7. MCP in n8n: consuming external tools and the instance MCP server

Description

By the end of this lesson you'll be able to connect your agent to an MCP server another company publishes — so it uses tools you never built — choosing with judgment which of those tools you expose and which you don't, and you'll be able to open your own n8n instance's MCP server so a client like Claude Desktop, ChatGPT, Cursor, or Claude Code can build and run workflows inside your n8n, understanding exactly what you're handing over when you do it.

This matters for a reason you already lived through in the previous lessons without naming it. Every tool you've given the agent so far, you built: you chose the node, wrote the query, drafted the description, mapped every $fromAI(). That works great as long as the system on the other end is yours or has a native n8n node. But the day the team tells you "the agent needs to be able to create the incident in the team's Notion space, and also open the issue on GitHub," you run into a scaling problem: each external system is several tools, each tool is several fields, and all of it needs maintaining when the provider changes its API. MCP flips that work around. Instead of you building the adapter for every service, the service publishes its own and you just plug it in.

Connection to the module: lesson 6 closed by promising this lesson, and rightly so: there you encapsulated logic that lives inside your n8n instance, and it left open the question of what you do when the logic you need doesn't live there at all. Today we answer it in both directions — consuming tools from outside, and letting the outside work on your n8n. One honesty up front: MCP isn't this guide's central axis and this lesson doesn't aim to be a full protocol course. You're going to learn the durable concept — what a client is, what a server is, what you're entrusting to each one — and the nodes n8n uses for it, not the transport specification, which is also changing as you read this. The guide's weight still sits on multi-agent delegation, real channels, and security, which is what actually gets asked in an interview.

The custom cable and the standard port

Think about what charging devices was like fifteen years ago. Every device came with its own charger with its own connector: one for the phone, another for the camera, another for the music player. If you bought a new gadget, it came with a new cable, and if you lost the cable none of the others worked. Every manufacturer had solved the same problem — getting power to the device — in a way incompatible with everyone else's.

Then a standard port arrived. Now the manufacturer doesn't design its own connector: it fits whatever everyone uses, and you plug any device into any charger without thinking about it. The manufacturer still decides how much current its device accepts and what it does with it — that didn't get standardized — but how it connects, did.

The tools you built in lessons 3 through 6 are custom cables. The Postgres node with its parameterized query, the Gmail node with its fixed recipient, the refund-eligibility sub-workflow: you built each one yourself, field by field, for a specific system. They work great and for many cases they're still the best choice. But each one is work for you to build and work for you to maintain.

MCP — Model Context Protocol — is the standard port. It's an open protocol that defines how an application using a language model asks an external service two things: "what tools do you have available?" and "run this tool with this data." Nothing more. That's the whole idea, and it's deliberately small.

The anatomy has two pieces, and it's worth having them clear from the start, because the rest of the lesson leans on telling them apart:

• The MCP client is whoever has the model and wants to use tools. Your n8n agent can be a client. Claude Desktop is a client. Cursor is a client. Claude Code is a client.
• The MCP server is whoever publishes the tool catalog and executes it when asked. Notion has an MCP server. GitHub has one. And — this is what you're going to see in this lesson's second half — your own n8n instance can be one too.

The important thing for you, who's building agents and not implementing protocols: the client discovers the catalog at runtime. You don't copy the list of tools by hand. You give the client an address, and the client asks what's there. If the provider adds a new tool next week, it shows up on its own. That's the real difference from a custom cable, and it's this lesson's durable concept — the one that's still going to be true after the transport's details have changed three times.

The three forms of MCP in n8n

This is where a lot of people get tangled up, so it's worth pinning down before touching a single node. n8n participates in MCP in three different ways, and they aren't interchangeable:

Notice what changes between the second and third rows, because it's this lesson's most common conceptual mistake: MCP Server Trigger exposes business tools you built — "check an order's status"; the instance MCP server exposes n8n build-and-operate tools — "create a workflow," "validate this node's configuration," "run this workflow." One gives an external agent access to your logic; the other gives it access to your workshop.

This lesson focuses on the first and third rows, which are what the module asked for. About MCP Server Trigger you're going to see enough to recognize it and not confuse it with the instance server — it's the natural piece when what you want to share is a business capability and not your entire instance — but it's not where this lesson's real substance is.

Worked example: TuTienda's agent logs incidents in Notion

