Skip to main content
Glama

wasm-mcp

Model Context Protocol server for the WebAssembly core specification. SHA-pinned, read-only, deterministic — safe to host as a public unauthenticated endpoint.

Not affiliated with, endorsed by, or sponsored by the W3C WebAssembly Community Group or Working Group.

What it gives you

  • spec_version — the pinned upstream commit and package version.

  • instruction_get — opcode bytes, category, introducing version, stack type signature, validation + execution prose anchors / URLs, and trap conditions (traps + can_trap), by mnemonic (i32.add) or binary opcode (0x6a).

  • instruction_list — enumerate, filterable by category (numeric, vector, reference, parametric, variable, table, memory, control, ref, i31, struct, array, extern), introducing version, or prefix.

  • instruction_search — ranked free-text search across mnemonics, categories, and opcodes.

  • type_get — value types (number / vector / reference) and type forms (functype, limits, memtype, …) with defining prose.

  • section_get — one spec clause by id / anchor (structure, validation, execution, binary, text), with prose, cross-references, SpecTec formal-rule references, and the rendered URL.

  • section_list — navigate the clause tree by area or anchor prefix.

  • spec_search — full-text search across anchors, titles, and prose.

  • proposal_list — WebAssembly proposals and their phases (from the pinned WebAssembly/proposals repo), filterable by status, phase, champion, or affected spec.

section_get, section_list, and spec_search take a spec argument covering all three specs in the WebAssembly/spec repo: core (default), js-api (the JavaScript embedding API), and web-api (Web-platform integration). The instruction and type tools are core-only.

Related MCP server: speclib-mcp

Contract

Every tool is:

  • Read-only. No state mutation, no writes outside an optional local cache.

  • Deterministic. Same input → same output, over the pinned spec commit recorded in vendor/PINNED.txt.

  • No execution. Never compiles, validates-by-running, instantiates, or runs any WebAssembly or arbitrary code. Validation and reduction rules are returned as data.

  • No auth, no secrets, no PII. Usable anonymously.

  • No network at request time. All spec data is fetched and indexed at build time and baked into the package.

Install (stdio, local)

npx wasm-mcp

Wire it into any MCP client by adding the server to its config (the launch command is the same everywhere; only the config file differs):

{
  "mcpServers": {
    "wasm": {
      "type": "stdio",
      "command": "npx",
      "args": ["wasm-mcp"]
    }
  }
}

Hosted Worker

The Cloudflare Worker in worker/ exposes the same tool surface as the stdio package over streamable HTTP at a single unauthenticated endpoint, rate-limited per source IP (30 req / 60 s):

https://mcp.xyzzylabs.ai/wasm/mcp

GET /wasm/health reports status and the pinned SHAs; GET /wasm/privacy states the anonymous, no-storage posture. All spec data is bundled into the Worker, so it does pure in-memory lookups — no storage, no network at request time.

Releases & data refresh

The pinned commits live in vendor/PINNED.txt and are reported by spec_version. A scheduled GitHub Actions workflow (refresh.yml) SHA-diffs the upstream repos daily; when a pin moves it re-pins, bumps the patch version, and tags a release, which publishes the npm package (release.yml) and redeploys the Worker (deploy-worker.yml).

Maintainers:

  • npm publish uses Trusted Publishing (OIDC) — no NPM_TOKEN. Configure it once on npmjs.com (wasm-mcp → Settings → Trusted Publisher → GitHub Actions: org xyzzylabs, repo wasm-mcp, workflow release.yml).

  • Worker deploy needs CLOUDFLARE_API_TOKEN + CLOUDFLARE_ACCOUNT_ID, stored as environment secrets on the cloudflare GitHub Environment (not repo-wide) with a main + v* deployment rule — see Securing the deploy credentials.

  • For the refresh workflow's tag push to trigger release + deploy, add a WORKFLOW_PAT PAT (contents: write + workflows) — without it, refresh still re-pins and tags, but you run release / deploy manually. (Same secret name tc39-mcp uses, so one PAT — or an xyzzylabs org secret — can serve both repos.)

License

MIT — see LICENSE.

Available Tools

9 tools
instruction_getGet instructionA
Read-only
Inspect

