The report
The MCPGuard preprint reports 13 conformance gaps in Python SDK 1.26.0 and 19 in TypeScript SDK 1.29.0. The authors inspected both schema constraints and normative prose rules, then used code review and targeted PoCs. The official endpoint-oriented conformance suite passed its applicable checks but detected none of the reported library-level mismatches.
The research Case treats those numbers as protocol differences in selected versions, not 32 verified remote compromises. Protocol conformance and authorization are different questions. The earlier MCP forced-tool study measured request-level tool-selection errors in mock scenarios, not SDK parsing. Applications still need final permission checks at every consequential tool and resource boundary.
Count what the authors examined
Of the 32 reported mismatches, MCPGuard classifies 27 as structural validation problems and five as behavioral discrepancies. The paper describes an incomplete search of the prose requirements, inspecting 349 of 485 candidate behavioral units for Python and 339 of 485 for TypeScript. Those denominators are not a measured percentage of vulnerable production MCP endpoints. They also explain why the paper does not warrant statements that every protocol obligation has been checked. Future SDK releases or application-level middleware may enforce particular rejected conditions even where the tested version did not. The finding is a versioned library-conformance result; a separate exploit claim would require a reachable consumer, a permitted tool call and demonstrated side effect.
What a passing SDK check does not certify
The paper's comparison is between rules inherited by library implementations and requests accepted by endpoint test suites. A client/server handshake can succeed while a model validation or capability rule is omitted. MCPGuard's authors report checking 349 of 485 behavioral specification units for Python and 339 for TypeScript; this coverage is not a claim of exhaustive proof. They also report notifying SDK maintainers and withhold exploit-oriented details. A deployment may add its own checks or run different SDK versions, so no universal exploit or breach count follows from the 32 findings. A useful regression test would map a particular normative requirement to the exact SDK path and then verify the actual downstream tool side effect. Compare the distinct request-scoped tool-authorization issue.