A company runs five internal AI assistants, and each one needs to reach the same twelve internal systems. Building a custom connector for every assistant-and-system pair would mean sixty integrations to maintain. Which outcome does adopting MCP primarily deliver here?
Select an answer to reveal the explanation.
Short Explanation
Think of it like a power strip standard: once every plug and every socket follows the same shape, you stop building custom adapters for each pairing. Each system gets one MCP server and each assistant speaks MCP once, so your sixty connectors collapse to seventeen implementations. Don't fall for the 'one big client' idea — MCP uses one client per server.
Full Explanation
MCP turns a many-to-many integration problem into a many-plus-many one. Each of the twelve systems is exposed once as an MCP server, and each of the five assistants (hosts) implements the protocol once; any conforming host can then use any conforming server. The integration count grows with the sum of hosts and systems rather than their product, which is the central economic argument for a shared protocol. A single central client holding connections to all twelve systems contradicts the architecture: a host creates one MCP client per server, each with a dedicated connection, so the client count follows the server count. Merging the systems into one server is not required; MCP is designed for composing many focused servers, and consolidation would only recreate a monolith. MCP also does not generate connectors from API documentation; someone still writes each server, but only once, and it is reused everywhere. Exam caveat: the arithmetic in a stem is illustrative, and the concept being tested is reuse through a common interface rather than any exact integration count. Operational check: list the systems that need AI access, confirm each has or will get exactly one MCP server, and verify that every assistant reaches them through its own per-server client instead of a bespoke connector.