How is MCP tool trust different from authentication and allow-lists?

Short answer: authentication and allow-lists answer who is allowed to call a tool. They say nothing about whether the tool still does what it declared when you connected it. MCP tool trust is about integrity over time, not identity and permission.

The gap auth does not cover

Auth, OAuth, and allow-lists are access control. They decide whether a caller is permitted. That is necessary, but a permitted call to a tool that has quietly changed its contract is still a problem. A fully authorized call to a server that redefined a tool, same name, now writes instead of reads, passes every auth check you have. The credential was valid. The permission was granted. The tool is not what it was.

Why MCP makes this sharp

MCP servers are remote and updatable with no version bump your client notices. The tools/list you consented to on connect can change on the server side. A re-described tool with the same name is a silent redefinition, and access control waves it through because identity and permission did not change.

What trust over time looks like

Pin each tool's declared contract on first sight. Diff it on every later call. Classify the kind of change, an added required parameter, a read annotation flipping to write, a narrowed constraint, so a benign additive change proceeds and a real redefinition shows up as a specific, actionable difference. Hold the call at the moment of drift, not on the next handshake, because the change can land mid-session.

What this does not replace

This is not a substitute for auth. You still need access control to decide who may call a tool. Trust over time sits next to it and answers the separate question of whether the tool still honors the contract you agreed to. Both matter.

Try it

The drift gate pins and diffs contracts locally and holds on drift. To see the blast radius of the tools you have already connected, run the scan on your mcp.json.