An architect prefers several small single-purpose MCP servers for calendar, email and file storage over one monolithic server. Which MCP property supports this design?
Select an answer to reveal the explanation.
Short Explanation
Think of LEGO bricks: each one is simple, and you snap together exactly what you need. MCP lets your host combine small focused servers, each with its own client. The traps claim servers share sessions or talk to each other behind the host's back.
Full Explanation
Composability is one of the goals the specification lists: MCP provides a standardized way to build composable integrations and workflows. Because a host creates a separate client for each server and every server speaks the same protocol, an architecture of small, focused servers works naturally. Each server can be developed, versioned, secured and replaced independently, and the host aggregates their tools, resources and prompts for the model. A limit of one server per host does not exist; the architecture explicitly shows a host managing many clients, each connected to its own server. Shared protocol sessions between servers are also wrong on two counts: revision 2026-07-28 has no protocol sessions at all, and state that spans requests must be carried by explicit identifiers passed on each request. Servers calling one another directly over MCP to finish work misdescribes the model; servers do not see each other through the host, and the host coordinates the work while enforcing consent and isolation. Exam caveat: when aggregating tools from several servers, name collisions can occur, and clients SHOULD apply a disambiguation strategy such as prefixing tool names with a server identifier. Operational check: confirm each focused server appears as its own client connection in the host, and that removing one leaves the others fully functional.