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

A developer built an MCP server for a ticket system to explore how the Model Context Protocol lets AI hosts connect to domain systems under controlled permissions. The project documents MCP's foundations, including its host-client-server architecture, JSON-RPC 2.0 core, and resources, prompts, and tools components, ahead of a second part applying them to a responsible, secured interface. The work cites Anthropic's November 2024 introduction of MCP as a response to fragmented point-to-point integrations between AI assistants and data sources.

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 that question. MCP provides an open standard for a shared approach across hosts Model Context Protocol, 2026a . That 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 . This first article documents the foundations I needed to clarify for my project. It answers the questions that arise at the beginning: What is MCP? Which problem does it solve? And how does a user question reach the data of a domain system? Part 2 applies these foundations to my project's MCP server and examines how a responsible interface can be designed and secured from them. 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 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 . This shared description does not replace the three special integrations by magic. It does avoid making every host reinvent the same domain capability. The control boundary remains essential: the host determines which offers it exposes to the model, which results enter the model context, and which calls it permits. The visibility of a call and the point at which consent is needed are decisions of the particular host implementation. Section 3 examines the three concepts more closely. In the ticket example, MCP does not replace the existing ticket API. Instead, it exposes selected capabilities of the system in a form that an AI host can understand and use in a controlled manner. An MCP server is therefore not an additional product API in the usual sense; it is an AI-oriented integration surface. Its purpose is not to expose as many functions as possible. It should shape context, prompt templates, and tools so that a host can use them in a comprehensible and bounded way. The exact design of approvals, logging, and audit remains the responsibility of the specific host and server implementations. This leads to a simple architectural rule: design an MCP server from the domain system outward, not from the language model inward. For a ticket system, that means first clarifying which tickets a user may see, which actions have an effect, which inputs are valid, and which results may enter the model context at all. A useful selection of tools and resources emerges only from those boundaries. 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. Important: MCP standardises the exchange between host and server, not the security of a domain system. A responsible host implementation must design approvals, data sharing, and the admission of content into context. A production server must itself implement authentication, domain permissions, data minimisation, and audit. The protocol provides boundaries and recommendations, but not a ready-made security architecture Model Context Protocol, 2026a; Model Context Protocol, 2026e; Model Context Protocol, 2026f . 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. Figure 1: Simplified MCP architecture. Inside the host, the LLM proposes an action; the MCP client transmits only the call permitted by the host. Results first return to the host and, from there, to its model context. 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 Language Server Protocol LSP is a helpful analogy. LSP was an explicit inspiration for MCP—not as a technical predecessor or direct extension, but because of its integration principle. LSP did not make all editors and programming languages the same. It created a shared integration contract: a defined language for the requests an editor can make and the answers a language server can provide. Editors and language servers no longer need bespoke knowledge of every counterpart. MCP applies that idea to context and tools for AI applications Model Context Protocol, 2026a; Microsoft, 2026 . Let us walk through Figure 1 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. The central information flow is therefore clear: MCP is not a direct tunnel from the model into the ticket system. The host controls which model proposals become MCP calls; the server enforces the domain and security boundaries toward the target system. Both sides must implement their responsibilities concretely. 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 in Figure 1; the details for production remote servers belong in Part 2 Model Context Protocol, 2026b; Model Context Protocol, 2026g; Model Context Protocol, 2026h . An MCP server does not simply deliver “data to AI.” It provides several clearly separate things to the host. For this introductory article, five guiding questions are enough. How does the host discover what a server can do? Which data objects can it read as context? Which work instructions can it adopt as prompt templates? Which functions can it have executed as tools? And which transport do client and server use to communicate? In MCP, these building blocks are called discovery, resources, prompts, tools, and transport. At first, the terms may sound similar. They mark different points in the information flow shown in Figure 1. Before a host can use a capability meaningfully, it needs to know what a server offers. In the current specification, that capability negotiation is not a connection-bound opening dialogue; it happens per request. Clients send their protocol version, client information, and capabilities as metadata with each request. They can also query supported protocol versions, capabilities, and server information in advance with server/discover Model Context Protocol, 2026b . In the ticket example, the server can therefore make visible that it supports context objects, prompt templates, and executable tools. The specific set of tools may depend on the authorisation context: a product manager might see search tickets and list ticket comments , but not an administrative export tool. The specification explicitly permits the returned tool or resource list to depend on the request's credentials, provided it does not depend covertly on the state of a connection Model Context Protocol, 2026c; Model Context Protocol, 2026e . Discovery does not replace authorisation. It merely prevents false expectations. The server must still check every later call on the server side. Resources are context objects. The specification describes them as a standardised way to provide data to clients, including files, database schemas, or application-specific information. Each resource is identified by a URI. Clients can list and read resources and, where the server supports it, receive notifications when resources change Model Context Protocol, 2026c . In the ticket example, an individual ticket might appear as ticket://ONB-123 . That resource is not automatically a fact in the model's awareness. The host decides whether to offer it to the user for selection, load it as the result of a search, or insert it into the model conversation as context. The separation matters: a resource makes context discoverable and referenceable, but it does not force the host to pour everything into the model without filtering. Good resources are narrow and understandable. A ticket object containing a title, status, assignee, short description, and link is usually more helpful than an undifferentiated database dump. The better a resource is scoped, the easier it is for the host to support data minimisation, source display, and user control. Prompts are reusable, parameterised work instructions. In substance, such a template can be an ordinary prompt a person could also write. The specification describes them as prompt templates that servers provide to clients; hosts may, for example, offer them as selectable actions in their interface Model Context Protocol, 2026d . In the ticket example, the MCP server could offer a prompt named analyze onboarding tickets : “Analyse tickets on {topic} . Group the findings into risks, open decisions, and next steps. Name sources for every claim.” As an MCP prompt, this instruction is more than copyable text: it has a stable name, describes expected parameters such as topic or output style , and can be discovered by the host. A chat client, IDE, and agent tool can then use the same domain-maintained template instead of each carrying its own variant. When a host uses the template, it retrieves it from the server, fills in its parameters, and can add the resulting messages to the model context. The template may be static or vary with its parameters and the authorisation context. It does not, however, start an analysis: at that stage, the MCP server has not read tickets, drawn conclusions, or formulated an answer. That is more than an implementation detail. A prompt parameter configures a work instruction; arguments to a tool call such as search tickets , by contrast, determine a server-side domain operation. Keeping the two separate prevents prompts and tools from being confused. A prompt template also does not technically assign tools. The host exposes the tools permitted by its policy; based on the instruction, the LLM decides which ones to propose. The host then checks every concrete tool proposal. Tools are executable functions. They can query databases, call APIs, perform calculations, or prepare domain actions. The specification describes tools as model-controlled: a model can discover available tools and call them based on context. At the same time, it emphasises that applications should make tool calls visible and allow people to reject or confirm relevant operations Model Context Protocol, 2026e . For the host, tools initially are a list of described capabilities. Their names, purposes, and expected parameters tell both the host and LLM what a tool can do. The host exposes only the tools that its policy permits. The LLM compares the user's question, the existing context, and those descriptions, then proposes a suitable tool with concrete arguments. For a ticket analysis, it might first choose search tickets , then retrieve details with get ticket , and propose list ticket comments if required. The selection is therefore a model decision based on clear tool descriptions; execution nevertheless remains with the host and server. In the ticket example, search tickets , get ticket , and list ticket comments are good initial tools. They are named in domain terms, read-only, bounded, and easy to explain. A generic query database would be much riskier: it moves too much semantics into a free-form query string and makes the permission model, input validation, and audit more difficult. For an initial production setup, the ticket server should therefore begin with narrowly described read tools. This is not a mandatory MCP sequence; it is a derived security decision. The MCP specification stresses visibility and human rejection or confirmation for tool calls. For plugin and API integration contexts, OpenAI additionally sets expectations for clear tool definitions, correct annotations, data-minimising inputs where possible, and server-side authorisation for every request Model Context Protocol, 2026e; OpenAI, 2026b; OpenAI, 2026c . In practical terms, a later add internal comment tool can be justified if it has a distinct write scope, project binding, maximum length, internal visibility, structured errors, correct read-only/destructive annotations, and audit without full text. A change ticket status tool is riskier because it changes a workflow. At a minimum, it needs a concrete preview, explicit approval, retry safety or recognisable non-idempotency, and audit correlation OpenAI, 2026b; OpenAI, 2026c . Resources, prompts, and tools describe what an MCP server offers. Transport answers the other, simpler question: how do protocol messages move between the host and server? It changes neither the roles in Figure 1 nor the domain responsibility; it is only the technical path of transmission. The 2026-07-28 specification names two standard paths. With stdio , the host starts the MCP server as a local process and exchanges messages through its standard input and output. This suits local developer tools, such as those for files, Git, or builds. With Streamable HTTP, the MCP server runs as a reachable service and host and server communicate over a web connection. That better suits SaaS services, enterprise applications, and other remote systems Model Context Protocol, 2026h . For a basic understanding, that distinction is enough: stdio is typically local and process-adjacent; Streamable HTTP is typically remote and network-based. The exact transport technology and the operational requirements of a production remote server—such as HTTPS, authentication, rate limits, and monitoring—belong in Part 2. So far, the focus has been on understanding the architecture: who talks to whom, when data enters the model context, and why MCP is not a direct tunnel from the model to the target system. The central insight is this: the value of an MCP server does not arise from tools alone, but from the controlled path between the AI host and the domain system. Part 2 will therefore ask more than how to program tools. It will show how an existing domain API can become a responsible MCP surface: which capability should become a tool, which information a resource, and how to prevent a helpful assistant from gaining uncontrolled access to far-reaching actions. This is an English adaptation of the German original, MCP-Server verstehen: Wie KI-Hosts kontrolliert mit Fachsystemen sprechen https://www.cherware.de/mcp-server-verstehen/ , published on my blog. It is an introductory technical article, not a complete design or security guide for production MCP servers.