.codex-plugin/plugin.json

{
  "apps": "./.app.json",
  "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.",
  "interface": {
    "capabilities": [],
    "category": "Developer Tools",
    "defaultPrompt": [
      "Scaffold a user service with a getUser(id: number) that returns User.",
      "Show me how to generate a fully-typed client for my UserService.",
      "How do I expose a method on a service?"
    ],
    "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.",
    "privacyPolicyURL": "https://imqueue.org/privacy/",
    "shortDescription": "Search docs, scaffold code",
    "supportURL": "https://imqueue.org/support/",
    "termsOfServiceURL": "https://imqueue.org/terms/",
    "websiteURL": "https://imqueue.org"
  },
  "name": "app-6a6f945292888191a7d77db4893f8520",
  "version": "3.3.0"
}