n8n AI Agents With MCP: Connecting Tools to a Workflow

An n8n AI agent is a workflow step that hands a task to a language model along with a set of tools, and lets the model decide which tools to call. You build it with the AI Agent node: connect a chat model and at least one tool. n8n’s MCP Client Tool node makes any MCP server’s tools available to that agent, and its MCP Server Trigger node works the other way, publishing tools from a workflow so outside clients such as Claude can call them. The rest is ordinary n8n: a trigger starts the run, fixed steps move data, and a human review step can pause a tool call until someone approves it.

The AI Agent node

In n8n’s terms the AI Agent is a root node, and the model, memory and tools plug into it as sub-nodes. n8n’s page on the AI Agent node↗ (opens in a new tab) says you must connect at least one tool, and that since version 1.82.0 every AI Agent node works as a Tools Agent: the model is told which tools exist and what arguments they take, and picks among them.

• Prompt: taken from the previous node’s chatInput, or written in the node, with expressions for the data that changes per run.
• System Message: standing instructions, such as what the agent is for and what it must never do.
• Max Iterations: how many rounds the model gets to reach an answer. The default is 10.
• Return Intermediate Steps: include the tool calls it made in the output, which is the easiest way to see why it did what it did.
• Require Specific Output Format: attach an output parser when the next step needs structured data rather than prose.

Tools can be n8n’s own app nodes, such as Gmail, Slack or Postgres, a Call n8n Workflow Tool that runs another workflow, or MCP servers. A memory sub-node keeps a chat going across several messages; n8n notes that memory does not persist between sessions.

The MCP Client Tool: an agent using MCP servers

The MCP Client Tool node↗ (opens in a new tab) is an MCP client that plugs into the agent’s tool slot. You give it the server’s endpoint and an authentication method: bearer token, a generic header, several headers, OAuth2, or none. Then you choose which of the server’s tools the agent may see: All, Selected, or All Except. Servers already listed in n8n’s MCP servers registry can be connected from the node panel without adding a credential.

Use Selected more than you think. A server with thirty tools gives the model thirty choices and thirty descriptions to read, and the one that deletes things is among them. An agent that only reads and comments should only see the read and comment tools.

There is also a plain MCP Client node, for when you want a single MCP tool call as a fixed workflow step, with its arguments set by you rather than chosen by a model. That is often the better choice: if the step is always the same, it does not need an agent.

The MCP Server Trigger: n8n as a server

The MCP Server Trigger↗ (opens in a new tab) turns one workflow into an MCP server. It exposes a URL; MCP clients list the tools attached to it and call them. Attach a Call n8n Workflow Tool and a whole workflow becomes one tool. The node supports server-sent events and streamable HTTP, not stdio, and can require bearer or header authentication.

• Test and production URLs are separate. The production URL is registered when you publish the workflow.
• The path is random by default so that two triggers do not clash. Set it yourself if you want a stable address.
• In queue mode with several webhook replicas, n8n says all /mcp* traffic must go to one dedicated replica, or connections break.
• Behind a reverse proxy such as nginx, turn off proxy buffering for the MCP endpoint.

There is a second way in. n8n’s built-in, instance-level server, described in connecting to the n8n MCP server↗ (opens in a new tab), gives a client such as Claude Desktop or Claude Code one connection to the whole instance, with OAuth or an API key. An owner or admin switches it on under Settings, then enables each workflow separately. Every connected client sees every enabled workflow; you cannot limit one workflow to one client. Use the trigger when you want one workflow to behave as a purpose-built server, and the instance-level server when you want a client to find and run many.

A worked workflow

Take a common job: every morning, read yesterday’s error summary, group it into distinct problems, and file one task per problem on the team’s board, without filing the same problem twice.

