xyzzylabs.ai

tc39-mcp serves read-only structured data from the TC39 specs (ECMA-262 + ECMA-402), tc39/test262, and tc39/proposals. Every response is deterministic over data pinned to specific upstream SHAs. Independent project — not an official Ecma International or TC39 publication. This is the hosted Cloudflare Worker deployment — 17 of the 19 tools (call tools/list for the set). The 2 stdio-only ones (spec.history, test262.get) are available via the stdio server (npx tc39-mcp). Common workflow: 1. `spec.about` — call first to see what SHAs and editions the server is serving. Returns per-snapshot pin metadata. 2. `spec.search` — find a clause from a name or symptom. Hits rank aoid-exact > aoid-substring > title > id; follow up with `clause.get { id }` to read the full clause. To find clauses by what they DO (e.g. which clauses invoke OrdinaryGetOwnProperty), pass search_steps: true to also scan algorithm step text — off by default since it is slower + noisier. 3. `clause.get { id, spec?, edition? }` — full structured clause. A clause id is also a test262 esid — test262.search { esid: <clause-id> } returns the conformance tests for that clause. Edition semantics. `latest` is spec-aware: - On 262, `latest` → current stable release (es2026 today). - On 402, `latest` → current stable release (es2026 today). - `main` is always the working draft. Historical pinning. `main` moves. Pass `at: "<sha>"` to query a specific historical snapshot (4-40 hex chars, prefix-matched). The hosted Worker retains every `main` SHA it has deployed since launch; the live snapshot is `at`-less. Released editions like `es2026` have no per-SHA history, so `at` doesn't apply — it only addresses `main`. Missing data is never an error. Tools return null, empty arrays, or a `hint:` field. `source: "none"` on `proposal.list` means the offline index isn't present in R2 — surface the hint to the user. MCP prompts (workflow templates) — prefer these when the user wants a guided multi-tool sequence. Available prompts: explain-clause, compare-editions, find-and-read, trace-crossrefs, proposal-status, test262-for-feature, cite-reproducibly. Call prompts/list for their argument shapes. All data is read-only: no tool modifies anything upstream, no tool runs user-supplied code. Safe to call freely.

wasm-mcp serves read-only structured data from the WebAssembly core specification (https://github.com/WebAssembly/spec). Every response is deterministic over data pinned to a specific upstream commit and baked into the package at build time. Not affiliated with, endorsed by, or sponsored by the W3C WebAssembly Community Group or Working Group. Common workflow: 1. `spec_version` — call first when you need to cite the spec or report what you're reading. Returns the pinned upstream commit. 2. `instruction_search` — find an instruction from a partial name or symptom ("extend", "trunc", "0x6a") when you don't know the exact mnemonic. Returns ranked lightweight hits. 3. `instruction_get { mnemonic }` or `{ opcode }` — the full record for one instruction: opcode bytes, category, stack type signature, and validation/execution prose anchors + URLs. 4. `instruction_list { category? }` — enumerate instructions, filterable by category, introducing version, or mnemonic prefix. 5. `type_get { name }` — a value type or type form ('i32', 'funcref', 'functype', 'limits') with its defining clause prose. 6. `spec_search { query }` — full-text search across clause anchors, titles, and prose when you don't know the anchor. 7. `section_get { id, spec? }` — one spec clause by anchor (e.g. 'syntax-numtype', 'valid-unreachable'): prose, cross-refs, SpecTec formal-rule references, and the rendered URL. 8. `section_list { spec?, path? }` — navigate the clause tree, scoped to an area ('syntax', 'valid', 'exec', 'binary', 'text', 'appendix'). The section tools (section_get / section_list / spec_search) cover three specs via a 'spec' argument: 'core' (default — the instruction set, validation, execution, binary + text formats), 'js-api' (the JavaScript embedding API), and 'web-api' (Web-platform integration). The instruction and type tools are 'core'-only. 9. `proposal_list { status? }` — WebAssembly proposals and their phases, from the pinned WebAssembly/proposals repo. Note on formal notation. Since 2025 the spec is authored in SpecTec; validation / execution clauses are generated from formal rules. This server keeps the hand-written prose and records each clause's SpecTec rule names in 'formal_refs', with 'url' linking the rendered notation. It does not itself render the formal grammar / reduction rules — follow the URL for those. The tool surface is intentionally narrow: - Read-only. No tool mutates state or writes to disk / the network. - Deterministic. Same input → same output, over the pinned commit. - No execution. Tools never compile, validate-by-running, instantiate, or run any WebAssembly or arbitrary code. Validation and reduction rules are returned as data (the prose / typing judgement), not by applying them. Transport differences: - The stdio server (npx wasm-mcp) exposes all 9 tools. - The hosted Cloudflare Worker exposes 9 of them. - Tools that need a subprocess or filesystem (0 today) are stdio-only.