Before adopting the Model Context Protocol (MCP), a company had built a separate bespoke integration connecting its coding-assistant agent to each of a Git server, a database, and an internal ticketing API -- three different one-off connectors, each written specifically for that one agent and that one system. MCP's host-client-server architecture instead has the host application create one client per server, with each client keeping a connection to exactly one server. What problem is this specifically designed to solve?
- It replaces separate one-off integrations, one per agent-to-tool pairing, with a shared protocol that any MCP-compatible host can speak to any MCP-compatible server, so a new tool only needs to be exposed once as a server rather than re-integrated for every agent that wants to use it
- It removes the need for any security boundary between the agent and the systems it connects to, since MCP's stateless request format already guarantees every request is safe to run without further checks
- It requires that a single MCP server be shared across every client in the host, so that all the tools from the Git server, the database, and the ticketing API are merged into one server implementation
- It guarantees the coding-assistant agent will never need to be given more than one tool at a time, since MCP only allows a single tool call to be issued per client
Why A? And why not the others?
Correct answer: A. It replaces separate one-off integrations, one per agent-to-tool pairing, with a shared protocol that any MCP-compatible host can speak to any MCP-compatible server, so a new tool only needs to be exposed once as a server rather than re-integrated for every agent that wants to use it
MCP standardizes the connection between an AI application (a host) and an external system's capabilities (a server), so that instead of writing a bespoke integration for every agent-to-tool pairing, a system exposes its capabilities once as an MCP server and any MCP-compatible host can connect to it through a client, cutting many bespoke one-off integrations down to shared servers plus hosts speaking one common protocol. The option describing removed security boundaries is wrong: MCP's architecture explicitly maintains clear security boundaries and isolates each server so it cannot read the whole conversation or see into other servers, the opposite of removing checks. The option describing one shared server merging every capability is wrong: the architecture's own model gives each client a 1:1 relationship with a particular server, precisely so the Git, database, and ticketing capabilities can stay as separate, independently composable servers rather than being merged into one. The option limiting an agent to one tool call per client is wrong: nothing about the client-server connection topology caps how many tool calls a client can make to its server.
Source: Model Context Protocol specification, 'Architecture' (modelcontextprotocol.io/specification/2026-07-28/architecture): 'client-host-server architecture where each host can run multiple client instances'; 'each client having a 1:1 relationship with a particular server'; 'Servers should not be able to read the whole conversation, nor see into other servers'