1. Schedule Trigger, 07:00 on weekdays.
2. HTTP Request node: fetch yesterday’s error summary from your logging service.
3. AI Agent node, with a chat model, a System Message that says “group these errors into distinct problems; for each, search the board first and comment on an existing task if there is one; file a bug only if there is not”, and Return Intermediate Steps on.
4. MCP Client Tool attached to the agent, pointed at the board’s MCP server, with Selected tools only: search, create and comment.
5. A human review step on the create tool, so each new task waits for a person’s yes.
6. Slack node at the end, posting the agent’s summary of what it filed and what it commented on.

Endpoint:          https://your-board.example/mcp
Authentication:    Bearer   (credential: "board – morning triage")
Tools to Include:  Selected
  - search
  - create task
  - comment

Only step three is agentic; the rest is fixed. That is the pattern the general guide to agentic workflows recommends, and n8n makes the fixed parts cheap to build. Every node page in n8n’s documentation links to templates that use it, which is a quick way to start: copy one, then replace its credentials and narrow its tools.

Human approval in n8n

n8n’s human-in-the-loop for tools↗ (opens in a new tab) puts the approval on a tool, not on the whole run. You open the agent’s Tools panel, add a human review step, choose a channel, and connect the tools that need approval to it. When the agent wants to call one, the workflow pauses and a reviewer sees the tool and its arguments and chooses Approve or Deny. If denied, the call does not run and the agent is told.

• Channels include n8n Chat, Slack, Discord, Telegram, Microsoft Teams, Gmail, WhatsApp Business Cloud, Google Chat and Outlook, and the reviewer can be someone other than the person using the agent.
• $tool.name and $tool.parameters let you write the approval message so the reviewer sees exactly what will happen.
• Tell the agent in its System Message which tools need approval and what to do when one is denied; n8n says this is required for it to handle a refusal sensibly.

Put review on tools that send, change or delete, and leave it off reads. The broader question of where approvals belong is in the AI agent approval workflow.

Credentials

n8n keeps tokens and keys as credentials, separate from the workflow, so a workflow can be shared or exported without its secrets. On a self-hosted instance, n8n’s page on setting a custom encryption key↗ (opens in a new tab) explains that n8n generates a random key on first launch, saves it in the ~/.n8n folder, and uses it to encrypt credentials before they are saved to the database. In queue mode every worker needs the same key, set with N8N_ENCRYPTION_KEY. Back that key up: without it the stored credentials cannot be read.

• One credential per purpose, named for it, so you can revoke the morning triage token without breaking anything else.
• Ask each MCP server for the narrowest token it offers: read and comment if that is all the workflow does.
• Prefer an expiry where the server supports one, and put the renewal date on your own list.

Self-hosted or n8n Cloud

n8n comes as n8n Cloud, run for you, or self-hosted on your own servers with npm or Docker, and both are used in production. The differences that matter for agents are who holds the encryption key and the credentials, where the data goes, and whether you need the queue-mode caveats above. Check n8n’s own documentation for what each plan or edition includes.

When n8n beats code, and when it does not

• n8n wins when most of the job is moving data between apps it already has nodes for, when the trigger is a schedule, webhook or app event, when approvals need to reach Slack or Teams, and when the people maintaining it would rather read a canvas than a repository.
• Code wins when the agent itself is the product, when you need tests and code review on every change to the agent’s logic, or when the loop is long and open-ended. For that route, see how to build an AI agent.
• If you are moving off OpenAI’s visual builder, OpenAI Agent Builder compares it with n8n and explains the shutdown.

fenbs as the board in that workflow

The worked workflow above fits fenbs directly. Its MCP server is at https://fenbs.ai/api/mcp. A workflow cannot complete a browser sign-in, so issue a token by hand under Settings, “Connect an AI assistant”: give it a name, tick only the scopes it needs, set an expiry if you want one, and paste it into an n8n Bearer credential. Revoking it there stops the workflow without touching anyone’s sign-in. fenbs_create_item accepts a key from an automated source, and the same key never files twice, so a rerun of the morning job cannot double the backlog. Each change is recorded in the board’s history, so the team can see which tasks came from the workflow.