MCP: how AI assistants work with platforms

A language model knows a lot about the world and nothing about your platform. It knows neither today’s registrations nor the draft the editorial team is working on right now. To work with them, it needs a connection. Until now, each of these connections was a one-off: one integration for this assistant and this system, another for the next pair. With ten assistants and ten systems, that makes a hundred integrations, and each one needs maintaining.

One language for all

The Model Context Protocol, MCP for short, defines how an AI assistant talks to another system. It was introduced as an open standard at the end of 2024. It is now supported by the assistants of the major language model providers as well as by common development environments. Since December 2025 it has belonged to the Agentic AI Foundation under the umbrella of the Linux Foundation, and so no longer to any single provider. A system that speaks MCP can be reached by all these assistants. A hundred integrations become twenty: ten assistants and ten systems that have agreed on the same language.

How assistant and system talk to each other

On one side is the application you work in, such as a provider’s assistant or a development environment. On the other side is a platform or a service. Through the MCP interface, the system shows what it offers:

• Tools: actions the assistant can trigger, such as creating a draft or querying data.
• Resources: content to read, such as pages, documents or records.
• Prompt templates: prepared tasks that the system supplies along with it.

Each tool carries a description in plain language. From this, the model recognises which tool fits the question and calls it. The system does the rest. It checks the authentication, fetches the data and returns the result. The thinking is done by the language model behind the assistant; the system only executes. If both run on the same machine, they talk to each other directly; over the network it works via HTTP, with authentication via OAuth.

The connection itself is quick to set up. If you use an assistant yourself, you grant it access when connecting it and define what it may do. After that, it works with these permissions, not with your account. It is different when an agent works with the platform on its own, for example in an automated workflow. Then the MCP interface sits in the configuration of its agent system (often called a harness). That is where it is defined how the agent authenticates and which tools it may use, with its own credentials rather than those of a person. Simplified, it looks like this:

{
    "agent": "agent-x",
    "mcp": {
        "stack": {
            "url": "https://stack.yourcompany.ch/mcp",
            "auth": {
                "type": "oauth2",
                "client_id": "agent-x",
                "client_secret": "${STACK_AGENT_SECRET}"
            },
            "tools": ["page.read", "page.draft", "data.query"]
        }
    }
}

The configuration governs access. How the agent should use the tools is set out in its system prompt, in plain language:

You are Agent X and prepare promotional pages in Example AG’s Stack CMS.

Through the ‘stack’ interface you can reach pages and sales data.
- Read a page with page.read before you suggest anything on it.
- Get sales figures with data.query, never from memory.
- Create changes only as drafts with page.draft.
  Publishing is not your job, the editorial team approves.
- If a piece of information is missing, ask instead of making it up.

The configuration determines what the agent can reach, the system prompt how it uses it. What it is actually allowed to change is still decided by the platform.

What the assistant may do

MCP governs how assistant and system talk to each other. It does not govern what the assistant may see and change. That is decided by the platform, and that is where we come in with the stack:

• The assistant gets its own permissions, separate from the user accounts. You configure individually what it may read and change.
• If it wants to change something, you get a preview first. You accept or discard, and every change can be undone. There is no tool for publishing.
• Which language model works behind the assistant is a separate decision. If it uses an external provider’s model, its queries go to that provider. If you don’t want that, you use a model that we operate in Switzerland.
• If the assistant calls one of the stack’s tools, for example for translating, that tool works with the tenant’s glossary and with the models we operate in Switzerland.

Where we use MCP in the stack

With the next generation of the stack, which we will roll out from 2027, an MCP interface is part of the standard equipment of every platform. These uses are planned:

• Editorial work: your own agent reads pages and blocks in Stack CMS, creates drafts and pre-fills language versions. The editorial team reviews and approves as with any other draft.
• Data: questions about the data behind the platform, asked in plain language, for example: which organisations registered for the first time this year? The assistant runs the query and, on request, produces an analysis.
• Visitor agents: every website on the stack gets a public MCP interface and an llms.txt file. AI search tools use them to read the published content in a structured way instead of guessing it from the layout. The agent and the language model are operated by the other side, not by us.

We already work this way internally: our assistants read tickets and documentation directly from Jira and Confluence via MCP. However, an assistant’s answers are only as good as its sources. That is why we are building documentation for our projects that it can query reliably, with a source reference for every statement.

What MCP leaves open

MCP makes access simple. Whether an assistant should use a platform at all, what data it may see and who approves in the end are questions the standard doesn’t answer. We clarify them with you for each platform before the first agent connects. The AI in the stack page shows how an agent works in the content management system in practice.