n8n and MCP: expose workflows to agents or call MCP tools

n8n supports MCP in both directions: MCP Server Trigger exposes tools to agents, while MCP Client calls external tools from workflows. Use MCP Client Tool when an n8n AI Agent should choose those external tools.

What it can do

Think about who initiates the action. An editor agent might request an order-status lookup from an automation you control. Alternatively, a workflow might call an external lookup tool before preparing a report. These are suggested designs, not preconfigured integrations.

The Trigger connects to tool nodes; attach workflows through the workflow tool node. The regular Client fetches available tools and lets you select one, with manual parameters or JSON for nested input. Client Tool provides an inclusion selector; start with Selected rather than making every tool available. These distinctions follow the official Server Trigger, MCP Client and Client Tool references, as of 30 Oct 2026.

A useful first design accepts an order identifier and returns only status and the last update. Keep customer contact details out of its response unless the task requires them. Write down what happens for an unknown identifier and an unauthorized account before inviting an agent to use it.

If you are comparing approaches, see MCP versus APIs and function calling, or browse MCP servers for apps.

Choose a narrow endpoint or instance-level access

n8n also documents instance-level MCP for Cloud and self-hosted instances, with OAuth or a personal token. It can support workflow discovery, execution and creation/editing. Workflow exposure is not a separate allowlist for each client; user access and granted client permissions still matter. (Instance-level documentation, as of 30 Oct 2026.)

For a narrowly defined automation, consider a Trigger endpoint first. If your actual requirement is to let an editor help build workflows, evaluate instance-level access separately. A person authorized to request a status lookup does not necessarily need permission to change the automation behind it.

For either deployment, require an endpoint reachable from the actual caller. A local browser successfully opening the editor does not prove that a remote agent can reach the MCP service. With self-hosting, include DNS, HTTPS and proxy configuration in your deployment review. n8n's reverse-proxy guidance covers external URLs and forwarded headers. Check the current documentation for settings matching your installation.

How to connect it safely

1. Define the operation and its owner. Record accepted inputs, returned fields, downstream credentials and every possible write. Review each exposed workflow like an API. For a lookup pilot, explicitly exclude creating orders, sending messages and changing account records. Use the MCP security checklist to organize that review.

2. Build a small, testable boundary. For incoming agent calls, attach only the intended tool to the MCP Server Trigger. For outgoing calls, configure MCP Client with the endpoint, server transport and selected tool. For an AI Agent, configure MCP Client Tool and select the permitted tools. The respective node references above describe these controls. Keep unrelated operations outside the pilot.

3. Configure authentication in the correct direction. The Trigger offers Bearer or Header auth, alongside None. The outbound client supports bearer, header, multiple headers and OAuth2. Match the server's requirements; do not assume an authentication method supported by an outbound client is also offered by the Trigger. For a bearer credential, n8n uses the Authorization header with a Bearer token; custom header credentials require a name and value. (HTTP credentials, as of 30 Oct 2026.) Keep secrets out of examples, prompts and committed configuration.

4. Connect the editor to the intended endpoint. For a Trigger, copy its displayed MCP URL and configure a compatible HTTP MCP client with the matching credential. For instance-level access, follow n8n's VS Code connection example: choose VS Code in the connection dialog where available, or use the documented workspace configuration and complete authorization. Its server URL ends in /mcp-server/http. Never substitute the editor's browser URL. See also MCP in VS Code.

5. Test before publishing. The Trigger's test URL works while listening for a test event; its production URL is registered when the workflow is published. Inspect production runs in Executions. (Trigger reference.) Try a valid lookup, missing input, unauthorized request and downstream failure. Judge the returned data and actual side effects, not only whether the client reports success.

6. Set approval and recovery rules. Require a human decision before adding a write operation. Decide how to recognize a repeated request and who checks an uncertain outcome. Before retrying a timed-out write, inspect the target system. A missing response alone is not evidence that nothing happened. Record an owner who can revoke access and disable the endpoint.

When this does not work

The caller only supports stdio. The Trigger supports SSE and Streamable HTTP, not stdio. Choose a compatible client or check the current documentation for an appropriate bridge. (Transport details.)

The endpoint is reachable only from the wrong machine. Test connectivity from the caller's environment. Behind a proxy, verify the advertised address and forwarded headers against the reverse-proxy reference above. Do not solve a networking failure by removing authentication.

A large result fails in queue mode. n8n documents a worker response relay limit that also applies to MCP Trigger tool results; tool results cannot use response offloading. Return a compact result and consult queue-mode documentation for current settings, as of 30 Oct 2026.

The call times out or behaves too broadly. MCP Client has a timeout option, but increasing it cannot resolve an uncertain write or an overpowered tool. Reduce the operation's scope, inspect the downstream outcome and make repeated calls safe before allowing unattended use. (Client options.)

Where Tvijo fits

Use n8n automation next to Tvijo tasks: ask for a bounded review of the workflow contract, then verify the automation separately. The DSHREM VS Code extension is an editor entry point for Tvijo tasks. TvijoCode embeds the extension in a test build; it is Windows-only, unsigned and lacks automatic updates. These are separate choices from configuring an MCP client for n8n.

As of 30 Oct 2026, Tvijo MCP's release-status page distinguishes published consultation from prepared diff review awaiting publication. Editor integration and safe delegation remain planned phases. Tvijo MCP makes Tvijo callable by an MCP client; it does not establish a ready n8n integration or make the extension a general executor of external MCP tools.

The Tvijo workspace, as of 30 Oct 2026, lists Try at $0: up to 5 tasks, 50,000 tokens or $0.05 of sponsored usage, whichever is reached first, within a shared $1 daily pool funded by TVIJO. Service credit is shown as $10 for requesting prepaid credit, with metered provider usage plus an 8% service markup. Payment collection is not activated; an order is not a charge.

FAQ

Which n8n MCP component should I choose?

Use the direction table above: expose an operation to an agent, call an external tool at a workflow step, or offer selected tools to an n8n agent. Decide which component controls execution before configuring it.

Does Cloud remove the need for access review?

No. Regardless of hosting, review the identity, inputs, returned data and downstream permissions. A hosted endpoint still needs an explicit operational boundary.

Can I expose a workflow that changes records?

Treat it as a separate rollout after the lookup pilot. Define authorization, human approval, duplicate handling and recovery first, then verify the target system after each test.

n8n is a trademark of its owner. Tvijo is not affiliated with or endorsed by it.