TuTienda's operations team keeps its incident log in Notion — a database of pages where every serious incident gets documented with its order, its customer, and what happened. So far, when the agent escalated a case, it wrote the row to Google Sheets and sent the email (lesson 4). Operations wants the page in Notion too, in the format they already use.

You could build this with the HTTP Request node against Notion's API: authentication, the page-creation endpoint, the JSON body with Notion's block structure. It's perfectly possible and exactly the kind of work MCP saves you. Notion publishes its own MCP server, hosted by them, and that server already knows how to create a well-formed page.

Step 1 — Add the MCP Client Tool node to the agent's ai_tool port. It's a sub-node, just like Postgres or Gmail in lesson 4: it connects with the same dotted line to the same port. What changes is you're not configuring an action — you're configuring an address:

# ai_tool CONNECTION -> node: MCP Client Tool
Endpoint         = "https://mcp.notion.com/mcp"
Authentication   = "OAuth2"
Tools to Include = "Selected"
Tools            = notion-search, notion-create-pages
Description      = "Use this tool to check and log incidents in
                    TuTienda's operations log, which lives in Notion.
                    Use it only when a case has already been escalated
                    to human support and needs to be documented. Do
                    not use it to reply to the customer or to check an
                    order's status — there's a different tool for
                    that."

Before continuing, let's break down each field, because each one is a decision, not a formality:

Endpoint is the address where the catalog lives. One note of honesty about this field: in n8n's documentation it shows up as SSE Endpoint, a name inherited from when Server-Sent Events was the only transport MCP supported. Today the recommended transport is HTTP Streamable, SSE stayed as backward compatibility, and some n8n versions add a transport selector next to the URL. Check what exactly the field is called in your version before pasting the address. What doesn't change — and what you need to understand — is what it represents: the gateway to that server's tool catalog.

Authentication is how you prove you have the right to use that server. n8n supports None (for public servers), Bearer, a generic header, several headers at once, and OAuth2. Notion, specifically, accepts only OAuth2 — when you configure it, n8n is going to send you to a Notion screen where you authorize which workspace it can touch. That consent is yours and is revocable from Notion, not from n8n. Worth knowing.

Tools to Include is the field most people overlook and the one that matters most for what you learned in lesson 5. It has three options: All exposes every tool the server publishes; Selected turns on a list where you choose which ones; All Except turns on the inverse list, where you choose which to block. Notion's MCP server publishes on the order of eighteen tools — search, read, create pages, update pages, move them, duplicate them, create databases, comment, query users. If you leave it on All, your customer-service agent ends up with the ability to move and duplicate pages from the company's workspace because someone wrote something weird in the chat. Setting Selected with notion-search and notion-create-pages isn't a cosmetic tweak: it's exactly lesson 5's trust boundary, applied to a catalog you didn't write.

Description is the same contract as always. The agent doesn't see Notion's catalog the way you see it; it sees what the server declares about each tool, plus whatever you write here about when to use this block of tools and when not to. Notice the description above explicitly states what not to do with it, and points to the right tool for an order's status. That prevents the tools-competing-for-the-same-intent problem you saw in lesson 5.

Step 2 — Put it to the test with a real case. With the workflow published, send a message that's clearly a serious incident and not a routine query:

curl -X POST "<your Chat URL, Production tab>" \
  -H "Content-Type: application/json" \
  -d '{
    "action": "sendMessage",
    "sessionId": "tab-mcp-notion",
    "customerPhone": "+1-555-8811-2299",
    "chatInput": "Order #4521 arrived open and with a wet box. I already complained twice and nobody has responded."
  }'

What to expect. The agent recognizes this doesn't get resolved with the lookup tool, escalates the case — row in Sheets, email to the team, like in lesson 4 — and also calls notion-create-pages through the MCP Client Tool, with a title and content it drafts from the message. The response to the customer looks like any other:

{ "output": "I'm so sorry about what happened with order #4521. I've documented the case and alerted the operations team so someone contacts you today. You're going to get a direct response, not through this chat." }

What confirms this actually happened is in two places, and it's worth checking both. In n8n's execution panel, the MCP Client Tool node shows up as an executed step, and inside it you're going to see the name of the tool the model chose from the server's catalog — notion-create-pages — along with the exact arguments it sent. That's what makes debugging MCP so different from debugging a normal node: a single node on your canvas could have executed any of the tools you enabled, and the panel tells you which one. The second thing is opening Notion and seeing the new page in the log. Same as in lesson 4 with Gmail and Sheets: the real system lives outside your Docker and the honest verification is looking at it.

