v0.5.2

Changed

• README: a section on VS Code, which needs the bridge of zig-bridge-sdk.

v0.5.1

Changed

• A cancel of serve of the HTTP, gRPC and Unix socket servers now sets the stop flag of shutdown. The WebSocket server and the authorization server already did this. After the cancel, the accept loop closes the wake connection of the stop and ends. A new call of serve on the same server then accepts no connections, and it returns only at shutdown or at a cancel. Before, the accept loop could serve the wake connection as a client connection, and a new serve accepted connections again.
• After a cancel of serve, the connections of the HTTP server obey the stop flag, as after shutdown. A connection then answers no request after its current request. shutdown wakes the connections, but the cancel does not. Thus a connection that waits can see the stop flag 60 seconds or less after the cancel. Before, the connections served requests until the client closed them or until idle_timeout.

Fixed

• The HTTP, gRPC and Unix socket servers stop their accept loop with util.wake.cancelAcceptLoop or util.wake.cancelUnixAcceptLoop. Thus the cancel usually comes before the wake connection, while the accept waits. Before, the wake connection came first, and on Windows the cancel then frequently came during the accept of that connection. In Zig 0.16.0, std then gives error.Canceled for the complete accept, and a Debug build writes a stack trace of error.Unexpected (INVALID_PARAMETER). The change removes these traces from the test runs of the SDK. Under load, the wake connection can still come first, and a trace is still possible.

• On a POSIX system, util.wake.wakeIp connects with a socket that does not block, and it waits for the connect in poll for 100 ms or less. A signal during the wait does not start a second connect. Before, wakeIp used the connect of std, which blocks and connects again after a signal. In Zig 0.16.0, std can send its cancel signal late, to a task that already saw its cancel. An example is a task that stops a server after a cancel. On macOS, the second connect then got EISCONN, and a Debug build stopped with a panic. cancelAcceptLoop uses wakeIp, and thus the stop of the WebSocket server and of the authorization server. The stop of the HTTP and gRPC servers also uses wakeIp.

v0.5.0

Added

• secret_service.Options.timeout and KeychainTokenStorage.Options.timeout: the time limit for each answer of the D-Bus bus and of the Secret Service. The default is dbus.default_timeout, 25 seconds, the same as in the reference implementation of D-Bus. A service that does not answer in time gives error.KeychainUnavailable. Before, the Secret Service backend waited without a limit, for example for a service that stopped.
• secret_service.Options.prompt_timeout and KeychainTokenStorage.Options.prompt_timeout: the time limit for the answer of the user to a prompt of the Secret Service. The default is secret_service.default_prompt_timeout, 5 minutes. A prompt without an answer in time gives error.KeychainLocked. Null waits without a limit, as before.

Changed

• Breaking: dbus.Connection.open has a fifth parameter, the time limit for each answer of the bus. Null waits without a limit, as before. The connect and the authentication of open together obey this limit, and each Connection.send, Connection.call and Connection.receive obeys it too. Connection.waitSignal has a parameter for the time limit of its wait. At the limit, these functions return the new error dbus.Error.Timeout, and the connection is then not usable.
• A wait of the D-Bus client with a time limit runs in its own task, and at the limit that task gets a cancel. A cancel stops a blocked read on each system. On Windows, a shutdown of the socket does not stop a blocked read. When the Io cannot run a task concurrently, the client can wait without a limit. The first such wait of the process writes a message to the log of the scope mcp_dbus.

Fixed

• Correction to the notes of 0.4.0: the proxy sees only the host and the port of the server for an https URL. For an http URL, the tunnel has no TLS, thus the proxy can read the requests. The doc comments of transport.proxy and HttpClient.Options.proxy now say this.
• On Windows, the fake D-Bus server of the keychain tests serves each connection in its own task. A read on a Unix socket of Windows can stay blocked after the client closes the connection. Before, the server then never accepted the next connection, and a test hung.
• Correction to the notes of 0.4.0: the warning of the scope mcp_router for an error response with a null id also has the error code. That code is the code of the error response.
• The D-Bus client connects to an abstract address (unix:abstract=) with a socket that does not block. While the queue of the bus is full, the client tries again after a short pause, until the time limit or a cancel. Before, this connect waited without a limit, and a cancel did not stop it.
• On Windows, the Unix socket transport sees each close of the peer. The Windows driver of Unix sockets can lose the close of the peer when a receive starts at about the same time. Before, the server then kept the connection open until shutdown, and the connection kept its place in limits.unix_socket.max_connections. The client did not see the end of the connection, and a request waited until its timeout. Now each read of the server and of the client first waits in a poll of the socket, until data comes or the connection ends. Each poll stops after one second and starts again.

