A CIO maintains separate plugins so that four AI assistants can reach the same eight internal systems, and every API change in one system means updating several plugins. Which benefit does moving to MCP servers mainly bring?
Select an answer to reveal the explanation.
Short Explanation
With per-assistant plugins, one API change ripples through every plugin you own. Put an MCP server in front of the system and you fix it in one place while every assistant keeps calling the same interface. The token-sharing option should set off alarm bells.
Full Explanation
A standard interface reduces maintenance as well as initial integration. When each internal system sits behind one MCP server, the server is the only component that knows the system's native API. An API change is handled once inside that server, while the MCP tools, resources and prompts it exposes can stay stable, so all four assistants keep working through their own clients without being touched. Caching a previous API version is not something MCP does; result caching via ttlMs and cacheScope is a freshness hint for list and read results, not a way to preserve an obsolete backend API. Regenerating plugins from tool annotations misunderstands annotations, which are untrusted behavioural hints such as readOnlyHint and destructiveHint, not code-generation inputs, and there are no per-assistant plugins left to regenerate. Sharing one token across systems is a security anti-pattern; MCP authorization binds tokens to a specific server through the resource parameter and audience validation, and token passthrough is forbidden. Exam caveat: if a backend change alters a tool's meaning or schema, the server's tool definitions do change, and hosts may need to refresh their lists, ideally prompted by a list-changed notification. Operational check: after a backend API change, confirm only the affected server was redeployed and that each assistant's tools/list and tools/call still succeed.