MCP Security Index methodology

Scope and units of comparison

The unit of assessment is a resolved MCP identity and its observed package release or endpoint scope. Providers are ranked within deployment cohorts because hosted services, installable packages and bridges expose different evidence. Functional categories such as productivity or identity support discovery; they do not change security scores or cohort ranks.

The MCP specification describes tools as model-controlled and recommends a human decision point for tool invocations. CoSAI identifies access control, tool design, human oversight and lifecycle governance as security concerns. The index adapts these themes into its own evidence requirements; the numerical weights are Durin policy. [2] [1]

Evidence, uncertainty and confidence

Evidence is attached to an identity, a stable control ID, a source and an observation time. A criterion's freshness window determines when its evidence expires. Attributed documentation can establish a declared capability, while runtime verification requires evidence appropriate to that control. One does not silently become the other.

SLSA provenance concerns verifiable information about how an artifact was produced. The index distinguishes registry digests and provenance metadata from independent verification of their claims. Metadata inspection does not execute the artifact or establish the security of its behavior. [4]

MCP security guidance addresses authorization context, token handling and scope minimization. In this index, published OAuth and identity metadata establish observable configuration; they do not validate every runtime access decision. [3]

Missing mandatory evidence, an incomplete or expired assessment, active compromise, an unresolved affected release or insufficient assessed weight can prevent ranking. At least 20 category-budget units must have evidence. Confidence and evidence coverage are reported separately from the baseline score; a failed or partial required check cannot establish that there are no known findings.

Scoring model and stability

For each category, earned baseline credit is divided by applicable baseline points, including unknown requirements at zero credit. The effective category weight is the smaller of its fixed budget and its applicable baseline points. The index normalizes the weighted category credits to a score from 0 to 100. Criterion credit is represented in thousandths, and the final score is rounded to the nearest integer.

In notation: effective weight = min(category budget, applicable baseline points); category credit = earned baseline points / applicable baseline points; score = round(100 × sum(effective weight × category credit) / sum(effective weight)). A category with no applicable points contributes no weight.

For a simple illustrative case with all 100 budget units applicable, unknown approval evidence earns zero of the 30 approval units. If every other category earns full credit, the resulting score is 70, assuming all other ranking requirements are met. Real configurations can have a different applicable denominator.

New criteria begin as observations outside the scored roster. Adding them does not change existing scores, scored confidence or ranks, although total catalog coverage changes. Promotion into scoring requires versioned review: existing weights and budgets remain fixed, the 20-unit evidence floor remains, and newly admitted weight must bound movement for already-graded providers to five points. A larger recalibration requires a new baseline edition.

Independent human approval

The baseline allocates 24 points to an independent approval flow for named sensitive actions and 6 points to request expiry. Attributable provider or execution-host documentation can meet this capability baseline. An agent-controlled approval flag, an ordinary client tool prompt or initial OAuth consent is not sufficient for this control.

Stripe documents Dashboard review for selected actions, independently of the client's tool-approval setting. Unapproved requests expire after 24 hours. Confirmation depends on the action: a generic write tool can also perform actions outside that approval flow. This is the reference capability, not a claim that every Stripe mutation requires human review. [5]

CoSAI discusses managed host confirmation and server-requested user confirmation as approaches to human oversight. The index recognizes attributable provider and host flows. Exact-action binding, bypass resistance and stronger enforcement assurance remain distinct advanced controls, visible outside the baseline score. [1]

Advisories and remediation timing

Advisories match a resolved package version or endpoint scope. OSV represents affected version ranges with events such as introduction and a fixed release; the presence of a reported fixed version is not evidence that a provider has deployed it. Remediation timing begins at the first attributable public disclosure and ends at a confirmed fixed release publication or reviewed incident end time. [6]

MCP-MNT-002 has four points. A complete, current advisory check with no matching advisory earns full credit. When advisories do match, the worst confirmed remediation latency determines credit. Missing timing evidence stays unknown, while an active affected release earns no credit for this criterion and affects ranking eligibility. Affected providers are checked hourly; this check's evidence expires after two hours without confirmation.

Catch-all execution as an independent finding

A catch-all red flag identifies an advertised generic execution surface: code, shell commands, unrestricted SQL, dispatch or generic requests. Detection uses inspected tool schemas or configured first-party documentation. Constrained enumerations do not trigger this rule; unavailable or partial inventories remain unknown unless an attributable source independently establishes the capability. Collection never invokes the tools.

CoSAI identifies overly permissive tool capabilities as a security boundary concern. The index treats this as a capability finding, independent of vulnerability advisories and baseline points. A documented approval flow and a catch-all red flag can therefore coexist. Stripe's generic API write tool illustrates why the two observations must remain separate. [1] [5]

Interpretation and limitations

The index describes demonstrated safeguards for a stated configuration at an observation time. First-party claims do not verify all production settings, and unauthenticated metadata does not establish authorization enforcement on every action. Hosted code, authenticated tool inventories and tenant-specific policies can be unavailable. Such gaps remain explicit rather than being filled by inference.

A complete advisory collection with no match is a bounded observation, not proof that no undisclosed vulnerability exists. Package code is not executed, prompt-injection resistance is not inferred from metadata, and functional categories are not risk ratings. Operators should read the control evidence, affected versions and independent findings alongside the score.

Dated editions preserve the methodology text, control definitions, point rules, checks, taxonomy and references used at release. The undated URL points to the current edition. Historical assessments retain their original calculation policy; this publication does not rewrite previous scores or make different baselines directly comparable.

Deterministic checks

Checks describe what collection can establish. Unsupported observations remain explicit. A release waiting period is not a security verdict, and unavailable hosted code is not assumed to be safe.

Appendix A. Control catalog

Control IDs identify the same safeguard across providers. Baseline controls contribute to the score; advanced assurance remains visible outside it. Each criterion has a fixed weight. Independent subcriteria have distinct evidence requirements and contribute their stated share; atomic criteria retain one evidence check. Historical editions preserve their original allocations.

Hosted services

Appendix B. Provider classification

One reviewed primary functional category per MCP identity. Classify the exposed service, not its transport, name, security controls or safety score.

Edition history

Dated links preserve released methodology content. The undated address opens the current edition.

1. Version 2 · 2026-11-11-v2Current edition
2. Version 1 · 2026-11-11

Edition fingerprint: sha256:eb7da9d823c624950c51de9660d39ddd64eb8c13d86584ddaeb14ab141e60799