AI agent tools n8n users actually ship with

An agent is a loop: a model, a prompt, and a list of things it's allowed to do. That last part is the whole game, and the AI agent tools n8n hands you are what turn a chat box into something that files a refund or updates a CRM record. Most broken agents we look at are not broken at the model. They're broken at the tools: too many attached, descriptions too vague to choose between, or one tool that returns 400 rows of JSON when the agent needed a single number.

So here's a list of what n8n actually gives you, what each one is for, what we'd use it for, and the ones we'd skip.

What counts as a tool in n8n

A tool is a node connected to the Agent node's tool port. The agent receives the node's name, its description, and a schema of the parameters it's allowed to fill. When the model picks it, n8n runs that node with the model's arguments and pushes the result back into the conversation. That's the entire mechanism, and understanding it saves you a week of guessing.

The piece that surprises people is $fromAI(). Any parameter on a tool node can be written as $fromAI('customer_email', 'the email address of the customer who complained'), and the model fills it at call time. A Gmail node stops being a fixed step in a linear workflow and becomes a function the agent can call with its own arguments. Same node, different contract.

This is why the description field matters more than anything else on the node. The model never sees your node's internals. It sees a name, a sentence, and a parameter list. If two of your tools could plausibly answer the same question, the agent will pick wrong some percentage of the time, and no amount of system prompt scolding fixes it. Rename the tools until a stranger could tell them apart from the description alone.

The AI agent tools n8n gives you out of the box

HTTP request tool

The one we reach for most. It lets the agent call any API you can describe, with the model filling path parameters, query strings, or body fields through $fromAI(). If your internal system has a REST endpoint, this is a five minute tool.

The failure mode is response size. An endpoint that returns every field of every record will eat your context window and confuse the model. Put a small transformation between the API and the agent, or use the endpoint's own field selection. We'd rather give an agent a tool that returns six fields than one that returns sixty.

Call n8n workflow tool

This calls another n8n workflow as a tool and returns its output. It's the most underused node in the whole set and the one that makes agents maintainable.

The pattern: keep the agent thin and push every multi-step procedure into a sub-workflow with a clear name and a tight input schema. "Issue a refund" becomes one tool, backed by a workflow that checks order status, checks the refund window, calls Stripe, writes to the ledger, and returns a confirmation. The agent decides when to refund. The workflow decides how. You can test the workflow without the model, which means when something breaks at 2am you're debugging deterministic steps, not a probability distribution.

App nodes attached as tools

Gmail, Slack, Google Sheets, Airtable, Notion, HubSpot, Postgres, and most of the rest of n8n's integration list can be attached directly to the tool port. You pick the operation, mark the fields you want the model to control, and leave the rest hardcoded.

That last part is the trick. Give the agent control of the message body but hardcode the Slack channel. Let it fill the search query but hardcode the spreadsheet ID. Every parameter you hand to the model is a parameter that can come back wrong.

Vector store question answer tool

Attach a vector store, ask a question, get an answer grounded in your documents. For anything that looks like "answer from our documentation", this beats stuffing the whole handbook into the system prompt.

Worth knowing: retrieval quality is a chunking and embedding problem, and no agent design rescues bad chunks. If your answers are wrong, the tool is usually innocent.

Code tool

Runs JavaScript or Python that the agent triggers, optionally with model-supplied arguments. Good for deterministic transformations the model is bad at: date math, ID formatting, parsing a weird string format, computing a total.

We use it as a correction layer. Language models do arithmetic and date arithmetic unreliably enough that we'd rather write eight lines of JavaScript than trust the token stream.

MCP client tool

Connects your agent to an MCP server and exposes that server's tools to the model. If you already run an MCP server for your internal systems, or you want to plug into a vendor's, this saves you rebuilding every endpoint as a separate node.

The caution is that an MCP server can expose dozens of tools at once, and dumping all of them into an agent is exactly the "too many tools" problem in a prettier wrapper. Filter down to the ones this agent needs.

Think tool

A tool that does nothing except give the model a place to reason before acting. It sounds pointless. In practice, on multi-step tasks with several similar tools, it measurably changes which tool gets called. Cheap to add, easy to remove if it doesn't help.

The demo tools

Calculator, Wikipedia, SerpAPI and Wolfram Alpha are the demo tools. Calculator is genuinely useful. The rest exist so the tutorial works, and we've never shipped a client workflow that needed Wikipedia. If you want live web results in production, you'll want a search API with a contract and a rate limit you control, wired through the HTTP Request Tool.

The parts that look like tools but aren't

Memory, chat models, and output parsers hang off the same Agent node but they're not tools. The agent doesn't choose to use them.

Memory nodes (simple buffer window, Postgres, Redis, and others) hold conversation history keyed by a session ID. Get the session key wrong and two customers share a conversation, which is the single worst bug we see in n8n chat agents. Test it with two browser tabs before you go live.

The structured output parser forces the agent's final answer into a JSON shape. If anything downstream consumes the agent's output programmatically, use it. Parsing prose with a regex is a bug waiting for a Monday.

AI agent tools vs skills

The words get used loosely, so here's the split that matters when you're building.

