An enterprise chatbot must answer questions using data from the HR, finance and sales databases, each owned by a different department with its own access rules. Which MCP architecture fits best?
Select an answer to reveal the explanation.
Short Explanation
Each department keeps its own front desk, and your chatbot visits each one with its own pass. The trap is the mega-server with every credential, which turns one compromise into three breaches.
Full Explanation
MCP is built for composition: a host connects to many focused servers, each through a dedicated client, and combines their capabilities for the model. Giving each department its own server keeps ownership, access rules and credentials with the team responsible for that data, while the host aggregates results and enforces consent across them. A single combined server concentrating credentials for every database collapses three trust boundaries into one and forces departments into a shared policy they did not choose. Having the HR server forward its client's token to the other servers is token passthrough, which the authorization rules forbid; each server must accept only tokens issued for its own audience. Sharing one client session across servers misreads the architecture twice: each server gets its own client, and revision 2026-07-28 has no initialize handshake or protocol sessions, since every request carries its own version and capabilities in _meta. Exam caveat: the host, not the servers, sees the whole conversation, so servers should not be able to read each other's data through the protocol. Operational check: confirm each server publishes its own protected resource metadata, that tokens are minted per server audience, and that the host shows the user which server answered each request.