MCP tools and servers

The MCP route is visible, but the current console initializes an empty registry and states that integration is disabled by default. It does not support live server connections, external process spawning, or MCP tool calls.

The page is locked as preview, while live MCP operation remains disabled and unconfigured.

The safe use of this page is to understand why no live setup procedure is provided. The route and console are real, but the implementation intentionally begins with no registered servers or tools and disables connections, process spawning, and MCP calls. That posture prevents a preview surface from silently acquiring external authority. Any future implementation would still need registration, transport, authentication, tool contracts, permissions, credentials, approval, untrusted-output handling, and audit behavior before live operation could be documented.

MCP overview

The disabled state is an intentional product boundary, not a connection error to work around. The console initializes without registered servers and does not expose a supported transport, process launcher, authentication form, discovery operation, or live tool-call path. Keeping the route visible can support future design and inspection, but it does not authorize unofficial configuration or direct process spawning.

The verified /mcp route renders a console whose current state is intentionally disabled. The registry starts empty, no servers or tools are registered, and the console states that live connections, external process spawning, and MCP tool calls are not supported.

This preview posture is the product behavior to document. It is not a setup guide. A route, console, type, or future policy statement does not establish live MCP execution.

The verified /mcp route renders a console that describes a disabled integration posture.

No servers or tools are initially registered.

MCP definitions should be treated as potential external capabilities rather than current execution proof.

The MCP route currently communicates a disabled posture. The empty registry is expected, and the visible console should not be described as a live integration manager simply because the route exists.

Do not provide transport, authentication, command, endpoint, discovery, or registry steps that the implementation cannot execute.

The console does not support live server connections or external process spawning. Future external tool output would remain untrusted context and require explicit approval. Any future MCP tool would still require a tool contract, permissions, credentials, risk handling, approval, and audit behavior.

External tool output would remain untrusted context and could not bypass the agent approval boundary.

The empty registry also means that server and tool identifiers cannot be documented as examples of current availability. Any future identifier must come from a verified registration path, not from a hypothetical configuration. Until then, the only accurate status is that the route is a preview of policy and interface boundaries with live integration disabled.

Troubleshooting should stop at verification of that state. There is no supported transport choice, command runner, environment-variable schema, authentication exchange, health probe, or discovery call to test. A control added in a later build would need fresh source inspection before this page could describe it as functional.

Servers

The current product cannot connect a live MCP server or spawn an external process. Therefore transport selection, command configuration, environment variables, server authentication, health checks, restart policy, discovery, and lifecycle management are not available procedures.

Do not provide sample server commands or configuration files. They would imply an execution path that the supplied implementation explicitly disables.

The current console does not support live server connections.

It does not spawn external processes.

Do not document transport, discovery, lifecycle, or server-health behavior as available.

No live server connections are supported and no external processes are spawned. Therefore transport selection, process lifecycle, health checks, restart behavior, and server authentication are outside the current documentation boundary.

The verified /mcp route renders the MCP console.

No MCP tool calls are supported. Route visibility should never be translated into live integration availability while the console remains disabled.

No servers or tools are initially registered. The route is a disabled preview: it does not connect live servers, spawn processes, or execute MCP tool calls.

Tools

No MCP tools are initially registered, and no MCP tool calls are supported. A future MCP tool would still need a tool contract describing execution state, provider, scope, risk, permission, approval, input, and output. Contract presence would not by itself make the tool available.

Tool output is designated untrusted context. It cannot grant itself authority, mark work complete, bypass policy, or override approval requirements.

No MCP tool calls are supported in the current implementation.

Tool output is explicitly treated as untrusted context.

A future MCP tool would still need an Ethen tool contract, execution state, scope, risk, credentials, permissions, and approval behavior before it could participate in an agent run.

An empty server and tool registry is the expected current state rather than a setup failure.

MCP is not configured, and integration remains disabled by default.

Tool discovery would also need a trustworthy mapping from the remote description to an Ethen tool contract. Without that mapping, a discovered name cannot establish safe inputs, expected outputs, side effects, or approval behavior. The current empty registry avoids presenting such unresolved definitions as usable capabilities.

Configuration

Even a future visible configuration form would not prove that the backend can connect or execute. Live documentation requires inspected registration, transport, authentication, discovery, call, and audit paths.

