Reference implementation now exists — pushed v0.1 of the inferrer as a follow-up commit on this PR's branch and as a standalone repo:

• https://github.com/walbis/mcp-risk-inferrer (Python, MIT)
• Heuristic classifier: ordered verb regex → category + riskLevel; risky-flag bump (force/recursive/cascade/all_namespaces); blast-radius inference from scope-hint params (namespace/cluster/org); derivation tables for reversibility/approvalRecommendation/minTrustLevel.
• Pydantic models matching this SEP's vocabulary exactly (RiskLevel/Category/BlastRadius/Reversibility/ApprovalRec/ToolRiskManifest).
• CLI: mcp-risk-inferrer classify tools.json --format yaml|json.
• 19 real failing-first tests against an 11-tool K8s fixture (kubectl_get → read/low; kubectl_apply → mutate/medium/namespace; kubectl_delete → delete/high + state_loss; cleanup_pods → destroy/critical; force bumps high → critical; etc.). No tautologies.
• v0.2 planned: optional LLM augmenter. v0.3: live MCP connector.

Goal is that consumers can bootstrap risk metadata for any existing MCP server today, without waiting for every server to declare the new fields. Happy to iterate the vocabulary mapping if the spec moves during review.

Strong +1 from the multi-server-host side. We run Pipeworx (a hosted MCP gateway — ~755 packs / 3,300+ tools behind one origin), and the "every platform reinvents the same vocabulary" problem is just as real on the consuming side.

One concrete data point that argues for this SEP: clients already diverge on the existing binary hints. The spec makes destructiveHint meaningful only when readOnlyHint=false, but at least one major client's validator flags it as "missing" on every tool regardless — so we set it unconditionally across all 3k+ tools just to pass review. Graded, machine-readable metadata helps, but only if the SEP also pins down required-ness (when a field is expected vs. optional per client), not just the value vocabulary — otherwise the same divergence reappears one layer up.

Two field notes on the proposed fields: (1) blastRadius maps cleanly onto how we'd want to gate tools by auth tier — genuinely useful. (2) reversibility: "none" + category: "destroy" overlap with the legacy destructiveHint; worth documenting precedence so consumers don't double-count. Happy to share how the binary hints play out across 3k+ real tools if it'd help ground the design.

@walbis @b-gutman the graded direction makes sense, and Bruce's required-ness point is the one I'd put front and center: a value vocabulary without a per-field optional/expected contract just pushes the divergence up a layer, the way he saw with destructiveHint.

One framing that might keep this clean: treat each field as a producer-asserted hint the consumer can interpret, override, or ignore — not an authority signal. A server says reversibility: "none"; the host still decides what to gate or prompt on. If the SEP spells that out (who asserts each field, and that consumers may override), the reversibility/category vs legacy destructiveHint precedence question mostly answers itself — you're reconciling hints, not resolving authority.

I'd scope approvalRecommendation as advisory-only for the same reason.

@walbis @b-gutman @AgentGymLeader — +1 from the static-analysis side, and a concrete addition that builds on Bruce's required-ness point.

Why the divergence reappears, and where SARIF helps

Bruce's framing is correct: a value vocabulary without per-field required-ness pushes divergence up a layer. The same problem hits the consumer-of-the-consumer — static-analysis tools that audit MCP catalogues (mcp-scanner, prompt-defense-audit, ultraprobe) want to ingest and emit this vocabulary, and right now there's no bridge between "server-declared riskLevel" and "SARIF finding emitted by a scanner". Each scanner reinvents the severity mapping.

A normative riskLevel → SARIF level table in this SEP closes that gap:

Spec language could be: "Consumers MAY tighten severity (escalate warning→error), but MUST NOT loosen below the producer-asserted level." That keeps Andrew's hint-not-authority framing for the value, while giving SARIF emitters a deterministic mapping that doesn't require per-client guessing.

One non-overlap clarification building on Bruce's reversibility:"none" + destructiveHint point

When a tool divergence exists between server-declared and statically-inferred risk, that divergence is the test signal: scanner emits a SARIF result like mcp-risk-mismatch (server: low, inferred: critical). Consumers gate or audit on the delta. This works whether the producer asserts the hint, the consumer overrides it, or a third-party scanner re-computes it.

Offer

Happy to draft seps/NNNN-tool-risk-sarif-mapping.md as a scoped follow-up SEP once #2793 lands, focused on the CI/CD + SAST consumer slice (out of scope for the current SEP). Doesn't change anything you've proposed; complements it on the audit side.

(Reference shapes I'd carry forward: SARIF 2.1.0 §3.27.10 for level semantics, ATR convergence on rule-ID federation in agent-threat-rules PR #54, Cisco mcp-scanner #146 merged 2026-04 for the static-side precedent.)