Install any skill in seconds. Free to start, no credit card required.
Get Started Free →awdr74100/mcp-sdk-audit
Upgrade @modelcontextprotocol/sdk and prove the wire contract survived. The SDK is a runtime dependency whose breakage lands on the wire, not in the type checker — so this sorts each release by which SDK source files it touched (Figwright uses only the server + stdio slice of a client/server/multi-transport package), then snapshots what a real MCP client observes — negotiated protocol version, every tool JSON Schema, annotations, prompts — before and after the bump and diffs them.
Passed 11 of 18 test cases with the skill, and 2 of 18 without it.
and 10 more in the full report
10 fixed3 passed either way9 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 10 test cases the skill fixed. Same model, same prompt, with and without the skill.
In Stage 0 version resolution for `@modelcontextprotocol/server`, if the installed version in `pnpm-lock.yaml` matches the target version requested by the user, what action should be taken?
| Checked | Without skill | With skill |
|---|---|---|
| Halts audit execution when requested target matches currently installed lockfile version | Missed | Passed |
The instructions your model reads when the skill loads.
Absorbing a @modelcontextprotocol/server release into Figwright, end to end: audit → upgrade → prove
the wire contract is unchanged.
Do not reason about this the way figma-typings-audit reasons about plugin typings. That package
is types-only, so tsc is a real gate. This one is a runtime dependency: it serializes every
tool result, generates the JSON Schema for every tool, and negotiates the protocol version. A
release can leave every type identical and still change what clients see. pnpm typecheck will stay
green through it.
Unlike every other dependency here, this one has a dedicated gate — use it.
packages/mcp/test/e2e/mcp-wire.test.ts spawns the built dist over real stdio, speaks raw
JSON-RPC at it, and asserts the advertised contract against what the specs declare. It runs in
pnpm test. That gate answers did anything break; it does not answer what moved, which is what
an audit is for — Stage 5 covers the difference.
Know the one thing that gate cannot see. Its schema check compares the SDK's output against
test/tool-schema.ts's derivation, and both call the same z.toJSONSchema. That is independent of
the SDK — it catches an SDK that stops asking Zod the same question — but not of Zod: when Zod
changes what it answers, both sides move together and the equality still holds. An SDK bump that
also moves the resolved zod version (its range is ^4.2.0, so it shares the repo's copy) can
therefore reshape every client's schema with this gate green.
packages/mcp/test/json-schema-generation.test.ts covers that half by pinning each construct's
rendering by hand — if a bump moves the Zod version, read its diff too, and let probe.mjs name
which tools changed.
Target version: whatever the user named, otherwise the latest @modelcontextprotocol/server on npm.
grep '@modelcontextprotocol' packages/mcp/package.json # declared range
grep -m1 '@modelcontextprotocol/server@' pnpm-lock.yaml # what is installed
npm view @modelcontextprotocol/server version dist-tags --json # latest
gh api repos/modelcontextprotocol/typescript-sdk/releases --jq '.[0:15][] | "\(.tag_name)\t\(.published_at)"'
Figwright is on v2 — the package family (@modelcontextprotocol/server + its transitive
/core, with /client, /node, /express, /hono, /fastify, /server-legacy, /codemod
alongside). It depends on exactly one of them.
test cases passed, vs 2 / 18 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.