MCP (Model Context Protocol) looks clean on paper. The moment you wire it into a real content pipeline with a custom CMS and a third-party automation layer, the gaps show up fast.
What MCP Actually Promises
Anthropic's Model Context Protocol is a standardized interface for connecting AI models to external tools and data sources. The pitch is simple: define a server, expose tools, let the model call them. The official docs walk through a handful of clean reference examples, mostly local filesystem or SQLite demos. Those examples work. Production environments, however, involve custom REST APIs, multi-tenant auth, and automation platforms that were never designed with MCP in mind.
The protocol itself is solid. JSON-RPC over stdio or HTTP, a well-defined tool schema, and a consistent response envelope. The real complexity lives in the integration layer, not the spec.
Where the Docs Fall Short
The official MCP documentation, as of mid-2025, covers the happy path well. It does not cover what happens when your CMS requires per-tenant API keys, when your tool server needs to stay stateless across cloud function invocations, or when the client calling your server is a Make.com HTTP module rather than a first-party Claude desktop client.
A few specific friction points that come up repeatedly in developer forums and community threads:
- Auth is entirely your problem. The spec says nothing about how to pass credentials. Developers working with custom CMS endpoints have reported needing to thread API keys through tool call arguments, request headers, or environment variables depending on the host. There is no standard pattern, and the docs do not pick one.
- Error handling is underspecified. When a tool call fails, the protocol returns an error object, but the shape of that object is loose enough that clients handle it inconsistently. Claude's own client surfaces errors differently than a Make.com HTTP module parsing the same response.
- Stateless servers behave differently than the examples suggest. Most reference implementations assume a persistent process. Deploy the same server to a Vercel serverless function or a cloud routine and you lose any in-memory state between calls, which breaks patterns the docs implicitly rely on.
Make.com as an MCP Client: What to Expect
Make.com added MCP support as part of its broader AI tooling push in 2025. In theory, a Make scenario can act as an MCP client, calling tools exposed by any compliant server. In practice, the integration has rough edges.
The Make HTTP module can construct valid JSON-RPC requests and parse responses, but it does not natively understand the MCP session lifecycle. Developers who have documented this in community posts note that you need to manage the initialize handshake manually, either by hardcoding it as the first module in the scenario or by building a sub-flow that handles it conditionally. The Make MCP connector module, where it exists, abstracts some of this, but the abstraction is incomplete for anything beyond simple tool calls.
One pattern that holds up better: expose your MCP server behind a plain REST endpoint that wraps the JSON-RPC layer, then call that from Make. You lose some protocol fidelity, but you gain predictable behavior in a platform that was not designed for stateful AI protocol sessions.
Custom CMS Endpoints: The Real Integration Work
Publishing to a headless CMS via MCP requires mapping the CMS's data model to MCP tool schemas. For a system like the Tuscan CMS, built on Next.js and Supabase, that means defining tools that match the CMS API's expected request shape, including required fields, optional metadata, and content type routing.
A few things developers consistently underestimate at this stage:
- Field validation happens twice. The MCP tool schema validates the model's input, and then the CMS API validates again on ingest. Mismatches between the two produce silent failures or cryptic 422 errors. The fix is keeping the tool schema as a strict subset of what the API accepts.
- Enum fields need explicit lists. If your CMS uses enum values for categories or content types, those values need to be listed explicitly in the tool schema. Models will hallucinate plausible-sounding values if the schema does not constrain them.
- Image routing is a separate problem. MCP tools can write content records, but they cannot resolve image sources. Any pipeline that needs featured images has to handle that in a separate step, either before the MCP call or as a post-publish webhook.
What Actually Works in a Cloud Routine Context
Agencies running AI content pipelines as scheduled cloud routines, rather than interactive Claude desktop sessions, face a different constraint set. The model is not in a conversation. It is executing a defined sequence, calling tools, and writing output. MCP works in this context, but the architecture looks different from the docs.
The patterns that hold up are: stateless tool servers deployed as simple API routes, explicit tool schemas with no ambiguity, and a calling harness that manages the full MCP session lifecycle in code rather than relying on a client to do it. GitHub Actions, Vercel cron jobs, and similar runners all work as execution environments as long as the server is reachable over HTTP and auth is handled at the request level.
The patterns that break are: anything that assumes a persistent server process, streaming responses where the runner does not support them, and tool schemas that leave optional fields underdefined enough for the model to fill them with unexpected values.
The Practical Takeaway
MCP is a real standard worth building on. The protocol is stable, the tooling is improving, and Anthropic is actively filling documentation gaps. The honest framing for agencies considering it now: budget the integration work at two to three times what the docs imply, particularly if your stack includes a custom CMS, a multi-tenant auth model, or Make.com as the automation layer. The spec works. The edges around it are where the real engineering happens.
