What is the difference between an MCP scanner and an MCP gateway?

A scanner answers whether a server or config looks bad at a point in time (pre-install or CI). A gateway answers who may call what, with what secrets, under what policy, at the organization edge. They are complementary. Neither by itself answers whether the live tool contract still matches what you pinned after connect.

What is MCP contract integrity or pin-and-diff?

Pin each tool's declared contract on first sight and diff it on later calls. When the live contract no longer matches the pin, warn or hold before the agent acts. It answers a different question than scanners (point-in-time) and gateways (permission and policy). It cannot catch behavior that changes under a stable schema.

Do I need an MCP scanner, a gateway, or both?

Most teams need a stack, not a single tool. Use a scanner at install and in CI. Use a gateway when you have an org control plane. Add a contract-integrity (pin-and-diff) control in the agent session where silent drift happens. They answer different questions; one does not replace the others.

Is an in-path MCP gate the same as a scanner?

No. In-path describes where a control runs (inside the agent session). A scanner is typically a point-in-time check. Some products span both - for example a scanner that also hash-pins tools or runs a proxy mode. Judge the capability (point-in-time vs permission vs contract integrity), not the product noun.

Can pin-and-diff detect every MCP rug pull or tool change?

No. It catches declared-contract changes: schema, annotations, description. A server that keeps the contract identical and changes behavior underneath is out of scope for client-side contract-diff. Treat that as an honest hard limit.

What do MCP scanners and gateways each catch - and what do they miss?

Short answer: scanners answer "does this look bad right now." Gateways answer "who may call what, under what policy." Neither answers "is this still the tool I pinned." That third question is contract integrity (pin-and-diff), and it is the layer most MCP security listicles under-name.

This is a map of layers, not a ranking. Examples below are illustrative as of July 2026, not a best-of list.

Three layers, three questions

Layer	Question it answers	When it runs	Blind spot
Scanner (point-in-time)	Does this server or config look bad right now?	Pre-install, CI, audit	A silent contract change after a clean scan
Gateway (control plane)	Who may call what, with what secrets, under what policy?	Org edge / every routed call	The unmanaged laptop session where most MCP experimentation still happens; also does not answer "is this still the tool I approved?"
Contract integrity (pin-and-diff)	Is the live tool contract still what I pinned?	In-session, at call time	Behavior that changes under a stable schema (honest hard limit)

"In-path" describes where a contract-integrity control can run (inside the agent session). It is not the name of the layer.

Scanner - point-in-time inspection

A scanner reads a server, a config, or a tool description once and flags known-bad shapes: tool poisoning in metadata, over-privilege, suspicious patterns. That is useful before you connect anything, and useful again in CI when a config changes.

Examples (illustrative): Cisco mcp-scanner; Invariant mcp-scan in CI / static mode; Golf Scanner; Proximity.

What it cannot see: a remote MCP server that was clean on Monday and quietly redefined a tool on Tuesday with no version bump your client notices. The scan you already ran stays green. Your agent still has permission. The contract moved.

Gateway - org control plane

A gateway sits at the organization edge: identity, RBAC, audit logs, secret injection, isolation, policy. It answers who is allowed to call which tools, and under what constraints. That is the right control for production fleets and compliance paperwork.

Examples (illustrative): TrueFoundry; MCP Manager; Docker MCP Gateway class.

What it cannot see by itself: most MCP experimentation still happens on an unmanaged developer laptop inside Claude Desktop, Cursor, Cline, or Zed - outside that gateway. Even inside a gateway, access control answers permission, not whether the tool's declared contract still matches what was approved. A fully authorized call to a redefined tool passes every RBAC check you have.

Contract integrity - pin-and-diff

Pin each tool's declared contract (name, schema, annotations, description) on first sight. Diff it on later calls. Classify the kind of change so a benign added-optional field can proceed and a breaking redefinition shows up as a specific, actionable difference. Hold or warn at call time when the live contract no longer matches the pin.

Examples (illustrative, co-equal): Invariant mcp-scan when it hash-pins tools and when it runs in proxy mode; mcpindex's drift gate (TOFU pin, HOLD on breaking drift, public drift corpus behind the numbers). Some products span rows. That is expected - name the capability, not a single vendor.

What it cannot see: a server that keeps the schema identical and changes behavior underneath. Client-side contract-diff cannot deterministically catch that. Anyone claiming otherwise is overclaiming. Say the limit out loud.

How mcpindex sits in this layer (not alone in it): deterministic TOFU pin + HOLD semantics in the session, plus a public ledger and citable Drift Report dataset (DOI 10.5281/zenodo.21449150) measuring how often contracts change in the wild. That is dataset-first differentiation, not an exclusivity claim. Run a scanner and a contract-integrity control when you can - they answer different questions.

Also not the same (short asides)

Credential vaults keep secrets out of agent context. Necessary; orthogonal to contract integrity.
Runtime / behavioral detection watches for hostile patterns at runtime. Different threat model than "did the declared contract change."
Auth and allow-lists answer who may call a tool. See MCP tool trust vs authentication.
Directories and advisory screens answer what a server declares and whether a description looks dishonest before install. Useful input, not continuous protection. See How to trust an MCP server.

The stack that usually works

Most teams need more than one layer. Scanner at install (and in CI). Gateway at the org edge if you have a control plane. Pin-and-diff in the session where drift actually happens. Complementary, not substitutes.

Questions

What is the difference between an MCP scanner and an MCP gateway?: A scanner answers whether a server or config looks bad at a point in time (pre-install or CI). A gateway answers who may call what, with what secrets, under what policy, at the organization edge. They are complementary. Neither by itself answers whether the live tool contract still matches what you pinned after connect.
What is MCP contract integrity or pin-and-diff?: Pin each tool's declared contract on first sight and diff it on later calls. When the live contract no longer matches the pin, warn or hold before the agent acts. It answers a different question than scanners (point-in-time) and gateways (permission and policy). It cannot catch behavior that changes under a stable schema.
Do I need an MCP scanner, a gateway, or both?: Most teams need a stack, not a single tool. Use a scanner at install and in CI. Use a gateway when you have an org control plane. Add a contract-integrity (pin-and-diff) control in the agent session where silent drift happens. They answer different questions; one does not replace the others.
Is an in-path MCP gate the same as a scanner?: No. In-path describes where a control runs (inside the agent session). A scanner is typically a point-in-time check. Some products span both - for example a scanner that also hash-pins tools or runs a proxy mode. Judge the capability (point-in-time vs permission vs contract integrity), not the product noun.
Can pin-and-diff detect every MCP rug pull or tool change?: No. It catches declared-contract changes: schema, annotations, description. A server that keeps the contract identical and changes behavior underneath is out of scope for client-side contract-diff. Treat that as an honest hard limit.