The only grounded configuration state is unconfigured and disabled by default. No server-registry API, transport schema, credential form, command runner, connection test, or discovery workflow is implemented.

If the console displays an empty list, that is expected under the current posture. It should not be troubleshot as though a hidden server ought to be connected.

The source does not provide a supported live-server setup workflow.

Do not invent command lines, configuration files, endpoints, authentication fields, or registry controls.

The empty registry and disabled default are the expected current state.

The source does not provide a supported configuration file, command, endpoint, registry workflow, or connection form. Publishing invented setup instructions would contradict the disabled default and create an unsafe false path.

No MCP tool calls are supported.

No supported configuration artifact exists to validate. The source does not define a server JSON shape, command array, environment map, transport URL, credential field, or registration endpoint. Publishing any of those would turn speculation into an apparent contract.

A future configuration surface would still need to distinguish registration from availability. A saved server record could remain disconnected, unhealthy, unauthorized, or blocked by policy; a discovered tool could remain contract_only or require approval. Those states are not implemented here, but they explain why a visible form alone would not be enough to change this page into a live setup guide.

Security

The deny-by-default posture also prevents an external tool from declaring its own result authoritative. Even after future connectivity exists, returned text or structured data will need validation by the caller, and any requested side effect will remain subject to the tool’s permission and approval contract. The current console already states this trust boundary without enabling execution.

The displayed safety policy blocks bypass of approval runtime, project policies, self-granted authority, and completion gates. External tool results would require explicit approval where the tool contract demands it and must remain subject to normal agent permissions.

This page does not claim a complete future MCP security architecture. It records the current deny-by-default posture and the boundaries that any future implementation would have to preserve.

External tools would require explicit approval.

Untrusted tool output must not be promoted to instructions or trusted evidence without review.

Tool output is untrusted context, and the displayed policy blocks bypass of approvals, policy, self-granted authority, and completion gates. External capabilities would require explicit approval rather than inheriting trust from an MCP server.

MCP is not configured and integration is disabled by default.

No servers or tools are initially registered.

No MCP tool calls are supported.

Disabled connectivity is only one layer of the posture. If MCP execution is introduced later, server identity and transport security will not replace Ethen’s own authorization model. Every exposed tool will still need an execution state, permission mode, risk classification, project and agent scope, credential path, approval requirement, redacted error handling, and auditable result. Returned text or structured data must remain input for evaluation, not an instruction that can grant itself permissions or declare the task complete.

Troubleshooting

The disabled state should remain obvious in screenshots and support responses. Describing an empty registry as an outage would encourage unsafe workarounds and hide the intentional security posture. The correct resolution is updated product support, not manual process spawning.

There are no live connection or execution steps to repair. Confirm that the current console reports MCP as unconfigured, the registry is empty, and live server connections, process spawning, and tool calls are disabled. Those results are expected.

Do not install dependencies, run external commands, or add invented server records to make the preview appear active. A future implementation will require new inspected sources and updated documentation before setup guidance is safe.

An empty server and tool list is not necessarily a loading failure under the current disabled state.

If a control appears to connect or execute, verify it against a newer implementation before documenting it.

Do not attempt to work around disabled integration by spawning processes or calling unverified routes.

Troubleshooting begins by confirming the disabled state. Empty lists are not necessarily a loading failure, and an apparent connect or execute control should be reverified against newer source before it is documented.

No servers or tools are initially registered.

Before expanding the integration, treat the current empty, disabled state as expected and do not construct unofficial connection steps or bypass the approval runtime.

Live server connections, external process spawning, MCP tool calls, transport configuration, and supported setup controls are not available in the supplied implementation.

The expected result today is an empty, disabled console. No registered servers, transport configuration, authentication workflow, connection test, process launcher, discovery operation, or MCP call path is available in the supplied implementation. An empty list is therefore not evidence of an outage, and unofficial command lines or configuration files would create a false execution path.

The displayed safety posture still defines requirements for any future implementation. Server output must remain untrusted context; an external tool cannot grant itself authority, bypass project policy, mark a run complete, or skip an approval required by its Ethen tool contract. Registration alone would also be insufficient: live use would require an implemented transport, credential handling, scope, permission, risk classification, execution state, approval behavior, error handling, and audit records. Documentation should change only after those paths are present in inspected source.