The n8n Tool Node: Giving an Agent Something to Actually Do

In n8n, a tool is a sub-node attached to an AI Agent node that gives the model something it can actually call - and an agent with no tools connected is just a chat interface with extra steps.

The tool concept is where agent workflows stop being a demo and start doing work, and it is also where the interesting failure modes live. The mechanics are simple. The design decisions around what a tool is allowed to do are not.

Table of contents

• How the pieces fit together
• The tool types worth knowing
• Writing tool descriptions that work
• Scoping and safety, which matter more here than elsewhere
• Why this pushes toward self-hosting
• How this fits the rest of the stack
• FAQ

How the pieces fit together

The AI Agent node is a root node that requires sub-nodes connected beneath it. A chat model provides the reasoning. Memory, optionally, carries context between messages. And one or more tools give it capabilities.

The loop is straightforward: the agent receives input, decides whether it needs a tool, calls it with arguments it generates, reads the result, and either calls another tool or produces an answer. All agent nodes now behave as a tools agent, which was the recommended configuration before it became the only one.

The critical detail is that the model chooses which tool to call and what arguments to pass, based on the tool’s name and description. Those two fields are not documentation - they are the interface. A tool described vaguely gets called at the wrong times with the wrong arguments, and the fix is almost always rewriting the description rather than changing any logic.

The tool types worth knowing

• HTTP Request tool. Call any API. The most general and the one that covers everything the built-in catalogue misses.
• Integration tools. Existing nodes exposed as tools - read a spreadsheet row, search a CRM, post a message. Convenient because the authentication is already handled.
• Code tool. Run JavaScript or Python. For calculations, formatting, and logic the model should not be doing itself, which is more than people expect since models are unreliable at arithmetic.
• Workflow tool. Call another n8n workflow as a tool. This is the most useful one for anything non-trivial: put the complicated sequence in its own workflow, expose it as a single tool, and the agent sees one clean capability instead of eight steps it might get wrong.
• Vector store tool. Retrieve relevant documents for grounding, when the answer should come from your content rather than the model’s training.

The workflow tool deserves emphasis. Wrapping a multi-step process behind one named capability is the difference between an agent that reliably does a job and one that improvises a sequence differently every time.

Writing tool descriptions that work

This is the highest-leverage thing in the whole setup and it gets the least attention.

1. Say what it does and when to use it, in the description, in plain language. search_orders: Look up a customer's order history by their email address. Use when the customer asks about a past or current order. Not Order tool.
2. Describe every parameter, including the format. The model is generating these arguments and it will guess badly if you do not specify. Say that a date is ISO 8601 rather than hoping.
3. Say what it does not do. Explicit boundaries prevent misuse: Does not create or modify orders. Models will otherwise reach for the nearest available tool.
4. Keep tools narrow. One tool that does five things is called incorrectly more often than five tools that do one thing each.
5. Cap the tool count. Past a dozen or so, selection accuracy drops noticeably. If you need more, group related ones behind workflow tools.

When an agent misbehaves, read the tool descriptions first. Most agent debugging is prompt engineering wearing an infrastructure costume.

Scoping and safety, which matter more here than elsewhere

A tool is a capability handed to a non-deterministic caller. That is a genuinely different security posture from ordinary automation, and it deserves deliberate limits rather than the default of whatever credentials were nearby.

Read and write should not share a credential. Give the read-only tools read-only API keys. If the agent only ever needs to look things up, it should be incapable of changing anything, enforced by the credential rather than by the description.

Put a human in the loop for consequential actions. Sending an external email, issuing a refund, deleting a record, posting publicly. An approval step costs latency and prevents the category of incident that ends up in a post-mortem.

Bound the loop. Agents can iterate. Set a maximum number of tool calls per run, because a loop calling a paid API is a loop generating an invoice, and it will do so overnight while nobody is watching.

Log every call. Which tool, what arguments, what came back. Without this you cannot explain a bad outcome or a surprising bill, and both will happen.

Validate arguments before acting. The model generates them and it will occasionally generate nonsense. Check them the way you would check input from any untrusted source, because that is what it is.

Why this pushes toward self-hosting

Agent workflows tend to accumulate reach. A useful agent ends up with a tool that queries the customer database, one that reads an internal API, and credentials for several systems that were never meant to be reachable from outside the network.

On a hosted platform, that means your internal systems need to be reachable from the vendor’s infrastructure, and all those credentials live in their database. Self-hosted, the agent runs inside your network, calls internal services directly over private networking, and keeps its credentials in your own environment variables.

That is usually the deciding factor rather than cost - though the cost argument is real too, since agent workflows fire often and per-task pricing scales badly against something that loops.

How this fits the rest of the stack

An n8n instance running agent workflows needs a container that stays up, a Postgres database for credentials and execution history, and a reachable HTTPS endpoint for webhooks. The RunxBuild hosting calculator prices those pieces so self-hosting is a figure rather than an estimate. RunxBuild runs n8n as a managed tool from a $6 Basic plan with custom domains, environment variables, autoscaling, and logs, with managed Postgres beside it - so agents and their credentials stay on infrastructure you control.

Useful related references:

• n8n vs Make: Where the Complexity Goes
• n8n Use Cases: What It Is Genuinely Good At, and What It Is Not
• n8n Alternatives: The Honest Comparison by What You Are Escaping
• Node services on RunxBuild

FAQ

What is a tool in n8n?

A sub-node connected beneath an AI Agent node that gives the model a capability it can call - an HTTP request, an integration node, a code block, another workflow, or a vector store lookup. The agent decides which to call and what arguments to pass based on the tool’s name and description.

Why is my n8n agent calling the wrong tool?

Almost always the description. The model selects tools from their names and descriptions, so vague ones get called at the wrong times. Say what the tool does, when to use it, what each parameter’s format is, and explicitly what it does not do.

How many tools can an n8n agent have?

Technically many; practically selection accuracy drops noticeably past about a dozen. If you need more capabilities than that, group related steps into separate workflows and expose each as a single workflow tool, so the agent sees a few clean capabilities rather than many fine-grained ones.

How do I keep an AI agent from doing something destructive?

Give read-only tools read-only credentials so it is incapable rather than merely instructed, require human approval for consequential actions like refunds or external email, cap the number of tool calls per run, validate generated arguments as untrusted input, and log every call.

Should I self-host n8n for agent workflows?

It is worth considering, because agents accumulate reach - database queries, internal APIs, credentials for several systems. Self-hosted, the agent runs inside your network with private access and keeps credentials in your own environment; hosted, all of that sits with a third party.