MCP integrations

MCP appears in Workflow Agent as a possible integration mechanism and configuration preview. Live MCP server connections, external process spawning, server registration, tool discovery, and tool calls are disabled in the inspected implementation. Use this page to understand the intended role and the security posture without following a fictional setup procedure.

MCP role

Model Context Protocol can describe a structured way for a client to discover and invoke tools exposed by a server. In Workflow Agent, mcp can appear as a candidate execution route and the integrations surface includes an MCP area. That representation supports planning and route analysis.

It does not establish a live connection. The general MCP console initializes an empty registry, and the Workflow Agent MCP route redirects to the integrations surface. A visible server card, configuration field, or tool definition should therefore be interpreted as preview data unless a future source proves a running server.

MCP also does not override the workflow control model. Tool output remains untrusted context, and any eventual invocation would still need to satisfy policy, credential, approval, and execution gates.

Configure a server

Live server configuration is not available. Do not document transport commands, process launch arguments, remote URLs, authentication fields, or registration steps as though they work today.

A configuration preview can still capture intended properties for review, such as a server identity, proposed transport, expected tool categories, and the policy boundary around those tools. Keep secrets out of the preview. Mark every server as non-executable unless the interface provides an explicit verified state, which the current source bundle does not.

The product must not spawn an external process from a preview card. It must not connect to an arbitrary host simply because a route is labeled MCP. If configuration appears complete, the correct result remains a reviewed draft or dry-run representation.

Tool discovery

An empty registry means there are no live discovered tools in the current console. Tool names included in seed data or a proposed server definition are examples, not evidence that discovery occurred.

Distinguish three ideas:

• a tool contract describes a possible input and output shape;
• a discovered tool would be reported by a connected server;
• an executable tool would also pass availability, credential, policy, and approval checks.

The current product does not verify the second or third state. Do not describe planned or contract-only tools as available. A Workflow Agent draft may reference an MCP-shaped action, but it should retain a blocked route and explain that discovery has not occurred.

Dry-run behavior

MCP support is configuration and dry-run oriented. A dry run can validate that the draft expects an MCP route, that required configuration is identified, and that the proposed action is represented in the workflow definition. It cannot contact a server or produce trusted tool output.

Treat any simulated response as test data. It should be clearly separated from real evidence and should not be used to authorize a downstream write. A dry run may expose missing server configuration, absent tools, or an approval requirement; these are useful preview outcomes.

No successful dry run changes canExecute or unlocks activation. It also does not prove transport compatibility, authentication, tool availability, or response correctness.

Security

MCP introduces a broad trust boundary because a server can advertise tools and return content that influences later reasoning. Current safeguards keep live execution disabled. Preserve that posture.

A future live path would need server allow-listing, authenticated transport, scoped credentials, schema validation, output sanitization, policy checks, approval gates, and auditability. These are requirements for review, not statements that the present implementation supplies them.

Never treat MCP output as instructions that can bypass product policy. Do not expose local files, environment secrets, or provider credentials to a preview server definition. Privacy and Terms are the approved legal references; no additional security or retention guarantee is verified.

Troubleshooting

If no servers or tools appear, that matches the empty-registry posture. If a route shows MCP as possible, read it as a candidate mechanism rather than as a connection failure. If a configuration card is present but execution is disabled, continue only with draft review.

Do not attempt to work around disabled controls with a guessed endpoint or process command. The documented current outcome is a blocked live path and an inspectable configuration preview.

Server and tool states

A server definition can exist without a connection. A connection can exist without successful discovery. Discovery can return a tool contract without making the tool executable. Documenting these states separately prevents a preview card from being read as a functioning integration.

The empty registry in the general MCP console establishes the current starting point: no live servers or tools are registered. Seeded examples and route candidates do not change that fact.

Untrusted output

If MCP becomes live later, server output must be treated as untrusted input to the workflow. Text returned by a tool should not be able to select another tool, expose credentials, change policy, or mark an approval as resolved. Schema checks and content handling would need to happen before the result influenced a later step.

That safety principle is already relevant to preview design. A simulated tool result should be labeled test data and should not be mixed with evidence that claims a real action occurred.

Transport and process boundaries

MCP implementation files do not authorize launching a local process, connecting to a remote server, choosing a transport, or passing environment variables. Do not copy common MCP configuration examples into Ethen documentation. A future implementation may support only a subset of transports and authentication models.

Review of an MCP-shaped draft

When a workflow proposes an MCP action, confirm that the step names the intended capability without assuming a discovered tool. Record the missing server and tool state, keep any sensitive action behind approval, and run only the supported configuration preview. The expected result is a blocked or dry-run route with clear prerequisites.

Policy and approval interaction

A proposed MCP tool can carry the same or greater risk as a native app action. Its tool contract should include risk and permission context, and a sensitive operation should remain behind an approval gate. The current disabled posture means the product can design those controls before enabling transport.

MCP must not become an alternate route around a blocked native or bridge connector. If policy rejects an action, selecting an MCP-shaped route does not change the decision.

Tool-schema review

A tool definition should specify expected inputs and outputs narrowly enough for validation. Free-form fields can increase the risk that untrusted content controls later behavior. The current preview can display a conceptual contract, but no server has confirmed it through discovery.

Do not document a tool as supporting a field merely because the draft would benefit from it. The real server contract must be inspected after live discovery becomes available.

Failure categories

Future live MCP failures could include connection, authentication, discovery, schema, policy, approval, execution, or response-validation errors. The present implementation can only represent configuration and preview failures. Avoid using network troubleshooting language when no connection attempt occurs.

Local-system exposure

Process-spawning and local-server support could expose files, environment variables, or network access. Live spawning is disabled, and documentation should not provide commands that would change that posture. Any future enablement requires explicit sandboxing and allow-list review.

Review endpoint

The supported endpoint of an MCP workflow today is a draft that identifies the desired tool, the absent server or registry state, the proposed security controls, and a dry-run result. That package can guide implementation without suggesting that a server was contacted.

Registry lifecycle

A future registry would need to distinguish configured, connected, discovered, unavailable, and removed servers. The empty current registry means none of those live transitions can be documented. A server preview should therefore remain outside the executable tool list.

Evidence from a dry run

Dry-run evidence can show that the workflow expected an MCP-shaped action and identified its prerequisites. It cannot contain a truthful remote response because no tool call occurred. Label any sample output clearly so it is not reused as operational evidence.

Disablement as the expected state

A disabled MCP control is not a malfunction in the current release. Troubleshooting should confirm the posture and stop, rather than directing the reader toward process-launch commands, network changes, or hidden configuration.

Server authentication

No credential or authentication method is verified for MCP servers. Do not describe bearer tokens, API keys, OAuth, local trust, or mutual TLS as Ethen support. A future server path must define how secrets are stored and which identity is authorized to register or call tools.

Tool-side effects

A tool contract can represent read-only or mutating behavior. A mutating tool would require stricter policy and approval handling, but current discovery and invocation are disabled for all tools. Keep the intended side effect visible in the draft without claiming that risk classification was enforced by a live server.

Status reporting

Use “disabled,” “empty registry,” “configuration preview,” or “dry run” according to the current surface. Avoid “offline” or “disconnected” unless a real connection was attempted, because those terms imply a live capability that temporarily failed.

No automatic trust from discovery

Even if future discovery returns a familiar tool name, the server identity, schema, permission, and policy state would still require review. Familiar naming cannot convert untrusted output into approved evidence.

Current conclusion

MCP remains useful as an integration design vocabulary, but every live server and tool operation is unavailable in the inspected product.