@imqueue: talk to your services like they're local.
@imqueue is a message-queue RPC framework for Node.js and TypeScript back-ends: services describe themselves at runtime, so their typed clients are generated, not written. No service discovery, no load balancer, no boilerplate — just methods, simplicity and reliability.
Guaranteed hand-off
Safe delivery re-queues a message a dying worker never started, instead of losing it with the process. At-least-once by design — so handlers stay idempotent.
Zero-config balancing
Instances compete for messages and self-balance across nodes. No service discovery, no external load balancer to wire up.
No polling, ever
No timers, no constant polling — zero delivery delay and zero CPU on workers while idle. It rests when there's nothing to do.
Implement a service
Write a class with exposed methods and doc-blocks. That's your whole service.
Generate the client
Services are self-describing — clients are generated on-the-fly or written to files.
Call it remotely
Await a client method like any local call. The queue routes and returns the result.
A message-queue RPC framework for Node.js and TypeScript microservices — and for the AI agents that write them.
@imqueue lets one back-end service call another as if it were a local typed function, while the call itself travels over a Redis-backed message queue instead of HTTP. A service is a class with exposed methods; because it describes its own signatures at runtime, the CLI generates the typed client for you — so there is no schema file, no IDL, and no hand-written SDK to keep in sync.
Because the queue name is the address, instances of a service simply compete for messages. That removes two moving parts most microservice stacks need: service discovery and an internal load balancer.
Reach for it when
Your services are Node.js and TypeScript and talk to each other a lot · you want compile-time-safe calls without maintaining an IDL · you are pulling a first service out of a monolith · you want traffic spikes buffered rather than cascading · or you need delayed and scheduled calls without adding a job system.
Look elsewhere when
Your fleet is polyglot — gRPC is the better answer · the API is public or browser-facing, where REST or GraphQL belongs at the edge · your types already span one shared TypeScript project, which is tRPC's home ground · you want a full application framework rather than a transport, which is NestJS or Moleculer · or you need exactly-once delivery, since handlers here must be idempotent.
An MCP server, live docs, and a typed client your agent never has to guess at.
Point an agent at an @imqueue codebase and it can do the work rather than approximate it.
It calls tools instead of recalling API shapes, looks a symbol up instead
of remembering it, and — because a service describes its own signatures at runtime —
generates the client rather than writing one. That last part is the one that
matters: “did it get the call right?” becomes a question tsc answers at build
time, not a question production answers later.
It calls tools, not guesses
One line wires @imqueue into Claude Code, Claude Desktop, Cursor, VS Code or a JetBrains IDE — @imqueue/mcp is in the official MCP registry as org.imqueue/mcp. Your agent then searches these docs, scaffolds idiomatic services and clients, and drives the real imq CLI itself.
It reads today's docs
Ask about a symbol and your agent looks it up rather than recalling it: every page is served as plain markdown as well as HTML — the whole generated API reference included — and a symbol index maps a name straight to its page, deprecations flagged. No 2024 training snapshot, and no HTML to pick apart. /llms.txt is the map.
It can prove the change worked
The agent recipes are written for a machine, not a reader: the contract each step relies on, the exact commands, the commands that prove the change took effect, and the ways it goes wrong. Not using MCP? One paste-ready context block gets you most of the way.
Read this page as plain markdown — no HTML, no navigation. For pasting into an LLM, or for an agent to fetch.