@imqueue/mcp
A Model Context Protocol server for @imqueue. It lets AI coding agents (Claude Code, 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 13 tools. The hosted server (mcp.imqueue.org/mcp) has six, 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 main @imqueue packages with install commands. |
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 five are read-only: they fetch or generate text and write nothing.
search_docs, list_packages and the two scaffold_* tools 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. The markdown is rendered from that same structure, so the two can't drift.
get_doc has no schema, on purpose. A schema obliges the server to send structuredContent, and its only possible fields would be the URL you passed in and the page body verbatim ā so it would ship the page twice. On a large API reference that is 16.6 kB of text plus 16.6 kB of structure for one read. Structure earns its place when it makes something possible that parsing prose does not; restating the payload is not that. The CLI-backed tools have no schema either: 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 <command> --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 <Service> ā the real typed client (the service must be running). |
fleet | imq ctl <start|stop|restart|status> ā manage a directory of service repos. status is read-only. |
config | imq config <check|get|set|init> ā read/write CLI configuration (set for automation; init is interactive). |
logs | imq log ā dump current fleet logs (never follows; capped) or clean them. |
Calls run with stdin closed and a timeout, so a missing-flag prompt fails fast instead of hanging. If imq isn't installed, run cli_install or use the offline scaffold_* tools.
Docs are fetched live from imqueue.org's machine-readable feeds (/llms.txt, per-page ā¦/index.md mirrors), so the server never ships stale content. It only ever fetches imqueue.org.
Install
Requires Node.js ā„ 18. No build step for users ā run straight from npm:
npx -y @imqueue/mcp
Claude Code
claude mcp add imqueue -- npx -y @imqueue/mcp
Other clients (Cursor, Claude Desktop, JetBrains, Windsurf, Zed, ā¦)
Add to your MCP config (.cursor/mcp.json, claude_desktop_config.json, ā¦):
{
"mcpServers": {
"imqueue": {
"command": "npx",
"args": ["-y", "@imqueue/mcp"]
}
}
}
VS Code and Visual Studio use a top-level
serverskey with"type": "stdio"instead ofmcpServers. See imqueue.org/mcp/installation for the exact config file path and snippet for every client.
Hosted server (no install)
If your client supports remote MCP servers and you only need docs and scaffolding, point it at the hosted endpoint instead:
{ "mcpServers": { "imqueue": { "url": "https://mcp.imqueue.org/mcp" } } }
It serves six tools, all read-only: the five above plus local_install_guide, which returns the setup steps for the local install.
It does not offer the CLI-backed tools, by design. Those act on your machine ā your project files, your running services, your CLI config ā which a server running on Cloudflare's edge cannot reach. Advertising them there would mean listing tools that can never do what their names say, so they are not registered at all in remote mode. If you need them, install locally.
Develop
npm install
npm run build # tsc -> dist/
npm run dev # run from source with tsx
npm run smoke # local surface: handshake + tools/list + annotations + tool calls
The hosted surface has its own check, because it is a different contract:
npm run dev:worker # wrangler dev on :8787
node scripts/remote-smoke.mjs http://localhost:8787/mcp
npm run smoke:remote # or against production
It asserts the exact six-tool list and that every one of them is read-only ā the assertion that stops a future refactor from quietly re-exposing a CLI tool on the hosted endpoint.
Example
User: "Create an @imqueue user service with a getUser(id) method."
The agent calls
scaffold_service({ name: "user", methods: [{ name: "getUser", params: [{ name: "id", type: "number" }], returns: "User" }] })and gets a ready-to-pasteUserService+ bootstrap, thensearch_docs("run a service")/get_doc(...)to wire it up.
License
GPL-3.0 ā free and open source.
Commercial licensing
Need to use @imqueue/mcp in a closed-source product, or want commercial support? A commercial license is available ā see imqueue.com. Full docs: imqueue.org/mcp. See SPEC.md for the design and registry-distribution plan.