Fetch one WebAssembly instruction by mnemonic (i32.add, br_if) or binary opcode (0x6a, 0xfd 0x89 0x02) as structured JSON: opcode bytes, category, introducing version, stack type signature, validation/execution prose anchors + spec URLs, and traps — the runtime conditions under which it traps (each with the spec's canonical trap name; empty + can_trap: false for instructions that never trap). Provide mnemonic or opcode (mnemonic wins if both match).

Inputs: opcode, version, mnemonic.

instruction_listList instructionsA
Read-only
Inspect

Enumerate WebAssembly instructions with optional filters: category (control, numeric, parametric, variable, table, memory, ref, i31, struct, array, extern, vec), introduced_in (1.0 | 2.0 | 3.0), prefix (mnemonic prefix like i32.), and can_trap (only trapping / only non-trapping instructions). Returns lightweight rows (incl. can_trap) sorted by opcode; follow up with instruction_get for full detail incl. trap conditions.

Inputs: prefix, version, can_trap, category, +1 more.

proposal_listList WebAssembly proposalsA
Read-only
Inspect

List WebAssembly proposals and their phases from the pinned WebAssembly/proposals repository. Filter by status (phase-0…phase-5, finished, inactive), phase (0–5), champion substring, affects (finished proposals touching core / js-api / web-api), or contains (name/champion substring). Each row carries name, status, phase, champion, affected_specs, spec_version, and the proposal URL.

Inputs: phase, status, affects, champion, +1 more.

section_getGet spec sectionA
Read-only
Inspect

Fetch one spec clause by id or anchor, across core / js-api / web-api (set spec). For core: syntax-numtype, valid-unreachable, binary-instr, … For the embedding specs: modules, memories, streaming-modules, … Matches the rendered spec's stable fragment ids. Returns the clause title, cleaned prose, cross-references, the SpecTec formal_refs it cites (core), and the rendered URL. Core validation/execution clauses are SpecTec-generated: prose may be terse, but formal_refs + url point to the formal rule.

Inputs: id (required), spec, version.

section_listList spec sectionsA
Read-only
Inspect

Enumerate spec clauses for navigation, across core / js-api / web-api (set spec). Filter by source path (core: intro, syntax, valid, exec, binary, text, appendix, or sub-paths like syntax/types), anchor_prefix, titled_only, and max_level. Returns lightweight rows {id, anchors, title, level, path, url}; follow up with section_get.

Inputs: path, spec, version, max_level, +2 more.

spec_versionPinned spec versionA
Read-only
Inspect

Return self-description of this MCP server: package name + version, plus the pinned upstream commit SHA for every spec snapshot baked into the package. Use this first when citing the spec, or to verify the server's freshness and reproducibility.

Inputs: no named parameters.

type_getGet typeA
Read-only
Inspect

Look up a WebAssembly type or type form by name: concrete value types (i32, i64, f32, f64, v128, funcref, externref, …) or type forms (functype, limits, memtype, tabletype, globaltype, reftype, valtype, rectype, heaptype, …). Returns its classification, sibling members for category types, defining clause prose, SpecTec formal-rule references, and the rendered spec URL.

Inputs: name (required), version.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A4.5/5.0

    Scored across 9 tools

    Disambiguation5/5

    Each tool targets a distinct aspect: server metadata, instructions (with clear get/list/search separation), type lookup, spec sections (get/list/search), and proposals. No overlapping purposes; an agent can easily distinguish them.

    Naming Consistency4/5

    Most tools follow a noun_verb pattern (e.g., instruction_get, type_get, section_list). The exception is spec_version (noun_noun), but it's a single outlier and still readable. Overall pattern is predictable.

    Tool Count5/5

    9 tools is well-scoped for a WebAssembly spec reference server. Each tool provides unique functionality without being too few or too many, covering instructions, types, sections, and proposals.

    Completeness5/5

    The tool set covers the core reference needs: instruction lookup/enumeration/search, type lookup, spec section navigation and search, and proposal listing. There are no obvious gaps for the server's purpose of providing spec information.

    Maintenance

    ActivityActive
    ResponsivenessNo recent community issues

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      A
      quality
      B
      maintenance
      MCP Server for accessing W3C/WHATWG/IETF web specifications. Provides AI assistants with access to official web standards data including specifications, WebIDL definitions, CSS properties, and HTML elements.
      11
      16 npm
      4
      MIT
    • F
      license
      Not graded
      quality
      D
      maintenance
      An MCP server that enables AI agents to search, discover, and retrieve technical specifications from a SpecLib instance. It provides tools for full-text search, scope listing, and reading specs as markdown content.
      -
    • A
      license
      Not graded
      quality
      D
      maintenance
      MCP server for exploring the ECMAScript specification and its implementation, enabling semantic search of spec sections, JavaScript execution in engine262, and access to a knowledge graph linking spec sections to implementation functions.
      19 npm
      ISC