Understanding MCP Servers: How AI Hosts Reliably Connect to Domain Systems

Understanding MCP Servers: How AI Hosts Reliably Connect to Domain Systems

How Can an LLM Gain Controlled Access to Current Data and Permitted Actions?

Anyone who wants to integrate AI into their own system-or make information held there available to an LLM-quickly encounters the question of how to gain controlled access to current data and permitted actions. MCP provides an open standard for a shared approach across hosts (Model Context Protocol, 2026a). This is why I have examined the Model Context Protocol more closely in my own project. Work on an MCP server is already well advanced; this article documents the foundations that need to be understood first.

My starting point was not how to implement a server as quickly as possible, but what MCP actually is, how it works, and whether it fits a domain system. The practical problem is straightforward. A model does not automatically know current tickets, permissions, domain terminology, or internal tools. Without controlled access, it is left with guesses, copied context, or another one-off integration. Before MCP, every AI application needed its own bridge: a chat client to a ticket system, an IDE to a file system, an agent script to a REST API. Each could work locally. Together, they formed a difficult-to-maintain tangle of duplicate tool descriptions, different authentication paths, and security decisions that could barely be reused.

When MCP was introduced in November 2024, Anthropic described precisely this problem of fragmented point-to-point integrations between AI assistants and data sources (Anthropic, 2024). MCP addresses that point. The 2026-07-28 specification defines an open protocol for connecting LLM applications to external data sources and tools: through a host-client-server architecture, JSON-RPC 2.0, a stateless protocol core, and components such as resources, prompts, and tools (JSON-RPC Working Group, 2013; Model Context Protocol, 2026a; Model Context Protocol, 2026b).

Why MCP?

MCP becomes tangible when we start with a practical need. An AI application should not merely talk about a domain system; where appropriate, it should work with the system's current data and permitted functions. It therefore needs to know which information it may request, which actions are allowed, and under what limits they take place. An AI host-the application that coordinates the model, context, and MCP connections-organises that path. A shared language is needed so that the path does not have to be rebuilt for every AI application.

The Concrete Problem

The example in this article is not fictional. I use the ticket system being developed as part of my project. I built an MCP server for it, which provides the practical frame for this article series. The server can connect an AI host-such as a chat client, IDE, or agent tool-to the ticket system, whose data and actions should be available only within the applicable permissions. A user might ask the AI host: “What risks, open decisions, and next steps emerge from all tickets related to customer onboarding?” The expected answer should be grounded in current, authorised data from the ticket system.

Without a common standard, every host needs a separate route: perhaps a plugin for the chat client, a direct REST integration for the IDE, and a dedicated API client for an agent script. To users, the result may initially look similar: all three can search tickets. To the team behind them, however, it means three sets of tool descriptions, three input-validation paths, and often three different ways to handle authentication, permissions, and logging. If the ticket model or a security rule later changes, every integration must determine what changed. Each variant may work in isolation; collectively they create a hard-to-maintain network in which domain objects are described repeatedly, security decisions are difficult to compare, and little can be reused between hosts.

This is where MCP starts. The server describes its capabilities once in a shared form that compatible hosts can read. A host can first discover what the server offers and then decide, in a controlled way, what to use for a particular request. In the ticket example, three kinds of offer are easy to distinguish: resources are readable context objects, such as an individual ticket; prompts are reusable work templates, for example for a risk analysis; and tools perform clearly named domain operations, such as search_tickets, get_ticket, or list_ticket_comments (Model Context Protocol, 2026b; Model Context Protocol, 2026c; Model Context Protocol, 2026d; Model Context Protocol, 2026e).

What MCP Is Not

The distinction may sound dry, but it matters: MCP adds a shared integration contract to existing layers. It does not replace them. MCP is not a product API. REST or GraphQL often remain a system's primary interfaces. MCP offers an AI host only selected capabilities in a suitable form-“search tickets,” for example, rather than the ticket system's complete public API.

