A startup hesitates to build an MCP server because it assumes the server must plan multi-step workflows, coordinate other servers and manage the model. What does the MCP design say about this division of work?
Select an answer to reveal the explanation.
Short Explanation
Building a server should feel like building one good tool, not a whole factory. The host does the orchestrating and the server just does its job well. Don't let 'agentic' scare you into embedding a planner.
Full Explanation
The first MCP design principle is that servers should be extremely easy to build. Host applications handle complex orchestration responsibilities, servers focus on specific and well-defined capabilities, simple interfaces minimize implementation overhead, and clear separation enables maintainable code. A second principle reinforces this: servers should be highly composable, each providing focused functionality in isolation so that multiple servers can be combined seamlessly by the host. A startup can therefore build a server that exposes a few clear tools or resources without writing any planning logic. Requiring each server to orchestrate its peers and embed its own model contradicts both principles; servers do not see into other servers, and cross-server interactions are controlled by the host. A shared registry helps people discover servers, but it does not move orchestration into servers or make servers coordinate one another. Holding conversation state is a host responsibility, since the full history stays with the host, and the 2026-07-28 protocol is stateless with no protocol-level session for a server to keep. Exam caveat: a server can still keep application state across calls, but it does so through explicit handles passed as tool arguments, not by owning the conversation. Operational check: review the server's design and confirm it exposes focused primitives with no dependency on other servers or on an embedded model.