v0.4.0

Added

• RequestOptions.log_level: the log level of one request. It replaces Options.log_level of the client. The client also sends it when Options.log_level is null.
• RequestOptions.meta: more _meta entries for one request, for example traceparent, tracestate, baggage or a key with a vendor prefix. Before the client sends the request, it checks each key. A key that meta.validateKey refuses, or a key that the SDK owns, gives the new error error.InvalidMeta of Client.RequestError. The client sends nothing then. The client accepts the keys of extensions under io.modelcontextprotocol/. The entries of the SDK always have priority.
• meta.sdk_owned_request_keys and meta.isSdkOwnedRequestKey: the request keys that the SDK owns. They are the protocol version, the client information, the client capabilities, the log level, the subscription id and the progress token.
• RequestOptions.inline_notifications: the reader task of the transport calls on_progress, on_log and on_notification of the request at once, before it routes the next frame. Thus a notification gets to its callback before the response of another request that the server wrote after it. An example is a notifications/tools/list_changed event of a listen stream and the tools/call result that caused it. The stdio, Unix socket and WebSocket transports obey the option, and the memory link, HTTP and gRPC ignore it. A callback must only copy, serialize and write the data, and must not send a request through the same client. Transport.Exchange.inline_notifications gives the option to the transports.
• stdio.Client.SpawnOptions.on_notification and stdio.Client.SpawnOptions.userdata: the callback of the stdio client for each notification without a progress token and without a subscription id. An example is a log message of the server. spawn sets the callback before the reader task starts.
• sse.Parser.max_event_bytes (4 MiB): the maximum bytes of the event that the SSE parser reads, across all calls of feed. The bytes are the line that the parser reads with its field name, the data and the event type of the event, and the last event ID. The events and comments before it do not count.
• sse.Parser.max_id_bytes (256): the maximum bytes of an event ID. The SSE parser ignores an id field with a longer value.
• line_framer.TopLevelScanner: finds the top-level members "id", "method", "result" and "error" of a JSON object in parts, with fixed memory. line_framer.Framer.dropped has the members of the last line that the framer dropped for its length or for its UTF-8. The framer reads the whole line for it, also the part after the limit.
• stdio.Client.exitStatus: the exit status of the last server process that ended, as std.process.Child.Term. The client reaps a process after it ends its output, before a restart, and in close and kill. When a process ends its output and no restart is left, the client logs a warning in the scope mcp_stdio with the status.
• Client.Diagnostics.http_status: the HTTP status of the last response to a request, also when the request failed. The Streamable HTTP and gRPC transports give it, and the WebSocket transport gives the status of an upgrade that the server refused. Thus a caller can tell a wrong path, for example status 404, from a response that is not valid. Both give error.InvalidResponse.
• OAuthClient.Options.ca_bundle: the CA certificates that the OAuth client trusts for its https requests. These are the metadata, registration and token requests, and the authorization request of headless_redirect. Null uses the CA store of the system, as before. Thus a private CA or the CA of a test server works without a change to the CA store of the system. The HTTP client transport can use the same bundle in tls.trust.
• auth.common.Fetcher.ca_bundle: the CA bundle of the fetcher. With a bundle, the fetcher sends each request on a new connection of http1.Connection. There, the TLS client of the SDK checks the certificates against the bundle only, at the time of the request. Thus the servers must offer TLS 1.3. The fetcher does not give the bundle to std.http.Client. On Windows, the TLS client of std also accepts a certificate chain that the certificate store of the system trusts.
• HttpClient.Options.proxy and OAuthClient.Options.proxy: the HTTP proxy of the client connections, with the new module transport.proxy. The client asks the proxy for a CONNECT tunnel to the server, also for an http URL. The tunnel carries the TLS handshake and the requests, thus the proxy sees only the host and the port. .explicit sets a proxy URL, and .none disables the proxy.
• By default, the proxy comes from the environment that the application gives, for example .{ .environment = init.environ_map }. The default environment is null, thus the clients connect directly, as before. An https URL takes the first of https_proxy, HTTPS_PROXY, all_proxy and ALL_PROXY with a value. An http URL takes the first of http_proxy, HTTP_PROXY, all_proxy and ALL_PROXY. When REQUEST_METHOD has a value, the client ignores http_proxy and HTTP_PROXY, because the Proxy header of a request to a web server can set them.
• transport.proxy.bypasses: the match of no_proxy and NO_PROXY. * matches each host. A name matches the same host and each host under it, with or without a dot or *. at the start. An IP address matches the same address, and an address with a prefix length, such as 10.0.0.0/8, matches the range. An entry with a port matches only that port. The client does not resolve names. A proxy from the environment never gets a loopback host: localhost, a name under .localhost, an address in 127.0.0.0/8 and ::1.
• The user and the password of a proxy URL go to the proxy only in the CONNECT request, in a proxy-authorization header with the Basic scheme. The log lines show only the host and the port of the proxy. The SDK has no TLS to the proxy and no socks5 proxy. A proxy URL that does not use http gives the new error error.InvalidProxy of HttpClient.InitError.
• When the proxy refuses the tunnel, the new log scope mcp_proxy has a warning with the proxy, the target and the status. http1.Connection.openThrough and auth.common.Fetcher.fetch then return error.ProxyRefused. The HTTP client transport gives error.WriteFailed, and the client returns error.TransportFailed.
• auth.common.Fetcher.proxy: the proxy of the OAuth fetcher. Through a proxy, the TLS client speaks to the server through the tunnel, with the same trust as a direct request. With ca_bundle, that is the TLS client of the SDK. Without it, the TLS client of std uses the CA store of the system. The fetcher does not use the proxy fields of std.http.Client. In Zig 0.16.0, that client sends an https request through a CONNECT tunnel without TLS.
• http1.Connection.openThrough and http1.TunnelError: a connection through a CONNECT tunnel. http1.writeRequest and http1.RequestError: the request of Connection.send for another writer. Connection.SendError is now the same error set as RequestError.
• http2.Connection.Stream.stopWaits: stops the waits on a stream without a reset. Each wait on the stream then gives error.Canceled when it must block. Use it, not Future.cancel, to stop a task that waits on the stream. In Zig 0.16.0, the condition of std can lose a cancel that comes together with a wake-up. The task then waits until the stream gets a reset or the connection ends.
• client.CallStream: the stream of a gRPC call that runs in its own task. The tunnel and typed channels reset the stream with CallStream.stop to stop the call.
• util.loopback.connect and util.loopback.listen: a connect to a loopback address and a listen on it, with at most five tries after error.Unexpected or error.AddressUnavailable. On Windows, Zig 0.16.0 gives two errors that can go away as error.Unexpected: a connect to a server with many connections in TIME_WAIT (ADDRESS_ALREADY_EXISTS), and a socket when no local port is free (TOO_MANY_ADDRESSES). On Windows, a refused connect is also error.Unexpected, thus use connect only for a server that listens. The tests of the SDK use these functions for their own sockets.

