An AI governance reviewer must decide whether employees may connect their AI assistant to a new third-party remote MCP server that offers CRM tools. What should the reviewer examine before approving it?
Select an answer to reveal the explanation.
Short Explanation
Think of it like vetting a new contractor: you check which keys they're asking for and which rooms they can walk into, not the name on their badge. The trap is trusting self-reported identity, a registry listing, or tool annotations as if they were guarantees, because none of them enforce anything.
Full Explanation
Approving a remote MCP server is a risk decision about access. The scopes the server requests during authorization define what the client's token can do, and the tools and resources it exposes define which business data the model can read or change. Tool annotations such as readOnlyHint and destructiveHint help classify risk, but the specification calls them hints that are untrusted unless the server itself is trusted, so they inform the review rather than settle it. Self-reported serverInfo is explicitly unverified and intended for display and debugging; MCP says implementations should not base security decisions on it. A listing in the official registry proves namespace ownership, not safety: the registry delegates code scanning to package registries and downstream aggregators. Roots are informational boundaries, deprecated in this revision, and never an access-control mechanism, so they cannot limit what a server can technically reach. Exam caveat: least privilege applies on both sides, so the reviewer should also expect the host to enforce consent for each tool call. Operational check: list the scopes in the server's challenge or metadata, map every tool and resource to the data it touches, and flag tools whose annotations are missing or claim read-only behaviour that the documentation contradicts.