imqueue/mcp

A Model Context Protocol server for **@imqueue**. It lets AI coding agents (Claude Code, ChatGPT, Codex, Cursor, VS Code, JetBrains, …) **search the @imqueue documentation**, **scaffold typed services & clients**, and **drive the imq CLI** — so they generate correct, idiomatic @imqueue code instead of guessing.
📖 **Full documentation: imqueue.org/mcp** — per-client setup, complete tools reference, agent workflows and the safety model.
Tools
Two surfaces, and they are not the same. The **local** server (npx -y @imqueue/mcp) has all 14 tools. The **hosted** server (mcp.imqueue.org/mcp) has seven, all read-only — see below for why.
Hosted + local
| Tool | What it does |
|---|---|
| search_docs | Search the official docs (guides, tutorial, CLI manual, API reference, articles) and return the most relevant pages + URLs. |
| get_doc | Fetch the full markdown of a doc page by URL. |
| list_packages | List the documented @imqueue packages with install commands, current versions and licences. |
| package_status | The current version, licence, minimum Node and last release date of any published @imqueue package, or all of them. |
| scaffold_service | Generate an IMQService subclass with @expose()d, JSDoc-typed methods + a bootstrap (offline, no CLI needed). |
| scaffold_client | Show how to generate and use the fully-typed client for a service (offline). |
All six are read-only: they fetch or generate text and write nothing.
All five also declare an MCP **outputSchema** and return structuredContent alongside the human-readable markdown, so a client can consume results as data — take results[0].url from search_docs and hand it to get_doc, or write scaffold_service's files[] straight to disk — instead of parsing prose and code fences. For the scaffolders and the catalogue the markdown is *rendered from* that same structure, so the two can't drift.
**get_doc's schema is metadata only, on purpose** — and that turns out to be the more interesting design than having no schema at all. A schema obliges the server to send structuredContent, but nothing says structuredContent must repeat what is in content: it describes the structured *part* of the answer. So the page travels once, in content, and the schema carries url (the mirror actually fetched, which is not always the URL you passed), mimeType, bytes (so a caller can decide before reading) and truncated. Putting markdown in there as well would have doubled the largest response the server can produce — measured on /api/rpc/latest/, 16.6 kB of text plus 16.6 kB of structure for one read. The absence of a body field is itself self-describing: a caller reading the schema sees no content field and knows the page is in content, which is where every client already looks.
The CLI-backed tools have no schema: they return imq stdout, which has no shape worth promising.
CLI-backed tools — local only (require @imqueue/cli on PATH)
These drive the **real** CLI, so they act on the machine the server runs on. They exist in the local install only; the hosted server does not register them.
| Tool | What it does |
|---|---|
| cli_status | Detect imq and report its version. |
| cli_install | Install @imqueue/cli globally (npm i -g @imqueue/cli) when it's missing. |
| cli_help | imq --help — exact, version-accurate flags (no side effects). |
| create_service | imq service create — **dry-run by default** (writes nothing); pass apply: true to actually create the project. |
| generate_client | imq client generate — the real typed client (the service must be running). |