MCP servers explained: the shared contract that lets AI hosts reach domain systems

A developer writing on dev.to has opened a series on the Model Context Protocol (MCP), the open standard that gives AI applications controlled access to external data and tools. Rather than racing to an implementation, the first article works through the foundations: what MCP is, which problem it solves, and how a question posed to an AI host actually reaches data inside a domain system. The author grounds the explanation in a real project — an MCP server built for a ticket system under development.

The problem MCP targets

According to the dev.to piece, a language model has no automatic knowledge of current tickets, internal terminology, permissions or domain tools. Historically, every AI application bridged that gap on its own: a chat client got a plugin for the ticket system, an IDE got a direct REST connection, and an agent script got a bespoke API client. Each integration might work in isolation, but together they multiplied tool descriptions, validation paths, authentication schemes and logging setups. When a data model or security rule changed, every bridge needed separate rework. The article notes that Anthropic introduced MCP in November 2024 precisely to address this fragmentation of point-to-point integrations between AI assistants and data sources.

How the protocol is built

The specification dated 2026-07-28 in the piece rests on a host-client-server architecture, JSON-RPC 2.0 for messaging, and a stateless protocol core. The host — a chat client, IDE or agent tool — coordinates the model, the context and the MCP connections. The decisive move is that a server describes its capabilities once, in a shared form any compatible host can read. A host first discovers what the server offers, then decides in a controlled way what to use for a particular request: which offers reach the model, which results enter the context, and which calls are permitted.

Three primitives: resources, prompts and tools

The article illustrates the component model with its ticket-system example. Resources are readable context objects, such as an individual ticket. Prompts are reusable work templates, for instance a risk-analysis structure. Tools are clearly named domain operations; the piece cites search_tickets, get_ticket and list_ticket_comments. With those primitives, a query like "what risks, open decisions and next steps emerge from tickets about customer onboarding?" can be answered from current, authorised data rather than guesses or copy-pasted context.

What MCP is not

A large part of the article is deliberate delimitation. MCP is not a product API: REST or GraphQL typically remain a system's primary interface, and the server exposes only selected capabilities. It is not an agent framework or workflow engine — planning multi-step work stays with the host, the model or an agent layer above. It is not a database, since resources make data visible as context but do not replace storage, search or the permission system. It is not a complete plugin system; installation, user interface and permission dialogues sit above the protocol, and the author points to OpenAI distinguishing its own connectors from arbitrary remote MCP servers as a product decision, not part of the specification. Finally, MCP is not AI: a server needs no language model of its own.

A design rule for builders

The author's central recommendation is to design a server from the domain system outward rather than from the model inward. For a ticket system, that means first settling which tickets a user may see, which actions have real effects, which inputs are valid, and which results may ever enter model context. Only from those boundaries does a useful selection of tools and resources emerge. Approvals, logging and audit remain the responsibility of each host and server implementation, the piece stresses — the protocol does not decide them.

Why it matters

For teams wiring AI into internal systems, the argument comes down to maintenance economics: one shared capability description replaces a growing pile of per-host bridges, security decisions become comparable instead of scattered, and domain capabilities get described once rather than repeatedly. Equally significant is what MCP leaves out — planning, storage, plugin UX — which keeps the protocol thin and keeps the control boundary in the host, where operators generally want it. As agents move from demos toward production use, that clean split between a standardised integration layer and the systems it exposes is what makes such integrations reviewable and auditable at all.