← @imqueueCONTENT HISTORY

Update to @imqueue

Snapshot Oct 7, 2026 · 12:02 UTC · version 3.7.9

WHAT CHANGED · RULE-BASED ANALYSIS

Package or technical metadata updated

Package contents changed in 1 files: .codex-plugin/plugin.json. Open the file diff to inspect the edits.

Observed in package metadata. These changes alone do not establish a new customer-facing feature.

Package file

Before

4fd1c890e2375488834cd0c727b92c6b7bfdfa04bcab7480818af550c7bd7859

After

e71010042e079fb01d25704351e5e1bea71d61379e7a1eba275ecf1831ab4d0e

Package file

Before

5755

After

7529

Compare saved observations

Download comparison JSON

Changed files

.codex-plugin/plugin.json →

.codex-plugin/plugin.json

--- before
+++ after
@@ -3,7 +3,7 @@
   "author": {
     "name": "MYKHAILO STADNYK"
   },
-  "description": "@imqueue is an open-source TypeScript framework for building microservices that\ntalk over a message queue instead of HTTP \u2014 you write a class, decorate the\nmethods you want to publish, and callers get a fully-typed client generated from\nthe running service.\n\nThis server gives your assistant first-hand knowledge of it, so it writes real\n@imqueue code instead of plausible-looking code.\n\nsearch_docs covers the guides, the tutorial, the CLI manual, the articles, and\nevery exported symbol of every @imqueue package that publishes an API reference \u2014\nso you can ask a question in plain words (\"how do I expose a service method?\") or\nlook up an exact signature (\"RedisQueue.send\", \"IMQOptions.safeDelivery\").\nResults carry page URLs, and get_doc returns any page as plain markdown for\nreading and quoting. list_packages returns the current package catalogue with\ninstall commands, which is how an assistant picks the right one rather than\nguessing at a name. Where two packages cover the same ground \u2014 tracing, or the\ndatabase layer \u2014 the results carry the rule for choosing exactly one, because\ninstalling both breaks quietly rather than loudly.\n\nscaffold_service generates an idiomatic service \u2014 an IMQService subclass with\n@expose()d, JSDoc-typed methods plus a bootstrap that starts it \u2014 from the method\nsignatures you describe. A custom return type comes back with the @classType() and\n@property() decorators it needs, which matters because a field that lacks them\nreaches the generated client typed any and still compiles. scaffold_client shows\nhow to generate and use the typed client for a service. Both return source text\nfor you to review and paste; neither writes a file.\n\nAll six tools are read-only. The server has no accounts, no authentication and no\nstorage: each request is handled statelessly, and the only data it sees is the\nargument you send \u2014 a search query, a doc URL, a service name. Nothing is\nretained, and no conversation content is collected or used for training.\n\nTools that would act on your own machine \u2014 driving the imq CLI, creating projects\non disk, starting and stopping your services, reading their logs \u2014 are\ndeliberately not part of this server, because a hosted server cannot reach your\nmachine and should not claim to. They ship in the local install instead\n(npx -y @imqueue/mcp), and local_install_guide returns the setup steps for it.",
+  "description": "@imqueue is an open-source TypeScript framework for building microservices that\ntalk over a message queue instead of HTTP \u2014 you write a class, decorate the\nmethods you want to publish, and callers get a fully-typed client generated from\nthe running service.\n\nThis server gives your assistant first-hand knowledge of it, so it writes real\n@imqueue code instead of plausible-looking code.\n\nsearch_docs covers the guides, the tutorial, the CLI manual, the articles, and\nevery exported symbol of every @imqueue package that publishes an API reference \u2014\nso you can ask a question in plain words (\"how do I expose a service method?\") or\nlook up an exact signature (\"RedisQueue.send\", \"IMQOptions.safeDelivery\"). It\nranks with the same engine imqueue.org's own search uses, so the site and this\nserver agree about which page answers a question, and licensing and pricing\nquestions answer from imqueue.com rather than the framework docs. A result can\npoint at a section rather than a whole page, and get_doc follows that anchor:\ngive it a URL with a #fragment and it returns just that section, with the heading\npath above it and its position on the page, so you can see what was left out and\nask for the rest. Without a fragment it returns the whole page as plain markdown\nfor reading and quoting. list_packages returns the current package catalogue with\ninstall commands, which is how an assistant picks the right one rather than\nguessing at a name. Where two packages cover the same ground \u2014 tracing, or the\ndatabase layer \u2014 the results carry the rule for choosing exactly one, because\ninstalling both breaks quietly rather than loudly.\n\npackage_status answers the version question outright: the current version,\nlicence, minimum Node version and release date of one @imqueue package or of all\nof them, read from imqueue.org at the moment you ask rather than recalled. It\nalso answers for the framework as a whole \u2014 the Node and Redis floors, and a\nlicence note that states the licence terms in a sentence.\n\nscaffold_service generates an idiomatic service \u2014 an IMQService subclass with\n@expose()d, JSDoc-typed methods plus a bootstrap that starts it \u2014 from the method\nsignatures you describe. A custom return type comes back with the @classType() and\n@property() decorators it needs, which matters because a field that lacks them\nreaches the generated client typed any and still compiles. scaffold_client shows\nhow to generate and use the typed client for a service. Both return source text\nfor you to review and paste; neither writes a file.\n\nAll seven tools are read-only. The server has no accounts, no authentication and\nno storage: each request is handled statelessly, and the only data it sees is the\nargument you send \u2014 a search query, a doc URL, a package or service name. Nothing\nis retained, and no conversation content is collected or used for training.\n\nTools that would act on your own machine \u2014 driving the imq CLI, creating projects\non disk, starting and stopping your services, reading their logs \u2014 are\ndeliberately not part of this server, because a hosted server cannot reach your\nmachine and should not claim to. They ship in the local install instead\n(npx -y @imqueue/mcp), and local_install_guide returns the setup steps for it.",
   "interface": {
     "capabilities": [],
     "category": "Developer Tools",
@@ -14,7 +14,7 @@
     ],
     "developerName": "MYKHAILO STADNYK",
     "displayName": "@imqueue",