Notice what you did not do at any point: you didn't write a single field of Notion's block structure, you didn't look up the database's ID, you didn't build a JSON body. Notion's server published a tool that knows how to do that, and your agent discovered it on its own. That's the savings.

One boundary worth marking: this is not the agent reading your documents. notion-search searches the workspace with the search Notion already has, the same as if you typed into their search bar. There's no embeddings, no document chunking, no semantic retrieval over PDFs or invoices. That's a different problem and belongs to another guide in the ecosystem. Here the agent acts on a system, as it's been doing since lesson 4.

The reverse direction: your n8n instance as an MCP server

Up to here, your n8n was the one going to the hardware store to get tools. Now let's open the counter.

Think about the difference between lending a tool to a neighbor and giving them the workshop key. Lending the tool is bounded: you give them the drill, you know what they can do with it, and they give it back. Giving them the workshop key is a different category of decision: they can use any tool, move them around, start new projects, and also leave everything a mess. Neither is bad on its own. What's serious is doing the second while believing you did the first.

Lending the tool is the MCP Server Trigger: a workflow that starts with that node exposes to the outside world the tools you connect to it, and nothing more. If you connect it the order-lookup tool, an external MCP client can look up orders. It's bounded by design. It's the right option when what you want to share is a concrete business capability.

Giving the workshop key is the instance MCP server, n8n 2.0's big novelty in this territory. It's not a node: it's a setting for the entire instance. When you turn it on, an MCP client can connect to your n8n and use tools to work on n8n itself: search workflows, view one's detail, create a new one from a natural-language description, update it, validate it, test it with pinned data, publish it, run it, review past executions, and manage data tables.

Put another way: you describe to Claude Desktop what you want a workflow to do, and the workflow shows up built in your instance, ready for you to open on the canvas and review. You no longer just build on the canvas and add a model afterward; now you can also talk to a model and have it build on the canvas.

What tools the instance server exposes

It's worth seeing the catalog, even grouped, because the list itself tells you what you're handing over to whoever you connect:

Read that table again with lesson 5's criterion in mind — reversibility, impact, who pays for the mistake — and you're going to see why this deserves care. create_workflow_from_code creates. update_workflow modifies what already exists. publish_workflow puts something into production. And execute_workflow runs the workflow's published version, meaning, in production mode: if that workflow sends real emails or writes to your business database, it sends and writes for real. Most of the other tools work on unpublished versions, which is a good safeguard; execute_workflow is the exception to keep in mind.

Worked example: enabling the instance server and building a workflow by talking

Step 1 — Enable MCP at the instance level. In n8n, go to Settings → Instance-level MCP and turn on Enable MCP access. You need to be the instance's owner or admin; if the button doesn't show up, that's the reason, not a version issue.

Step 2 — Enable workflows one by one. This is the detail that surprises a lot of people: turning on MCP at the instance level doesn't expose anything yet. Every workflow also has its own Available in MCP switch, which you can turn on from the workflow's own menu or from the Enable workflows button on that same settings screen.

Why two switches for the same thing? Because they aren't the same thing. The first decides whether your instance accepts MCP connections at all; the second decides, workflow by workflow, which ones stay in view. It's an explicit opt-in, and it's good that it is: if it were a single switch, turning it on would put every one of your company's production workflows within reach of an external client in one stroke.

Step 3 — Get the connection details. On that same screen, the connection details section shows you your MCP server's base URL, shaped like this:

https://<your-n8n-domain>/mcp-server/http

To authenticate you have two paths. OAuth2 is the recommended one: you paste the URL into the client, the client sends you to n8n to authorize, and that's it — there's no secret to copy and paste. MCP access token is the alternative: n8n generates you a personal token the first time you enter that screen, and you paste it into the client along with the URL. Treat that token with the same care as an administrator password, for the reason you already saw in the table above.

Step 4 — Connect your client. Depends on which one you use:

# Claude Code — HTTP connection with OAuth2
claude mcp add --transport http n8n-mcp https://<your-n8n-domain>/mcp-server/http

# Codex CLI
codex mcp add n8n-mcp --url https://<your-n8n-domain>/mcp-server/http

