deniz.in

Markets

Weather

Loading weather

· via dev.to (home feed)

mcp-cpp: community-built C++17 SDK passes MCP's official conformance suite

Developers released mcp-cpp, a C++17 SDK for the Model Context Protocol, and ran it through the official conformance suite — passing 100% on the current spec while finding bugs in their code and the harness.

mcp-cpp: community-built C++17 SDK passes MCP's official conformance suite

A C++ SDK where official support is missing

The official MCP SDK roster lists ten languages — TypeScript, Python, C#, Go, Rust, Ruby, Java, Swift, PHP and Kotlin — but not C++, even though much of the world's data infrastructure, from databases and trading systems to game engines and embedded devices, is written in it. A developer has now released mcp-cpp, a community-built C++17 SDK for the Model Context Protocol targeting the 2026-07-28 specification, and validated it against the official conformance suite rather than self-certifying. The project is described in a dev.to post published October 15, 2026; the code is available under the MIT licence.

The SDK is built to drop into existing C++ builds: no async runtime, one bundled JSON header, one optional HTTP library, and integration through CMake's find_package. The motivation, according to the post, is that agents increasingly need to reach native infrastructure just as MCP becomes the standard protocol for tool access.

What it implements

The 2026-07-28 revision departs sharply from the 2025-era model: no initialize handshake, no session identifiers, protocol version and client capabilities carried in each request's params._meta, servers advertising themselves via server/discover, and servers never initiating requests — when more input is needed they return an input_required result and the client retries, a pattern the post calls MRTR.

mcp-cpp covers both roles. The server side provides a builder for tools, resources and prompts, RFC 6570-style URI templates, capability gating, a signed request-state codec using an in-tree HMAC-SHA256 implementation, progress notifications, cancellation and cacheable results. The client is blocking and value-semantic, auto-fulfils the retry flow, and ships a full OAuth 2.1 client with PKCE and dynamic client registration. Transports cover stdio and Streamable HTTP on both sides, with mirrored-header enforcement, SSE responses and Last-Event-ID reconnect, plus a JSON Schema 2020-12 validator enforcing input and output schemas on every call.

Conformance results

The team ran the SDK through modelcontextprotocol/conformance v0.2.0-alpha.12, the same suite the official SDKs use, across both spec revisions and both roles. On 2026-07-28 the server passed 42 of 42 checks and 20 of 20 scenarios, and the client passed 32 of 32 scenarios and 399 of 399 checks, including all 25 OAuth 2.1 and client-ID metadata scenarios. On the older 2025-11-25 revision the server scored 26 of 30 and the client 17 of 18.

Every failure is baselined with an explanation. The four 2025 server failures all require the server to send a request to the client mid-call, a mechanism the 2026 revision replaced with the retry pattern; implementing a removed mechanism is a deliberate non-goal. The single 2025 client failure is attributed to a bug in the harness itself.

Bugs found on both sides

The harness caught five real bugs in the SDK within days, each tied to a named spec clause: notifications silently dropped during requests over Streamable HTTP, a 2026-only field injected into legacy responses that reject unknown fields, strict rejection of JSON-RPC's legal null id on error responses, a race between the session identifier returned by initialize and the next request, and incorrect handling of empty mirrored-header values.

The suite itself was not immune. In one elicitation scenario the mock never delivers the server-to-client elicitation, so the tool call never completes. The team built the official rust-sdk reference client in the same environment and reports that it fails identically; the defect has been filed upstream and baselined with that evidence.

Design and current use

The design targets unglamorous infrastructure constraints: C++17 rather than 20/23 so GCC 9 and MSVC v142 toolchains stay supported, an exception-free protocol layer, no external crypto dependency — entropy comes from RtlGenRandom on Windows and /dev/urandom elsewhere — and single-threaded stateless dispatch. The SDK already powers zorm-mcp, a production MCP server exposing 13 structured database tools across sqlite3, file, MySQL, PostgreSQL and dm8. Roadmap items include OAuth server-side enforcement, vcpkg and Conan ports, and a faster parser — the README openly notes that raw parsing is currently slower than serde_.

Why it matters

Agents are only as useful as the systems they can reach, and a great deal of the world's data lives behind C++ interfaces. Until now, exposing a C++ codebase to MCP meant hand-writing protocol plumbing or bridging through another language. mcp-cpp closes that gap and grounds its compatibility claims in the same conformance suite the official SDKs use — a higher evidentiary bar than most community libraries clear. The testing also cut both ways: the harness exposed five genuine integration bugs in days, and the authors reciprocated by documenting a harness defect with cross-verification against the official Rust client. The next step, per the post, is proposing C++ for the official SDK roster, a decision that rests with the MCP SDK Working Group; the in-tree conformance reports and production usage are being positioned as the supporting case.

  • #cpp
  • #mcp
  • #sdk
  • #open-source
  • #conformance-testing

Related posts