Changed

• Breaking: the client parses each notification of a request into scratch memory and resets that memory after the frame. Thus the method and params arguments of RequestOptions.on_notification and Hooks.on_notification are valid only during the call. Before, they stayed valid until the caller freed the request arena. A callback that keeps a part of them must copy it. The parameters of on_progress and on_log were already valid only during the call.
• The request arena does not hold the notifications of the request. Thus a long subscriptions/listen stream does not make the request arena larger. Before, each event added approximately 1900 bytes to the request arena on all transports.
• The client applies the progress rate limit before it parses a notification, when the method has no escape sequence. Thus it does not parse a progress notification over limits.max_progress_rate_per_s.
• Breaking: the fields on_notification and userdata of stdio.Client are gone. Use the spawn options with the same names. The reader task starts in spawn and read the fields one time for each child process. Thus a callback that the caller set after spawn raced with the reader task. When the reader task was first, it dropped these notifications until a restart, also the log messages of the server.
• Breaking: over the memory link, the callback of the acknowledgment of a listen stream runs while the server holds the lock of the stream. Thus the callback must not publish an event of the same server, for example with Server.setToolEnabled. The callbacks of the events already had this rule. Before, the server sent the acknowledgm...

v0.3.0

Added

• limits.listen_ack_timeout (10 s): the client waits this time for the acknowledgment of a subscriptions/listen stream. Then it cancels the stream, and the request returns error.Timeout. Zero disables the limit. All client transports obey it through Transport.Exchange.first_frame_timeout.
• json.checkDepth, json.parseTreeMaxDepth and jsonrpc.Message.parseMaxDepth check the nesting depth of a JSON text before the parse, without recursion.