-    "longDescription": "@imqueue is an open-source TypeScript framework for building microservices that\ntalk over a message queue instead of HTTP \u2014 you write a class, decorate the\nmethods you want to publish, and callers get a fully-typed client generated from\nthe running service.\n\nThis server gives your assistant first-hand knowledge of it, so it writes real\n@imqueue code instead of plausible-looking code.\n\nsearch_docs covers the guides, the tutorial, the CLI manual, the articles, and\nevery exported symbol of every @imqueue package that publishes an API reference \u2014\nso you can ask a question in plain words (\"how do I expose a service method?\") or\nlook up an exact signature (\"RedisQueue.send\", \"IMQOptions.safeDelivery\").\nResults carry page URLs, and get_doc returns any page as plain markdown for\nreading and quoting. list_packages returns the current package catalogue with\ninstall commands, which is how an assistant picks the right one rather than\nguessing at a name. Where two packages cover the same ground \u2014 tracing, or the\ndatabase layer \u2014 the results carry the rule for choosing exactly one, because\ninstalling both breaks quietly rather than loudly.\n\nscaffold_service generates an idiomatic service \u2014 an IMQService subclass with\n@expose()d, JSDoc-typed methods plus a bootstrap that starts it \u2014 from the method\nsignatures you describe. A custom return type comes back with the @classType() and\n@property() decorators it needs, which matters because a field that lacks them\nreaches the generated client typed any and still compiles. scaffold_client shows\nhow to generate and use the typed client for a service. Both return source text\nfor you to review and paste; neither writes a file.\n\nAll six tools are read-only. The server has no accounts, no authentication and no\nstorage: each request is handled statelessly, and the only data it sees is the\nargument you send \u2014 a search query, a doc URL, a service name. Nothing is\nretained, and no conversation content is collected or used for training.\n\nTools that would act on your own machine \u2014 driving the imq CLI, creating projects\non disk, starting and stopping your services, reading their logs \u2014 are\ndeliberately not part of this server, because a hosted server cannot reach your\nmachine and should not claim to. They ship in the local install instead\n(npx -y @imqueue/mcp), and local_install_guide returns the setup steps for it.",
+    "longDescription": "@imqueue is an open-source TypeScript framework for building microservices that\ntalk over a message queue instead of HTTP \u2014 you write a class, decorate the\nmethods you want to publish, and callers get a fully-typed client generated from\nthe running service.\n\nThis server gives your assistant first-hand knowledge of it, so it writes real\n@imqueue code instead of plausible-looking code.\n\nsearch_docs covers the guides, the tutorial, the CLI manual, the articles, and\nevery exported symbol of every @imqueue package that publishes an API reference \u2014\nso you can ask a question in plain words (\"how do I expose a service method?\") or\nlook up an exact signature (\"RedisQueue.send\", \"IMQOptions.safeDelivery\"). It\nranks with the same engine imqueue.org's own search uses, so the site and this\nserver agree about which page answers a question, and licensing and pricing\nquestions answer from imqueue.com rather than the framework docs. A result can\npoint at a section rather than a whole page, and get_doc follows that anchor:\ngive it a URL with a #fragment and it returns just that section, with the heading\npath above it and its position on the page, so you can see what was left out and\nask for the rest. Without a fragment it returns the whole page as plain markdown\nfor reading and quoting. list_packages returns the current package catalogue with\ninstall commands, which is how an assistant picks the right one rather than\nguessing at a name. Where two packages cover the same ground \u2014 tracing, or the\ndatabase layer \u2014 the results carry the rule for choosing exactly one, because\ninstalling both breaks quietly rather than loudly.\n\npackage_status answers the version question outright: the current version,\nlicence, minimum Node version and release date of one @imqueue package or of all\nof them, read from imqueue.org at the moment you ask rather than recalled. It\nalso answers for the framework as a whole \u2014 the Node and Redis floors, and a\nlicence note that states the licence terms in a sentence.\n\nscaffold_service generates an idiomatic service \u2014 an IMQService subclass with\n@expose()d, JSDoc-typed methods plus a bootstrap that starts it \u2014 from the method\nsignatures you describe. A custom return type comes back with the @classType() and\n@property() decorators it needs, which matters because a field that lacks them\nreaches the generated client typed any and still compiles. scaffold_client shows\nhow to generate and use the typed client for a service. Both return source text\nfor you to review and paste; neither writes a file.\n\nAll seven tools are read-only. The server has no accounts, no authentication and\nno storage: each request is handled statelessly, and the only data it sees is the\nargument you send \u2014 a search query, a doc URL, a package or service name. Nothing\nis retained, and no conversation content is collected or used for training.\n\nTools that would act on your own machine \u2014 driving the imq CLI, creating projects\non disk, starting and stopping your services, reading their logs \u2014 are\ndeliberately not part of this server, because a hosted server cannot reach your\nmachine and should not claim to. They ship in the local install instead\n(npx -y @imqueue/mcp), and local_install_guide returns the setup steps for it.",
     "privacyPolicyURL": "https://imqueue.org/privacy/",
     "shortDescription": "Search docs, scaffold code",
     "supportURL": "https://imqueue.org/support/",
@@ -22,5 +22,5 @@
     "websiteURL": "https://imqueue.org"
   },
   "name": "app-6a6f945292888191a7d77db4893f8520",
-  "version": "3.3.0"
+  "version": "3.7.9"
 }
\ No newline at end of file
Full technical diff · 2 changed fields

changed /files/.codex-plugin~1plugin.json/sha256

BEFORE
"4fd1c890e2375488834cd0c727b92c6b7bfdfa04bcab7480818af550c7bd7859"
AFTER
"e71010042e079fb01d25704351e5e1bea71d61379e7a1eba275ecf1831ab4d0e"

changed /files/.codex-plugin~1plugin.json/size

BEFORE
5755
AFTER
7529
Full snapshot data
{
  "files": {
    ".app.json": {
      "sha256": "b2757a861de541c752dabb2ed50fe30e13556a5fefd6caf3e2ca08989a2879fd",
      "size": 127
    },
    ".codex-plugin/plugin.json": {
      "sha256": "e71010042e079fb01d25704351e5e1bea71d61379e7a1eba275ecf1831ab4d0e",
      "size": 7529
    }
  }
}

SHA-256 of public snapshot: fd3862e200f488357b18fec5c8f5d2d68cc4f7f031ec55acf769b40c8d5e2182