Contentful's Remote MCP Server: Governed AI Access to Your Content Layer - My Blog

From Answering Questions to Taking Action

For the last couple of years, the interesting question about AI assistants was how good their answers were. That question is settling. The one replacing it is more operational: how does an assistant reach the systems where the work actually lives, without someone hand-rolling an integration for every tool and every user?

The Model Context Protocol is the current answer, and Contentful shipped its Remote MCP server to general availability in July 2026. It is a cloud-hosted, OAuth-secured endpoint that lets an MCP-aware client read and write entries, manage content models, handle assets, and invoke AI Actions across your spaces. No local process, no personal access token pasted into a config file.

I connected it to my own workflow this week. Here is what is actually worth knowing before you do the same.

How a Call Actually Travels

The client never talks to the Content Management API directly. Every tool call passes through the hosted server, which checks the MCP app configuration for the space and environment in play before anything reaches your content.

Remote or Local: Pick Your Trade-off

Contentful runs two servers with the same core toolset. They differ almost entirely in how identity and gating work.

Authentication: the remote server uses OAuth 2.1, so each person signs in as themselves. The local server runs on a Management API personal access token supplied through environment variables.
Identity: remote calls carry the individual user’s identity. Local calls all run as whoever owns the token, which flattens your audit trail to a single actor.
Gating: remote adds a second layer on top of user permissions, an allow-list managed by the Contentful MCP app per space and environment. Local has exactly one boundary: the token itself.
Setup: remote is a URL in a config file. Local means provisioning a token and running a Node process.
Best for: remote suits day-to-day team use where an admin wants central control over exposed tools. Local still wins for scripting, CI, and anywhere OAuth is not an option.

One detail that trips people up: the remote server is useless in a space until the Contentful MCP app is installed and configured there. The app is not a server, it is the permission gate. Installing it alone does nothing either. You need both halves.

Connecting a Client

Most MCP-aware clients need nothing more than the endpoint:

{
  "mcpServers": {
    "contentful": {
      "url": "https://mcp.contentful.com/mcp"
    }
  }
}

On first connect, the client discovers that OAuth is required, sends you to Contentful to sign in, and then asks you to pick the spaces and environments in scope for the session. That last step is not optional and it is not sticky. You select the space and environment pair every single time you connect, even when the MCP app is already installed. Skip it and the session has nothing to operate on.

If your organization is provisioned in the EU, swap in https://mcp.eu.contentful.com/mcp everywhere. Region is fixed by the endpoint you connect to, so authentication and every Management API call stay inside EU infrastructure. There is no in-session switch.

Assets Take Two Phases

MCP tool calls are JSON over HTTP, which means binary files cannot ride along inside one. The remote server splits uploads in two:

Call create_upload_session with no arguments. You get back an upload handle, a URL, and an expiry.
PUT the raw bytes to that URL with a Content-Length header. This endpoint is deliberately unauthenticated, so the handle is the credential. Treat it like a secret.
Call upload_asset with the handle, and the server binds the staged bytes into a real Contentful asset.

Handles expire after an hour and are single-use. Every upload needs a fresh session. If you are connected through ChatGPT, you can skip the session step entirely and call upload_asset directly, because the file gets passed to the server for you.

Failure Modes Worth Knowing in Advance

A tool returns “not allowed”: that category is probably switched off in the MCP app config for that environment. Update the app, then re-run the connection flow.
Environment aliases are not supported. Point at the underlying environment ID directly, or you will get a forbidden error when fetching the app installation.
The browser never opens: usually a stale or revoked token cached in the client. Remove the server and add it back so OAuth starts clean.
EU calls routing oddly: check that every snippet uses the EU endpoint, not the global one.

Where I Would Start

Read-only, and narrowly. Contentful’s own guidance says the same thing, and it is the right instinct. Turn on entries and content types as read-only in one non-production environment, enable human confirmation of tool calls in your client, and spend a week asking questions rather than issuing commands.

The workflows that pay off first are the assessment-heavy ones: auditing entries for missing localization fields before a launch, finding pages with absent alt text, spotting inconsistent metadata across a product release. None of those touch production content, and all of them are tedious enough by hand that you will notice the difference immediately.

Write access is the step after trust, not the step before it. The nice thing about the two-layer model is that it lets you make that a deliberate decision per environment rather than an all-or-nothing switch.

Further reading: Contentful’s MCP server documentation and their general availability announcement. The local server is open source on GitHub.

Contentful’s Remote MCP Server: Governed AI Access to Your Content Layer