MCP risk does not stop at a repository boundary. Agents combine tools installed by different teams, from different repositories, into one execution environment. The dangerous behavior can exist only in the composition.
A repository scanner answers: “Does this code contain a known problem?” An organization needs a second answer: “What can all MCP tools available to this agent accomplish together?” Those are different security questions.
Consider two servers that are individually ordinary: one reads source files and local credentials; another sends messages, makes HTTP requests, or executes deployment actions. The first supplies sensitive data. The second supplies an outbound path. Neither repository contains the complete attack chain.
We retain exact-version tools and security evidence across 71,565 canonical MCP implementations. That makes capabilities comparable across vendors and releases. When a customer supplies the MCPs actually enabled in one agent environment, we can build an organization-specific capability graph rather than scan each repository in isolation.
Single-repository CI never sees the full runtime tool set, organization permissions, shared agent context, or another team’s MCP configuration. It can validate one component; it cannot determine whether that component completes a toxic combination elsewhere.
Keep component scanning, but add an inventory-level policy: continuously resolve every enabled MCP to its exact version and observed capabilities, then alert when a new installation or version change creates a prohibited cross-MCP path.