Claude Code as an MCP Hub: What We Learned
What We Set Out to Build
By early 2026, we were running automations across five separate surfaces: n8n for orchestration, a browser-based LLM interface for drafting, a dedicated API client for testing, a Slack bot for internal routing, and a spreadsheet that tracked which tool did what. According to McKinsey's State of AI 2024 report, 72% of organizations now use AI in at least one business function, up from 50% in prior years. Most of them, like us, arrived at that number by adding tools one at a time rather than by design.
The goal was simple to state and hard to execute: collapse that surface area into a single command environment. Claude Code, Anthropic's terminal-native coding assistant, had just shipped stable support for Model Context Protocol - what the community shortens to MCP. The protocol lets a reasoning model call external tools, read live data sources, and write back to third-party systems without leaving the session. On paper, it looked like the connective tissue we needed.
We weren't trying to replace n8n. The pipeline orchestration layer stays - it handles scheduling, retries, and the branching logic that a conversational interface handles poorly. What we wanted was a single place to author those pipelines, test API calls, inspect payloads, and push changes, without toggling between four windows. That's the specific problem MCP was supposed to solve.
What Happened - Including What Went Wrong
The first MCP server we wired in was a filesystem connector. That part worked immediately. The model could read a local JSON config, suggest edits, and write the file back. Useful, but not the integration depth we needed.
The Stripe MCP server is where things got instructive. I learned this the hard way during our first Stripe product creation through the MCP interface: the API call included a recurring parameter set to null. We assumed omitting the value was the same as omitting the field entirely. It wasn't. Stripe created two prices - one correct one-time payment at $297, and one spurious monthly subscription at $297. We caught it before any customer was charged monthly for a one-time product, but it took a manual archive in the Stripe Dashboard to fix. The lesson wasn't about Claude Code specifically. It was about the gap between "the model generated valid JSON" and "the API received the payload we intended." Now our factory pipeline never includes the recurring field at all - not null, not false, just absent.
That incident shaped how we think about MCP integrations generally. The protocol hands the reasoning layer a set of tools and trusts it to call them correctly. When the tool's behavior is sensitive to field presence versus field value - and many payment, CRM, and messaging APIs have exactly this characteristic - you need explicit guardrails in the system prompt, not just a well-formed schema.
We also ran into a subtler problem with context window management. Claude Code sessions are stateful within a conversation but not across them. When we were building a multi-step n8n workflow - reading a webhook config, editing a node, testing the output, then committing the change - a session timeout mid-sequence meant the model lost the earlier context. We had to re-paste the workflow JSON, re-explain the goal, and re-run the preceding steps. For short tasks, this is a minor annoyance. For complex pipeline builds that span an hour of iteration, it's a real cost.
The GitHub MCP connector was the most reliable of the four we tested. Read access to repositories, diff generation, and commit drafting all worked without surprises. If your primary use case is code review and documentation, the integration holds up well. If you're trying to use it as a live operations console - reading production logs, mutating database records, pushing to external APIs - the failure modes multiply quickly.
One thing we didn't anticipate: the MCP directory is still fragmented as of mid-2026. Anthropic maintains an official list, but community-built servers vary wildly in quality. Some have no error handling. Some expose credentials in ways that would concern a security-conscious team. Before wiring any MCP server into a workflow that touches customer data, read the source. This is not optional advice.
For teams already building on n8n, the honest comparison is this: MCP inside Claude Code is excellent for authoring and debugging individual nodes. It is not a replacement for n8n's visual canvas when you need to see the full execution graph, manage credentials centrally, or run scheduled triggers. We've written about the tradeoffs of building agents from scratch versus using a dedicated service in this breakdown of agent service toolkits - the same logic applies here. The right tool depends on where in the build cycle you are.
Lessons Learned
Three things changed how we work after this experiment.
Field presence is not the same as field value. Any MCP integration that calls a payment processor, a CRM write endpoint, or a messaging API needs explicit instructions about which fields to omit entirely versus which to set to a default. "Don't include recurring unless the product is a subscription" is a better system prompt instruction than "set recurring to null for one-time products." The Stripe incident made this concrete for us, but the pattern shows up in HubSpot property updates, Twilio message parameters, and anywhere else an API distinguishes between a missing key and a null value.
Consolidation has a ceiling. We reduced our active tool count from five surfaces to three. That's real. But the claim that one well-configured tool can replace an entire stack is only true if your stack was poorly configured to begin with. Claude Code with MCP is a powerful authoring environment. It is not a scheduler, not a credential vault, not a monitoring dashboard. Trying to force it into those roles produces fragile workarounds, not a cleaner system. The lessons we documented from the Activepieces MCP build echo this - every tool has a boundary, and the boundary matters more than the marketing.
The value is in depth, not breadth. We connected four MCP servers during this experiment. The one we actually use daily is the filesystem connector, because we invested time in understanding exactly what it could and couldn't do. The Stripe connector sits dormant after the incident above - not because it's broken, but because we haven't yet built the guardrails to use it safely in a live environment. Collecting integrations without mastering them produces the same sprawl problem you started with, just at a different layer of the stack.
For teams building B2B automation pipelines - the kind that touch CRMs, payment systems, and outbound communication - the MCP ecosystem is genuinely useful, but it rewards caution. The reasoning model is only as reliable as the instructions you give it about the APIs it's calling. If you want to see how we structure those instructions in practice, the cold email automation system design post covers the prompt architecture we use when an LLM is making live API calls.
The broader point is one we keep returning to: according to McKinsey's 2024 State of AI report, AI adoption has grown fast, but most organizations are still in the "added a tool" phase rather than the "redesigned the process" phase. Claude Code with MCP can be part of a redesigned process. Used carelessly, it's just another tool in the pile.
What We'd Do Differently
Audit every MCP server's source before connecting it to anything that touches production data. We skipped this step on the first pass and got lucky. The community ecosystem moves fast, and "available in the directory" does not mean "reviewed for security." Treat each server like a third-party npm package: read the code, check the credential handling, understand what it can write.
Build session checkpoints into any long-running authoring task. Before starting a complex pipeline build in Claude Code, we now export the current workflow JSON and paste it into a local file. If the session drops, we have a restore point. This is obvious in retrospect, but we lost an hour of iteration before we started doing it.
Define the integration boundary before you start, not after. The question isn't "what can Claude Code do with MCP?" - it's "which specific steps in our current process would benefit from a reasoning model with tool access, and which steps need a dedicated system?" We should have mapped that before wiring anything in. The teams we've seen get the most out of this setup are the ones who treated it as a surgical addition to an existing pipeline, not a wholesale replacement of one.