MCPGuard compares the Model Context Protocol specification with the models and functions implemented in two official SDKs. Its structural analysis checks JSON-schema constraints, while its behavioral analysis traces normative textual rules into bounded SDK code paths. A review and reproduction stage then confirms candidate mismatches. The preprint reports…
Inspect the ClaimsCase · DiggingBeagle record
MCPGuard finds protocol-rule omissions beneath apparently passing SDK conformance suites
Preprint reports 32 MCP spec-to-SDK conformance gaps across two official SDK versions, while endpoint-only conformance suites miss those gaps.
Scope
Research on two pinned SDK versions, not an observed production incident. The findings are standards/implementation gaps with different security implications.
Assessment profile
Assessment method- Setting
- research demonstration
- Exploitation
- demonstrated
- Evidence
- Grade B
- AI role
- WITH AI
Basis and provenance
Authors tested specific Python 1.26.0 and TypeScript 1.29.0 implementations with structural PoCs and selected behavioral traces. No independent downstream exploit population or comprehensive patch state confirmed; evidence supports the versioned research result, not universal deployment compromise. Impact remains ungraded.
Assessed Nov 5, 2026 using diggingbeagle.assessment/1.
Evidence basis: CLM-MCP-GUARD-COUNT · CLM-MCP-GUARD-BASELINES · CLM-MCP-GUARD-STRUCTURAL-BEHAVIORAL · MCPGuard: conformance gaps in Python and TypeScript MCP SDKs
At a glance
A conforming network handshake cannot prove that an SDK enforces every normative schema or behavioral rule in the protocol specification. MCPGuard's versioned findings are therefore useful as a second test layer: identify a concrete rule, map it to library validation or execution paths and run a targeted negative or side-effect check. The authors' search…
Read the implicationsNo general exploitation or prevalence evidence across downstream deployments. Which findings were fixed in later SDK releases and which are enforceable by application-level middleware remains to be verified.
Limits and uncertaintyFull account
MCPGuard compares the Model Context Protocol specification with the models and functions implemented in two official SDKs. Its structural analysis checks JSON-schema constraints, while its behavioral analysis traces normative textual rules into bounded SDK code paths. A review and reproduction stage then confirms candidate mismatches. The preprint reports thirteen findings in Python SDK 1.26.0 and nineteen in TypeScript SDK 1.29.0.
The distinction matters because black-box endpoint suites can report conformance without checking every schema restriction or behavioral rule that library consumers assume. In the study, the official and a third-party endpoint-oriented suite identified none of the SDK-level gaps, whereas the authors supplied PoCs for all twenty-seven structural findings and performed targeted checks for the remainder. The researchers report notifying maintainers; a published preprint alone does not establish that every live MCP deployment is affected or that an attacker can turn these gaps into remote execution.
The failure pattern is contract-to-code drift across a shared developer SDK. It complements the forced-tool authorization study: tool selection policy and protocol parsing are different security boundaries, and the counts from the two studies must not be combined.
The evidence is narrower than a claim that all MCP servers are insecure. The authors froze two SDK versions and matched the November 2025 protocol requirements to Pydantic and Zod models, then traced selected normative text into code. Of 32 total reported gaps, 27 concern structural validations such as URI formats, numeric ranges or required fields; five concern protocol actions, advertised capability enforcement or authorization. The paper also shows incomplete inspection coverage, particularly for behavioral rules: only 349 of 485 candidate units for Python and 339 for TypeScript were analyzed. A downstream server may independently reject malformed inputs even when an SDK accepts them, just as some missing checks can propagate where integrations trust the SDK. These are reproducible author-run conformance findings, not 32 observed breaches and not a substitute for side-effect authorization tests.
Mechanism and trust boundary
- 01
Client/server expects MCP specification constraints
Applications rely on official SDK models and handlers to validate messages.
Boundary: Protocol document into library expectations
- 02
SDK omits a constraint
Schema or normative rule does not match actual parsing or behavior for some inputs.
Boundary: Specification to implementation
- 03
Downstream server accepts or mishandles data
A conformance omission can propagate unless the integrating application independently checks it.
Boundary: SDK validation into application state
Claims & evidence
CLM-MCP-GUARD-COUNTMCPGuard authors report 13 specification-conformance findings in Python SDK 1.26.0 and 19 in TypeScript SDK 1.29.0, with structural PoCs and targeted review of behavioral constraints.supported
Basis: reported finding
- supportsMCPGuard: conformance gaps in Python and TypeScript MCP SDKsprimary disclosure
Abstract; Section V-B Conformance gap findings, Table II
CLM-MCP-GUARD-BASELINESIn the paper evaluation, two endpoint-oriented conformance baselines found none of the 32 SDK-level gaps even though the official suite passed its applicable checks.supported
Basis: reported finding
- supportsMCPGuard: conformance gaps in Python and TypeScript MCP SDKsprimary disclosure
Section V-C Comparison with Baselines; Table IV
CLM-MCP-GUARD-STRUCTURAL-BEHAVIORALMCPGuard authors classify 27 findings as structural constraint gaps and five as behavioral rule gaps across the Python and TypeScript SDKs; their analysis covered 349 of 485 behavioral specification units in Python and 339 of 485 in TypeScript, leaving unexamined rules outside the reported findings.supported
Basis: reported finding
- supportsMCPGuard: conformance gaps in Python and TypeScript MCP SDKsprimary disclosure
Evaluation Section V-B, Table II Aggregate distribution; Table I Specification-to-SDK analysis coverage
Implications
A conforming network handshake cannot prove that an SDK enforces every normative schema or behavioral rule in the protocol specification. MCPGuard's versioned findings are therefore useful as a second test layer: identify a concrete rule, map it to library validation or execution paths and run a targeted negative or side-effect check. The authors' search did not exhaust all behavioral requirements, and applications may add their own checks or use different SDK versions. None of the 32 reported mismatches is automatically one confirmed remote compromise. Contrast the separate forced-tool authorization study, which investigates whether tool choice can cross a request's permitted actions even when a protocol message is structurally valid. Both require enforcement at consequential backends rather than accepting client-side annotations as authority.
Controls and mitigations
- Pin SDK and protocol versions for policy-sensitive integrations; run specification-driven negative tests.
- Treat SDK convenience validation as an implementation detail, not the only authorization boundary.
- Separate confirmed protocol mismatches from confirmed exploitability and test the final tool action server side.
- Pin the exact MCP SDK and specification revisions; test both accept/reject paths for numeric bounds, URI templates, capability negotiations and actual tool execution. Treat a black-box conformance pass as coverage of its tested scenarios, not proof of complete standards enforcement.
Unknowns and contradictions
- No general exploitation or prevalence evidence across downstream deployments.
- Which findings were fixed in later SDK releases and which are enforceable by application-level middleware remains to be verified.
Sources and citation
Material revision history
- Nov 5, 2026 · Published version · first publication · revision 221