On Claude Desktop it's not a command but the interface: Settings → Connectors → Add custom connector, give it a name (for example, n8n MCP) and paste your instance's base URL. The authorization flow opens on its own.

One practical warning that saves half an hour of frustration: the client has to be able to reach that URL over the network. If your n8n runs in Docker on your laptop, at http://localhost:5678, a client that also runs on your laptop — Claude Desktop, Claude Code, Cursor — reaches it fine. A client that lives in the cloud, like ChatGPT in the browser, can't reach your localhost: for that you need your instance to have a public address, with HTTPS. It's not a limitation of MCP, it's how networks work — but it's the number-one stumbling block for whoever tries this for the first time on a self-hosted instance.

Step 5 — Ask it for something concrete. With the client connected, instead of opening the canvas, you write:

"In my n8n instance, create a workflow called Weekly Escalations Digest that runs every Monday at 8 a.m., reads the 'Cases' sheet from the 'TuTienda Escalations' spreadsheet filtering rows from the last 7 days, and sends an email with the count and the list to the team. Leave it unpublished."

What to expect. You're not going to see a workflow appear instantly: you're going to see the client work through several steps, and those steps are the table's tools in action. It typically checks search_nodes to find out which node maps to a schedule trigger and which to Google Sheets, calls get_sdk_reference to know how the configuration is declared, builds the definition, runs it through validate_workflow — and if something doesn't fit, fixes it and validates again — and only then calls create_workflow_from_code. When it's done, it gives you the created workflow's ID or name.

Now the part you shouldn't skip: open n8n and check it with your own eyes. You're going to find the workflow in the list, unpublished, with its nodes built on the canvas. Open it, verify the Google Sheets credential is the correct one, that the date filter says what you actually wanted it to say, and that the email's recipient is the right one. A model having built it doesn't change anything about what you learned in the previous six lessons about checking before trusting — if anything, it makes it more necessary.

Also notice what you explicitly asked for: "leave it unpublished." It's a good habit. Publishing is what puts the workflow into production, and that decision is best made by you after looking at it, not by the model while it builds.

The piece in the middle: lending a tool with MCP Server Trigger

Between consuming outside tools and handing over the workshop key sits the middle case, and it's worth seeing even though it's not this lesson's focus: sharing one of your business capabilities, and only that one.

MCP Server Trigger is a trigger node, meaning it goes at the start of a workflow, like the Chat Trigger you've used since Module 1. But it behaves differently from any other trigger you've seen: instead of receiving an event and passing data to the nodes that follow, it has no nodes that follow it. The only thing connected to it are tools, through the same dotted connection type you use to fill an agent's ai_tool port.

Think of it as a toolbox with your name on the door. Inside you put exactly the tools you want to lend — not one more — and whoever arrives with the right address can see what's there and use what they need. They can't open other boxes or walk into the workshop.

# Workflow: "TuTienda Support Tools"

  ┌──────────────────────┐
  │  MCP Server Trigger  │   ← this node has NO output to other nodes
  │  Path: /tutienda     │
  │  Auth: Bearer        │
  └──────────┬───────────┘
             │ tools connection
      ┌──────┴───────┐
      │              │
 ┌────▼─────┐  ┌─────▼──────────┐
 │ Postgres │  │ Call n8n       │
 │ (order   │  │ Workflow Tool  │
 │  lookup) │  │ (refund        │
 │          │  │  eligibility)  │
 └──────────┘  └────────────────┘

The node gives you two addresses, with the same logic you already know from Chat Trigger: a test URL, which works while the workflow isn't published and lets you see the data on the canvas, and a production URL, which gets registered when you publish it and whose data shows up in the executions tab. The Path comes randomly generated and you can change it to a stable one. Authentication supports Bearer or a header, and it's worth setting it: without it, anyone with the address can use your tools.

What to expect. An agent from another team — or your own Claude Desktop — connects to that URL with an MCP Client Tool, asks what's there, and gets exactly two tools: look up an order and evaluate refund eligibility. Nothing else living on your instance shows up on that list. If tomorrow the finance team also needs to check refunds already issued, you add that tool to the same trigger and it shows up on its own on the other end, with nobody having to reconfigure their client.

The comparison with what comes next is the one you need to take away: here you decide tool by tool what gets shared, and everything you didn't connect stays invisible. On the instance server you don't choose tools, you choose workflows, and the tools exposed are the ones for building and operating n8n. They're two very different levels of access with similar names.

