Comparisons

created:      2026-09-30T08:00:00-05:00
last-updated: 2026-09-30T08:00:00-05:00
increment:    1
status:       standard
tags:         area:compare
description:  mcpx next to the five MCP revisions, opencode v1 and v2,
              lootbox and Cloudflare code mode: a granular register of
              every difference, capability matrices, and plain answers to
              the questions the comparison raises.

mcpx sits between things that disagree. There are five revisions of the Model Context Protocol, two of them eras apart. There are two opencodes with different plugin APIs and different ideas of what an MCP server is for. And there are three other ways to run code against MCP tools. This directory records every difference found between them, what each difference is worth to mcpx, and where mcpx stood at one named commit.

It is the “living comparison” that #153 recommends (approach C). The earlier records, ../../ASSESSMENT.md and ../../OPENCODE-V2.md, are left as they were; where this directory finds them wrong it says so (conflicts.md §E).

Start here

Matrices

The register

One row per difference: one field, one method, one error code, one header or one behaviour. Each area file has a table (ID, difference, labels, where it exists, mcpx status, value, effort, risk). Below the table is one block per row with the detail: field names, error codes, edge cases, behaviour the specifications imply without stating, and a source for every claim.

Two areas are not in the list the register was asked for, because the 2026 revision made them matter: pagination and caching (CacheableResult is new and required) and input_required, which is one mechanism under three features.

Labels

Every row carries every label that applies.

Cloudflare code mode has no label of its own. Rows about it name it in where it exists and use the other labels for what it means for mcpx.

The other columns

• mcpx status (header mcpx @ 05c78b2): ✓ works as defined · partial (the cell says how) · ✗ missing or broken · n/a · acc. accepted beyond what the revision defines (accept liberally), then a few words.
• Value: + what mcpx gains by doing it, − what it costs or why it is moot; high, med or low.
• Effort: S (hours), M (days), L (a week or more), XL (a redesign).
• Risk: what breaks, or who is surprised, if it is done or if it is not.

Where each mcpx missing row is tracked

Every mcpx missing row names its issue in the status cell. Most issues group the rows one fix would close, so there are fewer issues than rows. All are in the milestone mcpx: backlog build-out; the ones where mcpx declares something it does not deliver hang under #177, the rest under #181.

Refreshing the status column

The status column is a snapshot of mcpx at 05c78b2, and mcpx has changed since – including fixes to rows in every area. Treat every mcpx @ 05c78b2 cell as out of date until re-checked; some are wrong in mcpx’s favour. They are not refreshed piecemeal, because refreshing a 511-row register by hand is how a register starts lying: it is better to know the whole column is stale than to trust a column that was half updated.

What has landed since is not listed here, because a hand-kept list goes stale the same way. Ask git:

git log --oneline 05c78b2..HEAD -- pkgs/mcpx

For the protocol rows, the current status of each specification requirement is ../spec/conformance-matrix.md, which is generated from the tests and checked on every go test.

To refresh:

1. Pick the new commit. Replace 05c78b2 in the header of each table and in the mcpx @ field of each block you re-check.
2. For each row, re-read the mcpx path:line citations in its block. The status cell and the mcpx @ field are the only parts that describe mcpx. Everything else describes a specification or another product, and stays true until that changes.
3. Where the fix landed, set the cell to ✓ and drop mcpx missing from the labels. Keep the row: the difference between the revisions is still real.
4. Update the counts above.

matrix-mcpx.md has the same property: each row cites the code it describes.

Citations

Every claim has a source, in one of these forms:

Quoted text after a citation is verbatim from that line. Four quotes of specification prose have relative links expanded to absolute ones.

Related documents

• ../protocol.md: mcpx’s own protocol design (accept liberally, send conservatively, one downgrade() at the edge). This directory records differences and conflicts; it does not restate that design.
• docs/spec/server-obligations.md: the exhaustive list of what a server MUST and SHOULD do per revision. The protocol work is writing it, and it is not on main at 05c78b2. what-a-server-should-be.md summarises the character of each revision and product, not the obligations.
• ../opencode-plugin.md: the plugin’s design. Claims in it that the pinned sources contradict are in conflicts.md §E.