MCPGuard Finds Protocol Checks Missing from Two Official MCP SDKs

Passing a protocol test suite does not necessarily mean a software library enforces every rule in the protocol. That is the central distinction explored by MCPGuard, a research preprint by Xikai Sun and colleagues, which reports missing checks in two official Model Context Protocol SDKs.

MCP connects language-model applications to external tools, resources and services. Its SDKs sit between incoming messages and application code, translating the specification into data validators and session logic. If a library omits a constraint, applications using it may inherit the omission unless they supply their own checks.

The authors evaluated Python SDK 1.26.0 and TypeScript SDK 1.29.0 against specification revision 2025-11-25. They report 13 confirmed findings in Python and 19 in TypeScript. These are SDK-specific records, not necessarily 32 different underlying constraints: some omissions occur in both libraries.

Two kinds of missing rule

MCPGuard separates requirements into structural and behavioral tracks because they demand different kinds of evidence.

Structural requirements concern message contents: whether a field must be present, which values it permits, or whether a number falls within a specified range. MCPGuard extracts supported constraints from JSON Schema and compares them deterministically with a normalized representation of the SDK’s validators. Language-specific adapters inspect Python’s Pydantic models and TypeScript’s Zod schemas.

One example concerns a preference field restricted to values between zero and one. A model that accepts a floating-point number without checking its bounds preserves the basic data type but loses the protocol constraint. Another mechanism involves defaults: inserting a default value after receiving a message can conceal that a required field was absent from the transmitted JSON.

Behavioral requirements depend on session state and interactions rather than individual fields. A request can have a valid structure yet violate the capabilities negotiated between client and server. For example, support for one elicitation mode does not automatically authorize another.

For this track, MCPGuard extracts normative prose rules, retrieves relevant function-level code slices and asks a language model to assess possible omissions. The reported implementation uses GPT-5.5, with three judgments per located rule and a majority requirement. Those judgments generate candidates; they do not establish findings.

Why the final check matters

MCPGuard’s adjudicator examines broader source context and uses executable witnesses to distinguish confirmed, rejected and unresolved candidates. Structural witnesses submit deliberately invalid values to the actual validators. Behavioral investigation examines relevant callers, callees and protocol state, constructing targeted interaction sequences where possible.

This distinction matters because a narrow code slice can miss a check implemented elsewhere. The paper describes one suspected initialization violation that disappeared under end-to-end testing: an outer session layer rejected the request.

Across both SDKs, adjudication retained 27 of 44 structural candidates and five of 39 behavioral candidates. The authors report that all 27 structural findings were reproduced by generated proofs of concept; the behavioral findings survived full-context review and targeted protocol probes where available. They also state that SDK developers reproduced and confirmed the reported findings following private disclosure.

Most structural findings concerned formats: URI syntax, URI-template syntax or byte encoding. Others involved required fields and numeric bounds. Behavioral findings concerned protocol actions, capability negotiation and authorization policy.

What endpoint tests did—and did not—show

On the same SDK versions, the official conformance suite passed all 42 applicable checks for each SDK. The Yaw Labs suite passed all required checks. Neither exposed the MCPGuard findings.

That comparison does not make endpoint testing obsolete. The baseline suites exercised running reference servers, while MCPGuard examined underlying validators and control logic and constructed negative inputs for suspected omissions. The paper presents these approaches as complementary, not interchangeable.

The authors also probed 32 public MCP servers. All 32 that completed initialization accepted malformed values in two handshake metadata fields. An active resource-request probe produced mixed results: 15 servers rejected the malformed identifier, five proceeded to resource lookup, one accepted the request and 11 lacked the relevant capability or method.

These observations support the authors’ claim that SDK-level omissions can propagate downstream, while showing that application-specific checks can change the outcome on particular paths.

Evidence, not a completeness guarantee

The study remains a preprint and evaluates two specific SDK versions. Its coverage is also incomplete: behavioral code slices were located for 349 of 485 extracted rules in Python and 339 in TypeScript. The authors explicitly distinguish analyzability from conformance; an uncovered rule is not automatically a defect.

The practical lesson is narrower than a claim of demonstrated exploitation. Protocol constraints can disappear inside shared libraries, and passing endpoint checks may leave those omissions undiscovered. MCPGuard offers a way to investigate that boundary with evidence tied to the implementation.