MCP is not an agent framework and not a workflow engine. It does not plan goals, choose multi-step strategies, or execute business processes as its own workflow machine. Whether several tools are combined, follow-up questions are asked, or work steps are planned is decided by the host, the model, or an agent system above it.

MCP is not a database. Resources can make data visible as context, but they do not replace storage, search, transaction logic, the data model, or the target system's permission system. Tickets in the example remain tickets of the domain system, even if the host can read individual ones.

MCP is not a complete plugin system. Installation, distribution, user interface, permission dialogues, and product integration sit above the protocol. A product may use MCP for an integration and build a plugin experience around it. OpenAI, for example, distinguishes its own connectors from arbitrary remote MCP servers; that is an OpenAI-specific product category, not part of the MCP specification (OpenAI, 2026a).

And MCP is not AI. An MCP server does not need to contain a language model. It provides context and capabilities; interpreting the user's question and generating an answer happen in the host's LLM context.

The Architecture Map

The following diagram is the most useful point of orientation for the rest of the article. It deliberately shows the higher level: the host contains the LLM and MCP client, and it remains the control boundary between the user request, model, and domain system.

The Roles

The host is the AI application: a chat client, IDE, or agent tool, for example. It coordinates the user request, model context, tool selection, approvals, and answer output. The specification describes the host as a container and coordinator that manages client instances, enforces security and consent requirements, and aggregates context (Model Context Protocol, 2026b).

The MCP client lives inside the host. It mediates protocol messages between the host and exactly one MCP server. A host can have several clients: one for tickets, one for documentation, and one for Git, for example.

The MCP server provides specialised capabilities. It makes resources, prompts, and tools available and translates calls into domain operations against the target system. A production server must validate incoming requests within its own authentication, authorisation, and domain boundaries.

The target system is the actual application: a ticket system, documentation platform, database, monitoring system, or internal operational system. The LLM formulates answers and can propose tool calls. It is not itself the MCP server and does not access the target system directly. That separation is the core of the architecture.

The Flow of an MCP Request

Let us walk through the architecture using the ticket example. A product manager asks the AI host: “What risks, open decisions, and next steps emerge from all tickets related to customer onboarding?” For that person, it is an ordinary question. Technically, however, it moves through a controlled chain-not a direct line from the model to the ticket system.

First: the host builds context. It assembles the information the model should work from: the user's question, persistent application rules such as security and formatting requirements, and the selected MCP capabilities. It may optionally retrieve a prompt template provided by the server and add it to the model context. No ticket has been read at this point.

Second: the LLM proposes what is needed next. If the existing context is enough, it can answer directly or formulate a follow-up question. If it needs current or more detailed information, it can propose a suitable tool call-for example, search_tickets with { "topic": "customer onboarding", "limit": 20 }. If a returned ticket refers to two other tickets, the LLM can then propose get_ticket for them after the first result. Such a proposal is still not an executed domain operation.

Third: the host permits the call-or does not. Its concrete policy determines which tools are visible, which arguments are accepted, and whether the user must approve the action. If the call is permitted, the MCP client sends it to the MCP server as a JSON-RPC message. The target system behind it may still use REST, database access, or another internal interface (Model Context Protocol, 2026b; Model Context Protocol, 2026h).

Fourth: the server performs the domain operation within its own boundaries. A production ticket server must itself enforce authentication, domain permissions, project boundaries, and limits; MCP does not remove that responsibility. It calls the target system and prepares a bounded, structured result for the host.

Fifth: the host decides whether to return the result to the model context. Only then can the LLM evaluate the permitted ticket data, propose another call where necessary, or formulate the answer.

An Important Versioning Nuance

This article refers to the MCP specification 2026-07-28. That revision describes MCP as stateless: there is no protocol state bound to a connection, and each request carries its own protocol information. Older clients and servers may still use the previous session-based protocol. This does not change the architecture; the details for production remote servers belong in Part 2 (Model Context Protocol, 2026b; Model Context Protocol, 2026g; Model Context Protocol, 2026h).

What Flows Through an MCP Server

An MCP server does not simply deliver “data to AI.” It provides several clearly separate things