Changed

• json.parseTree and jsonrpc.Message.parse reject a text that nests deeper than 256 levels (json.max_tree_depth) or 200 levels (json.max_message_depth). std.json.Stringify cannot write more than 256 levels in a safe build mode.
• The HTTP server supervises each connection in a second task. At the shutdown, it ends a connection that waits for a request at once, and a busy connection after limits.shutdown_grace. Before, the shutdown waited until each peer closed its connection.

Removed

• Breaking: Limits.cancel_notify_timeout and Limits.max_step_up_attempts. No code used them. Each authorization client has its own max_step_up_attempts option.
• Breaking: Limits.http.listen_ack_timeout. It is now Limits.listen_ack_timeout, because all transports obey it.

Fixed

• The Streamable HTTP server obeys limits.http.head_timeout and limits.http.idle_timeout. A request head that does not arrive in head_timeout (10 s, with the TLS handshake for the first request) gets HTTP 408. A body that does not arrive in idle_timeout (60 s) after its head also gets HTTP 408. A keep-alive connection without a new request for idle_timeout closes without a response. Before, a slow client could keep one of the http.max_connections connections without a time limit.
• The servers of all transports obey limits.json_max_depth (64). A message that nests deeper gets -32700 with a null id. The client fails a request whose response nests deeper with error.InvalidResponse. Before, the server parsed a message of any depth, and std.json.Stringify panics in a safe build mode when the server serializes a part of more than 256 levels, for example the parameters of a task.
• The server refuses a subscriptions/listen filter larger than limits.max_filter_bytes (64 KiB) as compact JSON with -32603.
• The HTTP client transport gives each SSE event to the request when its bytes arrive. Before, it held back an event until the next bytes came, thus a listen stream got its acknowledgment and its events late, with the next keep-alive comment.
• The HTTP/2 connection of the gRPC transport answers a frame larger than the maximum frame size with GOAWAY and FRAME_SIZE_ERROR (RFC 9113 section 4.2). Before, it sent PROTOCOL_ERROR. A PING, PRIORITY, RST_STREAM, SETTINGS or WINDOW_UPDATE frame with a wrong length also gives FRAME_SIZE_ERROR.
• Correction to the notes of 0.2.0: only the server checks includeContext against the client capability sampling.context. The client does not. The client validates elicitation URLs, form answers and sampling messages with tool results, as the notes say.

v0.2.0

Added

