- [Narrator] Before our agent can really do anything useful,
it needs tools.
So in this lesson we'll explore what a tool really is,
how tools work in n8n,
and what the difference is between built-in custom
and external tools, including things like MCP.
But before we get there,
let's quickly discuss what exactly is a tool.
Well, conceptually a tool is just an API call
wrapped with plain language documentation:
a name, a description, and a schema
that lists the input parameters the agent can supply.
That schema is the bridge between the agent's reasoning
and structure data.
Think of a tool like a function with documentation built in.
The LLM here doesn't read code,
it reads the available tool descriptions
and keeps them in context,
typically as part of the system prompt.
Let's make this concrete.
Imagine we would like to give our LLM a tool
that allows it to create GitHub issues for us.
Here's a GitHub API call that creates an issue.
It sends a title and body.
It's a simple POST HTTP request.
To give the LLM access to this tool,
we would define the tool similar to this
in the system prompt.
There isn't really a standard
for defining these tools except for MCP,
which we'll cover in a bit.
For now, here's what the agent sees:
a function like definition, typically in JSON schema
with parameter names, types, and which ones are required.
If we now prompt this LLM with a message like,
"Create a GitHub issue for me, 'Bug: Payment fails,'"
and the body message, "'Errors on checkout for EU cards,'"
then the LLM would recognize the intent
and match the user's goal, create an issue to the tool,
Create a GitHub issue.
That decision is made entirely by the LLM's reasoning,
based on the tool's description.
And effectively the LLM generates the payload,
structured data that matches the schema.
This is not the API call itself,
it's just a description of what needs to be executed.
Now, the LLM runtime, in our case, that's n8n, takes over.
It recognizes that the model is trying to call a tool,
and instead of showing that payload to the user,
it passes it to the corresponding tool node,
which runs the real action.
And in this case, that's an HTTP request to the GitHub API.
n8n handles the credentials, headers,
and network call safely.
The LLM never touches those directly.
GitHub now sends back a response, the issue number and URL.
And n8n then captures that output
and feeds it back into the agent's memory,
or conversation context.
And now finally, the LLM interprets the result
and replies a natural language.
Note, it didn't make the API call itself.
It simply decided what to do,
and then n8n handled how to do it.
That's the core of agentic tool use.
So to recap quickly, first, the LLM decides which tool
to use and prepares the payload.
Second, n8n then executes the real API call
through a node or workflow.
And then third, the result flows back into the conversation.
That's how the agent moves from generating text
to performing real action.
Let's zoom in back to n8n.
In n8n tools come in three flavors.
Pre-built standard nodes, custom tools in n8n,
typically your own workflows exposed as tools,
and external APIs, you call via HTTP requests.
Let's look at pre-built tools.
n8n comes with a wide range of built-in connectors
to popular services like Gmail, Airtable, or even GitHub.
Each of these connectors already includes
a predefined tool description,
which you can fully customize if you want,
along with the most relevant data fields.
For example, the Gmail node exposes inputs like
the To address, the Subject line,
and the Message body, so the agent knows exactly
how to send an email through Gmail.
Now, let's talk about custom internal tools.
n8n lets you take any workflow you've built
and expose it as a tool for your AI agent.
That means the agent can trigger any n8n workflow,
passing in data and getting structured results back
just like an API call.
Make no mistake, this is super-powerful.
You've seen this in action earlier when we connected
our knowledge tool.
The agent sent a question into a workflow,
the workflow fetched the answer
and then returned it to the agent as a result.
But it doesn't have to be a big workflow.
A tool could be as simple as a little code node
that performs a small calculation, cleans text,
or a small transformation.
If it accepts inputs and returns outputs,
it can act as a tool.
By exposing your internal logic this way,
whether it's a full workflow or just a small code snippet,
your agent can start using the custom logic
that already lives inside your organization,
not just external APIs.
Now, let's talk about external tools.
These are typically APIs that aren't covered
by n8n's built-in nodes.
The most flexible way to connect them
is through the HTTP request node.
Here you define the endpoint, the HTTP method,
any headers or authentication, and the expected body fields.
Once that's configured,
your agent can call this node just like any other tool,
passing in parameters and getting the API response back.
You can use this to integrate practically anything,
from CRMs to databases, document repositories,
or even your own internal APIs.
And there's also a newer standard to this
called the Model Context Protocol, or MCP.
MCP defines a common way for tools to describe themselves,
including their name, description, and input schema.
So any LLM-based agent can understand
how to use them right away.
n8n now supports this natively through the MCP client node,
which connects to any MCP server.
An MCP server can expose multiple tool at once,
so you don't have to wire them up one by one.
For example, imagine connecting to
a Google Workspace MCP server
that gives you access to Gmail, Drive, Sheets, and Docs
all through a single connection.
In practice, though, you might not need MCP
that often inside n8n, since there are already
so many built-in connectors available.
But it's a powerful option for integrating
external ecosystems that publish MCP endpoints.
And since you might hear MCP more and more often,
here's how it works.
On the left, you have the MCP client,
like in our case, n8n.
It connects to an external MCP server,
shown here in the middle.
This server can be hosted by anyone, even by you.
Since MCP is an open standard.
The server then hosts and manages multiple tools,
each with its own authentication and description.
Now, instead of wiring up every API individually,
n8n only needs to connect to the MCP server once.
From there, it automatically discovers all available tools,
like email, documents, or database access
that the server exposes.
So, the MCP client in n8n becomes your bridge
to entire ecosystems of tools,
without the manual setup you'd normally need for each one.
To summarize, the user sends a message
and then the LLM decides whether and which tool to use.
It creates a structured payload,
which is then handed off to n8n.
n8n then executes the real API call internally
using a built-in tool or workflow,
or externally by calling an HTTP API, or MCP server.
It gets the results and feeds that back to the model.
Finally, the LLM replies to the user in natural language.
This simple cycle, decide, execute and return,
is what turns a passive chatbot into an active agent
that can actually interact with the world around it.