The instance server's trust boundary

It's worth spelling out plainly what leaving this open implies, because it's a security decision, not a configuration one.

Every client you connect sees every workflow you've enabled. You can't say "Claude Desktop can see this workflow but ChatGPT can't." The Available in MCP switch is per workflow, not per client. If you enable the billing workflow so a client helps you debug it, it stays enabled for any client that has access to your MCP server.

A connected client can modify, not just read. update_workflow and publish_workflow are in the catalog. The capability you're handing over isn't "query my n8n," it's "work on my n8n."

From that, a practical criterion, in line with lesson 5's reversibility table: enable the instance MCP server in your development environment, not in production, and only enable the workflows you're actively building on it. When you're done working on one, take off its Available in MCP. It's the same hygiene habit you'd apply to any administrative access: it's granted narrowly and revoked when no longer needed.

When MCP isn't the answer

MCP is one more tool, not a promotion to a higher category. An agent that consumes three MCP servers isn't better than one with three well-built native tools — it's different, and sometimes worse. Here's the criterion that helps you decide, and it's the part of this lesson that's going to stick with you the most:

The question that resolves almost every borderline case is simple: who owns the logic I need? If it's yours, it stays in n8n. If it's someone else's, MCP is the port it comes in through.

Common mistakes

Connecting an MCP server with Tools to Include = All without reading the catalog (conceptual). What happens: someone connects Notion's MCP server so the agent can log incidents, leaves the field at its default value, and without realizing it, has given the customer-service agent eighteen tools — including moving pages, duplicating them, and creating new databases in the company's workspace. Why it happens: the node looks like a single node on the canvas, so the intuition says "I connected a tool"; actually you connected a complete catalog, and the size of that catalog is decided by the provider, not you. Also, every enabled tool takes up space in the context the model receives, so a big catalog makes the model choose worse among all the tools, not just the MCP ones. How to spot it: open the MCP Client Tool node, change Tools to Include to Selected, and look at the list that unfolds — that's the real list of what your agent can do today with that server. How to fix it: use Selected with the minimum tools the use case needs, or All Except to explicitly block the destructive ones; it's the same criterion from lesson 5's reversibility table, applied to a catalog you didn't write.

Confusing MCP Server Trigger with the instance MCP server (conceptual). What happens: someone wants Claude Desktop to help build workflows, adds an MCP Server Trigger to an empty workflow, connects Claude Desktop to that URL, and no useful tool shows up from the client — there's no way to create a workflow from there. Why it happens: both are called "MCP server" and both make n8n a server, but they expose things of a completely different nature. MCP Server Trigger exposes the tools you connect to that workflow: if you didn't connect any, it exposes nothing, and even if you connect several, they're still business tools. The instance MCP server exposes n8n's build-and-operate tools, and it's not turned on with a node but in Settings. How to spot it: ask yourself what you want the external client to be able to do — if the answer is "use a capability I already built," it's the trigger; if it's "build new things in my n8n," it's the instance one. How to fix it: to build workflows by talking, go to Settings → Instance-level MCP, turn on Enable MCP access, and connect the client to https://<your-n8n-domain>/mcp-server/http.

Treating the instance MCP access token as a read-only key (practical). What happens: someone generates the token, pastes it into a client running on a shared machine — or sends it over chat to a coworker so they can "also see the workflows" — with the idea that at most they'll be reading configurations. Later a workflow shows up modified, or published, with nobody remembering having touched it on the canvas. Why it happens: the instance server's catalog includes update_workflow, publish_workflow, and execute_workflow — whoever has the token has write and production-execution capability, not just query access. How to spot it: check the execution and change history of the workflows you have enabled in MCP; an execution nobody triggered from the canvas or from a real trigger is the signal. How to fix it: prefer OAuth2 over the token when the client supports it — that way every person authorizes with their own account and you can revoke individually —, enable the instance server in development and not in production, and take off Available in MCP on every workflow as soon as you're done working on it.

