MCP: hosts, clients, and servers
The Model Context Protocol (MCP) defines how AI applications connect to external context and capabilities. It separates the application the user works with, the clients that communicate with servers, and the servers that make data and operations available.
The MCP architecture specification describes a host-client-server model. MCP is an integration protocol. It does not prescribe a complete agent architecture or make every connected system equally trustworthy.
Explore Dome: Tool Gateway · Docs: Tools gateway.
Host, client, and server are different roles
Suppose a desktop application helps an engineer investigate incidents. It connects to a ticket service and a documentation service.
- The MCP host is the application. It coordinates the model interaction, user experience, permissions, and connections.
- An MCP client communicates with a particular server. One host can manage several clients.
- An MCP server makes capabilities available through the protocol. It may run locally or as a remote service.
| Component | In the example |
|---|---|
| Host | The incident-investigation application |
| Client | Its connection component for the ticket server |
| Server | The service exposing ticket operations |
| Backend | The ticket system the server reads or changes |
The server and backend may be separate components. That distinction matters when checking credentials and permissions: the MCP endpoint may authenticate the application while the backend uses a different credential to execute the operation.
An MCP server doesn't need its own language model. It can make an existing service available to an AI application.
Explore Dome: Tool Gateway · Docs: Agent identity.
What tools, resources, and prompts provide
MCP tools expose operations the application can request, such as searching tickets. MCP resources provide contextual data, such as the contents of a document. MCP prompts provide reusable interaction templates.
Discovery tells the application what the server offers. A tool's schema describes its expected arguments; permissions and implementation behavior still need separate checks.
In the incident example, a resource might supply a runbook while a tool retrieves the current status of a ticket. The host decides how to present that information and use those capabilities in the application. The tools specification describes tool discovery and invocation; tool calling explains the broader application execution loop.
Explore Dome: Tool Gateway · Docs: Tools gateway.
Map the connections and where checks happen
Write down where the host runs, how each client reaches its server, and which backend the server can access. Add the credential used at each connection. Then ask which component sees the user, the requested operation, and the business records needed to decide whether the action is allowed.
For a failed ticket update, the map helps you find the relevant check: protocol handling for a malformed message, authentication for an invalid token, or authorization for a forbidden action.
Dome's Tool Gateway can provide a common path for configured tool connections, with its supported protocols and controls described in the Docs. Do not assume that support for tool traffic implies support for every MCP primitive or extension. MCP security explains what to check on each connection. The gateway comparison distinguishes the services that handle tool and model requests.
Explore Dome: Tool Gateway · Docs: Tools gateway.