@imqueue is an open-source TypeScript framework for building microservices that
talk over a message queue instead of HTTP — you write a class, decorate the
methods you want to publish, and callers get a fully-typed client generated from
the running service.
This server gives your assistant first-hand knowledge of it, so it writes real
@imqueue code instead of plausible-looking code.
search_docs covers the guides, the tutorial, the CLI manual, the articles, and
every exported symbol of every @imqueue package that publishes an API reference —
so you can ask a question in plain words ("how do I expose a service method?") or
look up an exact signature ("RedisQueue.send", "IMQOptions.safeDelivery"). It
ranks with the same engine imqueue.org's own search uses, so the site and this
server agree about which page answers a question, and licensing and pricing
questions answer from imqueue.com rather than the framework docs. A result can
point at a section rather than a whole page, and get_doc follows that anchor:
give it a URL with a #fragment and it returns just that section, with the heading
path above it and its position on the page, so you can see what was left out and
ask for the rest. Without a fragment it returns the whole page as plain markdown
for reading and quoting. list_packages returns the current package catalogue with
install commands, which is how an assistant picks the right one rather than
guessing at a name. Where two packages cover the same ground — tracing, or the
database layer — the results carry the rule for choosing exactly one, because
installing both breaks quietly rather than loudly.
package_status answers the version question outright: the current version,
licence, minimum Node version and release date of one @imqueue package or of all
of them, read from imqueue.org at the moment you ask rather than recalled. It
also answers for the framework as a whole — the Node and Redis floors, and a
licence note that states the licence terms in a sentence.
scaffold_service generates an idiomatic service — an IMQService subclass with
@expose()d, JSDoc-typed methods plus a bootstrap that starts it — from the method
signatures you describe. A custom return type comes back with the @classType() and
@property() decorators it needs, which matters because a field that lacks them
reaches the generated client typed any and still compiles. scaffold_client shows
how to generate and use the typed client for a service. Both return source text
for you to review and paste; neither writes a file.
All seven tools are read-only. The server has no accounts, no authentication and
no storage: each request is handled statelessly, and the only data it sees is the
argument you send — a search query, a doc URL, a package or service name. Nothing
is retained, and no conversation content is collected or used for training.
Tools that would act on your own machine — driving the imq CLI, creating projects
on disk, starting and stopping your services, reading their logs — are
deliberately not part of this server, because a hosted server cannot reach your
machine and should not claim to. They ship in the local install instead
(npx -y @imqueue/mcp), and local_install_guide returns the setup steps for it.