The workflow had been working for eleven days. It was pulling support tickets from a Webhook node, running them through a Code node that did some basic classification, then hitting the Claude API via HTTP Request to generate a draft response, which went into a Set node and then out to the client’s helpdesk via another HTTP Request. Clean. Straightforward. The kind of thing that makes you feel briefly competent. Then on day twelve it started returning 400 errors from the Claude endpoint, and the error message said “invalid request body” which is the API equivalent of a shrug, and I spent the better part of two hours convinced I had broken something in the JSON construction before I found the actual problem, which was that Anthropic had updated the messages array schema in a way that the documentation reflected but the changelog had not flagged clearly enough for someone checking it casually. I had to go into the HTTP Request node, pull up the raw request body, compare it character by character against the current API reference, and find the one structural difference that was causing the rejection.
That debugging session is why I think MCP changes things more than most people currently understand.
Model Context Protocol, if you have not been watching Anthropic’s tooling releases closely, is a specification for how AI models communicate with external tools and data sources in a standardised way. The short version is that instead of building a custom HTTP Request node for every API you want Claude to interact with, you define a set of tools in a structured format and the model can call them contextually, based on what the task requires. It is the difference between handing someone a phone and telling them to call a specific number, and handing them a phone with all the contacts already saved and letting them decide who to call based on what they are trying to accomplish.
When you put that inside n8n, the implications are not subtle.
I have been running a test stack for the past few months: n8n handling the workflow orchestration, Claude as the reasoning layer via the HTTP Request node with MCP tool definitions passed in the system prompt, and a small set of tools pointed at internal APIs. The specific use case was a client’s contract review process, which previously required someone to manually pull documents from a SharePoint, run them through a checklist, flag exceptions, and route to the appropriate approver. The n8n side of this is not complicated. Webhook receives the document reference, HTTP Request fetches the file, another HTTP Request sends it to Claude with a structured tool list that includes a flag_exception function and a route_to_approver function with typed parameters. Claude reads the document, decides which tools to call, and n8n executes the corresponding downstream nodes based on the tool call response.
The part that is hard to explain without sounding like a marketing brochure is how different this feels from prompt engineering your way through the same problem. When I built a similar flow using LangChain six months earlier, I spent three weeks on prompt iteration, chain configuration, and debugging output formatting issues that were occurring because the chain was sometimes returning tool call syntax and sometimes returning prose, depending on phrasing I could not fully control. LangChain is genuinely impressive if you are building something research-oriented or if you have a team that can maintain the abstraction layers. For production automation work where a client is depending on consistent structured outputs, it is painful in ways that the demo never is.
MCP makes the tool calling deterministic in a way that matters for production. The model knows what tools exist, what parameters they take, and what it is supposed to return. When it works, it works reliably. When it does not work, the failure is usually in the JSON schema you defined for the tool, which means the error is in your code, which means you can fix it without renegotiating with an opaque chain configuration.
The documentation on running MCP through n8n’s HTTP Request node is currently incomplete in one specific way that will cost you time if you hit it. The tool definitions need to be passed in a particular position in the request body, and the examples in Anthropic’s MCP documentation assume you are calling the API directly from code, not constructing the request body inside a workflow node. The field nesting that works in a Python dict does not map cleanly to the way n8n’s JSON body editor handles nested objects by default. You need to switch to raw JSON mode in the body editor and construct the tools array manually. Once I worked that out it took about twenty minutes to get the first successful tool call. Getting to that realisation took considerably longer.
Zapier will not support this stack in any meaningful way because Zapier’s model is built around discrete trigger-action pairs, and what MCP enables is contextual, multi-step tool use within a single inference call. That is not a Zapier workflow. That is a fundamentally different model of how software should make decisions.
Business schools are still teaching automation as if it is about connecting apps. The actual frontier is about giving a reasoning layer the tools it needs to make decisions inside a workflow, and letting the model determine the sequence rather than encoding it yourself.
The engineers who understand how to build that kind of infrastructure right now are not writing it up in a way that makes it into a curriculum. But they are the ones whose clients are not going to be looking for someone to rebuild their automations in two years when the app-connection model stops being sufficient.
That gap between what is being taught and what is actually being built is not going to stay open much longer.
Olaitan Oladipo holds a BSc in Sociology from Olabisi Onabanjo University. He is a self-taught automation builder who has spent years inside n8n doing the work that most tutorials skip: debugging OAuth errors at 2am, migrating client automations from Make.com mid-project, fighting reverse proxy misconfigurations on AWS EC2, and figuring out through trial and error what actually holds up in production versus what only looks clean in a demo.
He is not a developer by training and not a SaaS founder. He is the person in the Discord server who actually answers the question instead of linking to the docs.
His writing on n8n Automation Tutorial covers self-hosting, AI agent workflows, tool comparisons, and the security vulnerabilities the automation industry would rather not discuss. He has built AI-assisted invoice approval flows using OpenAI function calling, connected Claude via HTTP Request nodes, and holds considered opinions about Zapier, Make.com, LangChain, and CrewAI that their marketing teams would not appreciate.
He writes for people who are technical enough to follow a tutorial but experienced enough to want the honest version.