• Regular expression engine for the JSON Schema keywords pattern and patternProperties (mcp.schema.regex). It is a Pike VM over code points with the ECMA-262 syntax, and the match time is linear in the input length. Backreferences, lookaround and most Unicode property escapes give error.UnsupportedRegex. The limits are limits.schema.max_pattern_bytes and limits.schema.max_regex_states. A derived schema accepts .pattern on string fields.
• RSA certificate keys in the TLS server and the TLS client: PKCS#1 and PKCS#8 keys of 2048 to 4096 bits sign with RSA-PSS (rsa_pss_rsae_sha256, sha384, sha512). The private operation uses the Chinese remainder theorem, and the key verifies each signature before it goes out.
• The post-quantum hybrid key exchange group X25519MLKEM768 (RFC 10024) in the TLS server and the TLS client. It is the first group of the default order. The client also sends an X25519 share, so a server without the hybrid group needs no HelloRetryRequest.
• Unix socket transport (mcp.transport.unix) with the stdio framing: a server that accepts many peers on a socket file and a client transport. The limit is limits.unix_socket.max_connections. The example unix_server and the client_cli unix mode use it.
• On Windows the Unix socket server gives the socket file a protected access control list that allows access only to the user of the process. This is the Windows form of the mode 0600, and Windows checks the list when a client connects. A mode with group or other bits keeps the inherited list. A failure gives BindError.AccessControlFailed.
• The Unix socket server refuses a directory where other accounts can add, delete or rename entries, because such an account can put its own socket at the path (BindError.DirectoryNotPrivate). On POSIX systems it also checks the parent directories. When mode gives the group access, the group can also write to the directory. mcp.transport.unix.createPrivateDirectory makes a safe directory: mode 0700, or on Windows an access control list that its files inherit. The example unix_server uses it.
• The Unix socket server creates the socket in a new private directory, sets the mode or the access control list, and then moves the socket to its path. Thus no client can connect before the socket has its protection.
• Client icon rules (mcp.icons, Client.fetchIcon, Client.selectIcon): only https and data: icons, the same origin as the server unless the policy trusts other origins, no credentials, magic byte checks, PNG and JPEG by default, other formats through the icon_decoder hook, and the limits limits.icon.
• OAuth client credentials extension (mcp.auth.ClientCredentials) with client secrets and private_key_jwt assertions, token caching and renewal before expiry.
• Enterprise-managed authorization extension: the client (mcp.auth.EnterpriseClient) exchanges an identity assertion for an ID-JAG at the enterprise identity provider and the ID-JAG for an access token. mcp.auth.IdJagValidator checks ID-JAGs for an application with its own authorization server.
• mcp.auth.Provider for the HTTP client transport (auth_provider), and Server.Options.authorization_extensions to advertise the authorization extensions.
• JWT signing keys (mcp.auth.jwt.SigningKey) for ES256, ES384, EdDSA, RS256 and PS256, JWK set parsing, and ES384 and EdDSA verification.
• Skills extension (io.modelcontextprotocol/skills): the server option skills, addSkill, addDynamicSkill, skills/list, skills/get and resources/directory/read, and the client methods listSkills, getSkill, readDirectory and readSkillFile with manifest checks.
• MCP Apps extension (io.modelcontextprotocol/ui): the server option apps, UI resources with addUiResource, tool UI metadata with ToolDef.ui, and the client accessors toolUi and readUiResource.
• Requirement matrix: zig build extract-requirements finds the 733 normative sentences of the vendored specification pages, docs/spec/requirement_tests.zon maps each one to tests or to a reason, and zig build spec-matrix checks the mapping and renders docs/generated/conformance-matrix.md. The CI checks both files. 127 new tests cover requirements that had no test.
• Documentation site: zig build site builds a landing page and the API reference of the modules mcp and mcp_grpc. The workflow docs.yml deploys it to GitHub Pages from main.
• zig build lint-docs has the options --strict, --format, --rule, --string-literals and --wiki-dir, and the warning rules of the project profile. The project dictionary has all its lists.
• Full JSON Schema 2020-12 support: unevaluatedProperties, unevaluatedItems, $id in subschemas with base URI resolution, $dynamicRef and $dynamicAnchor. The content keywords are annotations. The draft 2020-12 files of the JSON Schema Test Suite run with the tests.
• x-mcp-header annotations on nested properties. The client and the server refuse a tool with an annotation that a chain of properties keywords does not reach, and the client logs the refusal.
• The client refreshes tools/list and retries a tool call one time after error -32020.
• The client validates structuredContent against the output schema and reports Diagnostics.structured_content_invalid.
• The client and the server validate elicitation URLs, form answers against requestedSchema, sampling messages with tool results, and includeContext against the client capability.
• The HTTP server cancels a request when the client disconnects. Progress notifications have a rate limit of limits.max_progress_rate_per_s on both sides.
• RequestOptions.max_total_timeout. A request without a timeout gets limits.request_timeout (60 s).
• OAuthClient.Options.application_type, OAuthClient.lastFailure, ResourceServer.scope_hierarchy and Principal.issuer.
• DPoP (RFC 9449) for the DPoP extension of MCP (mcp.auth.dpop). DpopProver makes a proof for each request and keeps the nonces of each server. The option dpop of OAuthClient, ClientCredentials, EnterpriseClient and WorkloadIdentity requests DPoP-bound tokens. The HTTP client transport sends Authorization: DPoP with a new proof and answers use_dpop_nonce. OAuthClient sends dpop_jkt and can register with dpop_bound_access_tokens.
• ResourceServer.dpop (DpopPolicy) accepts DPoP-bound tokens: the checks of RFC 9449 section 4.3 with a window of 5 minutes, the cnf.jkt binding, optional nonces without state (dpop.NonceIssuer) and an optional replay check. The server refuses a DPoP-bound token with the Bearer scheme. ResourceServer.authorizeRequest takes the DPoP headers. Principal.confirmation has the jkt.
• Workload identity federation (mcp.auth.WorkloadIdentity): a workload JWT from a value, a file or a callback goes to the token endpoint as a JWT bearer grant without client registration. The client does not send a refused JWT again. WorkloadJwtValidator and KeyDiscovery (OpenID Connect Discovery) check workload JWTs for an application with its own authorization server.
• Server.Options.authorization_extensions has dpop and workload_identity. The conformance client passes auth/dpop, auth/dpop-nonce and auth/wif-jwt-bearer.
• The CI job conformance runs each scenario that the suite does not score alone, with the per-check baseline conformance/expected-failures-unscored.yml. A failure of these scenarios now makes the job fail.
• Rate limits for each caller (limits.rate_limits): a token bucket for the tool calls of each caller, one for all tool calls together, one for the log messages of each caller, and ToolDef.rate_limit for one tool. The caller is the principal, else the IP address (an IPv6 /64 network), else the connection. A refused tool call gets error -31429 with data.retryAfterMs, and on HTTP with a JSON response also status 429 with Retry-After. The server drops log messages over the limit and later sends one summary with the count. The limits are off by default. The table of callers has at most max_callers entries. Server.rateLimitStats gives the counters.
• The TLS cipher suites TLS_AEGIS_128L_SHA256 and TLS_AEGIS_256_SHA512 as an option of the TLS client and server (tls.suites.default_suites_with_aegis). They are off by default. HttpClient.TlsSetup.cipher_suites selects them for the HTTP client.
• Record padding in the TLS client and server (RFC 8446 section 5.4): the option padding with the policies none, block and random, and Connection.setPadding. Padding stops at an inner plaintext of 2^14 bytes. HttpClient.TlsSetup.padding sets it for the HTTP client.
• The TLS server option retry_cookie sends a HelloRetryRequest with a random cookie and requires the cookie in the second ClientHello (RFC 8446 section 4.2.2).
• A fuzz target for the TLS record layer: records with each padding policy, input in pieces of any size, line, short and buffered reads, and one changed byte.
• OAuthClient refreshes the access token with the refresh token before it expires (refresh_margin_seconds) and after a 401 challenge. It keeps a rotated refresh token, never asks for a wider scope, sends a DPoP proof for a DPoP-bound grant, and runs the authorization code flow again when the server refuses the refresh token.
• Token storage for OAuthClient (storage, storage_identity): the registration and the tokens of each issuer, resource and client go to a mcp.auth.TokenStorage, so a new process needs no new sign-in. MemoryTokenStorage keeps the records in memory. FileTokenStorage encrypts each record with AES-256-GCM and a key of the application, in a private directory. KeychainTokenStorage uses the keychain of the host: the Credential Manager on Windows, Keychain Services on macOS (loaded at run time) and the Secret Service on the D-Bus bus of the user on Linux, with a D-Bus client in the SDK. The example `cl...

v0.1.0

Added

• Protocol types for MCP specification revision 2026-07-28.
• JSON-RPC envelope parsing and writers.
• Server engine with tools, resources, resource templates, prompts, completion, pagination, multi round-trip requests and subscriptions.
• stdio transport for servers.
• Streamable HTTP transport for servers with SSE responses and header mirroring.
• Client (mcp.Client) with typed requests, progress and log callbacks, the multi round-trip driver over application hooks, and three client transports: in-memory, stdio with process management, and Streamable HTTP with header mirroring.
• OAuth 2.1 authorization client (mcp.auth.OAuthClient): protected resource and authorization server metadata discovery, pre-registered, client ID metadata document and dynamic registration, PKCE S256, resource indicators, iss validation, scope selection with step-up limits, and per-issuer credentials. The HTTP client transport answers 401 and 403 challenges with it.
• Resource server helpers (mcp.auth.ResourceServer, mcp.auth.JwtVerifier): protected resource metadata, bearer token checks with WWW-Authenticate challenges, JWT verification with HS256, ES256, RS256 and PS256, and the principal in the request context. The HTTP server serves them with the auth option.
• In-tree TLS 1.3 server (mcp.tls) with ECDSA P-256, P-384 and Ed25519 certificates, X25519, P-256 and P-384 key exchange, HelloRetryRequest, ALPN and server name indication. The HTTP transport serves HTTPS with the tls option.
• Tasks extension for servers (mcp.tasks): the tasks server option, task_support per tool, the .start_task outcome, tasks/get, tasks/update and tasks/cancel, input requests inside a task, cancellation and the -32021 gate.
• Tasks extension for clients: callTool waits for a task and answers its input requests with the hooks; callToolOrTask, getTask, updateTask, cancelTask and awaitTask give full control. The HTTP client mirrors the task id into Mcp-Name.
• stdio client process management: process groups on POSIX and a job object on Windows, shutdown escalation (SIGTERM, then SIGKILL) after limits.shutdown_grace, and restarts of a crashed server process with max_restarts.
• Client result cache (Client.Options.cache, RequestOptions.cache_mode): results with a positive ttlMs are served again until they expire, a list-changed notification arrives, or invalidateCache runs.
• Client retry of requests whose stream was lost before a response byte: RequestOptions.retry (auto, never, force) bounded by limits.max_lost_stream_retries. force reopens a listen stream after a restart.
• In-tree TLS 1.3 client (mcp.tls.connect): chain validation with a CA set, the std bundle, a pinned leaf or a self-signed policy; host name and IP address checks; CA constraints; ALPN; HelloRetryRequest; client certificates. The server can ask for client certificates (client_auth, client_trust).
• The Streamable HTTP client runs on an SDK-owned HTTP/1.1 connection (mcp.transport.http1) and uses the SDK TLS client for https (HttpClient.Options.tls).
• gRPC transport in the module mcp_grpc: a JSON-RPC tunnel over HTTP/2 (proto/mcp_zig_transport_v1.proto) with its own protobuf wire format, HPACK with the RFC 7541 tables, an HTTP/2 connection with flow control, and the gRPC server (mcp_grpc.Server) and client (mcp_grpc.Channel) transports. Metadata mirrors the HTTP headers; errors before the first message travel in the trailers with mcp-error-code and mcp-error-bin.
• Conformance fixture server and a CI job that runs the official conformance suite. The fixture server serves gRPC with --grpc-port; the CI job grpc-interop calls it from a Node http2 peer and from curl over HTTP/2.
• Comptime JSON Schema derivation from Zig types.
• JSON Schema 2020-12 subset validator. Tool arguments are checked against the input schema and structured output against the output schema.
• Build steps test, fmt, examples, docs, lint-docs, census, commit-policy, conformance-server, conformance-client, gen-bibliography, gen-dictionary, bench, check-version, changelog-section.
• Benchmarks (zig build bench) for request dispatch, HPACK decoding and the TLS handshake, with the baseline in docs/generated/bench.md and a nightly smoke run.
• Fuzz targets for every parser (zig build test --fuzz), run nightly. A certificate precheck now rejects malformed peer certificates before the std parser reads them; the first fuzz run found that the std parser reads out of bounds on truncated input.
• CI workflow with a GitHub-native Zig installation step, a consumer build through b.dependency, a nightly workflow (wiki lint, link check, ReleaseSafe matrix) and a release workflow that verifies the signed tag and publishes the changelog section.