Pasting an MCP server's URL into a field expecting a different transport (practical). What happens: you configure MCP Client Tool with a modern server's URL, and the node hangs, fails to list the tools, or — in the worst reported case — enters a retry loop that fires an absurd number of requests. Why it happens: MCP supports more than one transport. SSE was the original and stayed as backward compatibility; HTTP Streamable is the recommended one today. Some servers expose two different addresses — one for each transport — and n8n's field keeps the inherited name SSE Endpoint, which makes it easy to paste the wrong address or assume a transport the server no longer speaks. How to spot it: if the node can't list the server's tools, or the execution panel shows chained retries, it's almost always this and not an authentication problem. How to fix it: check the provider's documentation for the address for each transport — Notion's server, for example, publishes one for HTTP Streamable and another ending in /sse — and check in your n8n version whether the node has a transport selector; if it does, the URL and the selector have to match.

Exercises

Exercise 1 — Choose the mechanism. For each of these four assignments, decide which of the four pieces fits — native node as a tool, sub-workflow as a tool, MCP Client Tool, or instance MCP server — and justify in one sentence:

(a) The agent should be able to write a row to the Google Sheets escalations spreadsheet. (b) The agent should decide whether an order qualifies for a refund by applying the policy with category exceptions. (c) The agent should be able to create an issue in the product team's GitHub repository, which already publishes its own MCP server. (d) You want to ask Claude Code to build you a new weekly reports workflow without opening the canvas.

Exercise 2 — Narrow the catalog. You connect Notion's MCP server to TuTienda's support agent. The catalog includes, among others: notion-search, notion-fetch, notion-create-pages, notion-update-page, notion-move-pages, notion-duplicate-page, notion-create-database, notion-update-database, notion-create-comment, notion-get-comments. The agent's only job with Notion is to document an incident when it escalates a case, and to check whether that incident already existed. Write the Tools to Include configuration and justify what you left out and why.

Tools to Include = "Selected"
Tools            = notion-search, notion-create-pages

Exercise 3 — Diagnose the access. At TuTienda someone turned on the instance MCP server on the production instance and enabled Available in MCP on every workflow "to be able to check them quickly from chat." A new person on the team connected their MCP client with the token they were given and asked it: "test the notifications workflow to see if it works." The next day some customers had received an escalation email that didn't apply to them. What happened, and what three things would you change in the configuration?

Summary and next step

In this lesson you saw MCP in both directions. Outward, MCP Client Tool connects your agent to a catalog an external server publishes: you give it an address, a way to authenticate, and — most importantly — you narrow with Tools to Include which part of that catalog actually stays within the model's reach. Inward, the instance MCP server opens your n8n so Claude Desktop, ChatGPT, Cursor, or Claude Code can search, build, validate, test, and run workflows inside your instance, with a double switch — Enable MCP access at the instance level, Available in MCP per workflow — that exists precisely because what's handed over there is the workshop key.

Before moving on you should be able to: explain in one sentence the difference between an MCP client and server, and say which one n8n is in each of the table's three cases; tell apart MCP Server Trigger from the instance MCP server by what each one exposes; narrow an external server's catalog with a reversibility criterion instead of leaving it on All; and decide, given a new assignment, whether a native node, a sub-workflow, or MCP fits, by answering first whose logic it is.

With this you close out the module's conceptual arc. You have the tool-calling mechanism (lesson 2), the native catalog (lesson 3), the connection to real systems (lesson 4), the contract and trust boundaries (lesson 5), encapsulation in sub-workflows (lesson 6), and tools coming from outside (this one). What's left is the only thing that genuinely proves you have it: building it. The next lesson is the module's mini-project — an agent with three tools that search, create, and send against real systems, verified start to finish, not by what the agent says it did but by what you can prove happened.

Resources

• MCP Client Tool node — n8n Docs — reference for the sub-node: the endpoint field, the authentication methods, and the three Tools to Include options.
• MCP Server Trigger node — n8n Docs — the node that exposes one workflow's tools as an MCP server, with its test and production URLs.
• Use n8n MCP server — n8n Docs — what the instance MCP server is and what it lets you do from an external client.
• Connect to n8n MCP server — n8n Docs — the /mcp-server/http URL, OAuth2 versus the access token, and the connection steps for Claude Desktop, Claude Code, and Codex CLI.
• MCP server tools reference — n8n Docs — the instance server's complete tool catalog, including the note that execute_workflow runs in production mode.
• Model Context Protocol — official site — the protocol's specification: what a client is, what a server is, and how tools get discovered. Useful if you want to see what's underneath the nodes.
• Notion MCP server — Notion — this lesson's hosted-server example: its address, its OAuth authentication, and the catalog of tools it publishes.