An internal ticketing system must become usable from three different AI assistants without writing a separate plugin for each assistant. Which approach fits MCP's architecture?
Select an answer to reveal the explanation.
Short Explanation
Get the direction right: the ticketing system is the thing being offered, so it's the server, and each assistant reaches in with its own client. You build the server once and all three hosts can plug into it. The backwards option — a client inside the ticketing system — is the trap.
Full Explanation
In MCP the server is the program that provides context and capabilities, and the host is the AI application that creates one MCP client for each server it connects to. The ticketing system should therefore be exposed as a single MCP server, offering tools such as creating or updating tickets and perhaps resources for ticket details. Each assistant's host then instantiates its own client to that server, so no assistant-specific plugin is required. Embedding ticketing logic in every host repeats the integration three times, which is exactly what MCP is meant to avoid. Placing an MCP client inside the ticketing system reverses the roles: clients live in hosts and connect to servers, while the system offering capabilities acts as the server. Exposing the API as a prompt misuses that primitive; prompts are user-selected message templates, not a way to execute actions, and having a model compose raw HTTP calls bypasses tool schemas, validation and host consent. Exam caveat: a remote server over Streamable HTTP can be shared by many hosts, while a stdio server is launched as a subprocess per client. Operational check: confirm each assistant lists the ticketing tools through tools/list on its own client and that no assistant carries bespoke ticketing code.