A tool is a callable function. The model emits a name and arguments, something executes, a result comes back. It's an action with a return value.

A skill is instructions. It's a bundle of procedure, context, and sometimes files that gets loaded into the model's context so it knows how to do a class of task. No execution, no return value. ChatGPT Work ships both as separate concepts alongside plugins, and the distinction there is the same as here: plugins and tools connect to systems, skills describe how to work.

n8n has no skills primitive. What it has is the system prompt on the Agent node, and sub-workflows with careful descriptions. If you're porting a skill-shaped idea into n8n, the procedure goes in the system prompt or gets compiled into a sub-workflow tool that does the steps for real. We prefer the second. Instructions drift under pressure. A workflow does the same thing every time.

The useful rule: if getting it wrong costs money or touches a customer, make it a tool with hardcoded parameters, not an instruction you hope the model follows.

What LangChain has to do with it

n8n's agent nodes are built on LangChain's JavaScript library. The Tools Agent, the memory nodes, the vector store nodes, and the output parsers all map onto LangChain concepts underneath the visual editor.

This matters for two reasons. First, when you hit a behaviour that makes no sense, LangChain's docs often explain it, because you're looking at their abstraction with n8n's paint on top. Second, it sets the ceiling. Anything LangChain's agent loop can't express, the n8n node can't either, and at that point you're writing a Code node or moving the agent out of n8n entirely.

If you're already comfortable writing agents in LangChain directly, the honest comparison is this: n8n buys you the connectors, the credential store, the execution log, and a UI a non-engineer can read. It costs you fine control of the loop. For most business processes that's a good trade. For a product where the agent loop is the product, write the code.

Three examples worth copying

Inbox triage. Gmail trigger, agent with three tools: a sub-workflow that looks up the sender in the CRM, a Gmail node that applies labels, and a Slack node that posts to one hardcoded channel. No send permission. The agent reads and routes, a human replies. This is the safest useful agent you can build and it's usually the first one we'd put in.

Internal question answering over documents. Vector Store Question Answer Tool over your handbook and process docs, plus one HTTP Request Tool hitting your ticketing system so it can say what's currently open. Chat trigger, Postgres memory keyed to the user's ID. The value here is that the answer cites something real instead of being generated from vibes.

Order operations. An agent with exactly four sub-workflow tools: look up order, check refund eligibility, issue refund up to a fixed amount, escalate to a human. Every tool is a workflow you can run and test on its own. The refund cap lives in the workflow, not the prompt, so the model cannot talk its way past it.

What all three share: few tools, tight scope, and a hard boundary between what the agent decides and what the workflow enforces. If you want a hand designing that boundary for your own processes, that's a large part of our AI services.

What's free, and what the free version costs you

n8n's source is on GitHub under a fair-code licence. You can clone it, run it with Docker, and build agents with every tool node listed above without paying n8n anything. The AI nodes are not gated behind a plan. That makes it one of the better free AI agent tool setups available, with the usual asterisk: you're paying in hosting, upgrades, backups, and the evening you spend on a Postgres connection string.

Model calls are separate and never free. Every tool call is a round trip through your model provider, and an agent that calls four tools to answer one question costs four times what the naive version suggests. Ollama through the local model node removes that cost and adds a hardware bill.

n8n Cloud is the paid path, priced by executions rather than by tasks or seats, which suits agents badly if you're not careful: a chatty agent runs a lot of executions. Self-hosting removes that pressure. The licence permits internal business use freely, so a company running its own operations on it is fine. Reselling n8n as a hosted product is where the licence starts having opinions, and that's worth reading before you build a business on it.

The GitHub repo is also the best debugging resource. When a tool node behaves oddly, the node source tells you exactly what gets sent to the model, which beats guessing from the UI.

Where we'd stop

Give the agent write access to a system, and you've built something that can be wrong in expensive ways. The UK AI Safety Institute ran a battery of tests on frontier agents and logged 19 unsanctioned actions across 122 tests, including an agent that created fake online identities and attempted to slip malicious code into a GitHub project without being told to. Those were research systems under deliberate pressure, not an n8n workflow doing invoice matching. The lesson still holds: an agent will find paths to its goal that you did not authorise, and the only reliable control is the one you build into the tool, not the one you write into the prompt.

So: caps in the workflow, not the prompt. Approval steps on anything irreversible, which n8n supports with a wait node and a Slack button. Separate credentials for the agent with the narrowest scope that works, so a confused agent can read the CRM but not delete from it. And log every tool call, because when someone asks what happened on Tuesday you'll want the execution history rather than a reconstruction.

Before you attach the next tool, check these

Can you describe what this tool does in one sentence a new hire would understand? If not, the model can't either.

Could this tool be confused with another tool already attached? Rename or merge them.

What's the worst thing this tool can do if the model calls it with the wrong arguments? If the answer involves money or a customer, hardcode more parameters.

How big is its output? Trim it before it reaches the model.

Can you test it without the agent? If not, move the logic into a sub-workflow you can run on its own.

An agent with four well-described tools and one clear job beats an agent with fifteen every time we've compared them. Start with the fewest tools that make the task possible, ship it to five people, and add the sixth tool only when you watch someone need it.