Skip to main content
Glama

@imqueue

by org.imqueue
OverviewDiscussionsAdmin

Server Details

Search @imqueue docs and scaffold typed services & clients from your AI coding agent.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
100.0% over 46 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL
Repository
imqueue/mcp
GitHub Stars
1
Server Listing
@imqueue/mcp

TDQS

A4.4/5.0

Scored across 7 tools

Disambiguation4/5

Most tools have clearly distinct roles: search_docs finds pages, get_doc fetches them, and scaffold_client/scaffold_service target different artifacts. The main overlap is list_packages and package_status, which both return version, licence, and minimum Node version, so their boundary rests on subtle intent rather than obvious separation.

Naming Consistency4/5

Five tools follow the verb_noun pattern: get_doc, list_packages, search_docs, scaffold_client, and scaffold_service. package_status and local_install_guide are readable noun phrases that break the consistent verb-first convention, but the names are still predictable and unambiguous.

Tool Count5/5

Seven tools is a well-scoped count for a documentation, package-discovery, and scaffolding server. Each tool serves a distinct step in the workflow: search, fetch, catalogue, status, install guidance, and client/service scaffolding.

Completeness4/5

The core documentation and package metadata workflows are well covered: search, read, list, and status are all present, and scaffold_client/scaffold_service provide useful read-only templates. The main gap is that actual file-generation and CLI execution are only described as available through a local install, so the hosted server can guide but not complete those actions.

Available Tools

7 tools
get_docRead an @imqueue doc pageA
Read-onlyIdempotent
Inspect

Fetch the markdown of an @imqueue documentation page by its URL (as returned by search_docs). Returns plain markdown suitable for reading and quoting. Pass a URL with a #fragment — which is what search_docs returns for a section result — to get just that section plus the heading path above it; pass the URL without one to read the whole page. Only imqueue.org (framework docs) and imqueue.com (licensing, pricing, support) URLs are fetched; anything else is refused. Very large pages are truncated, which the result reports.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesAn imqueue.org or imqueue.com page URL, e.g. https://imqueue.org/get-started/

Output Schema

ParametersJSON Schema
NameRequiredDescription
urlYesThe markdown mirror actually fetched — not always the URL passed in, which is why it is worth returning
bytesYesSize of the page body, so a caller can decide before reading it
sectionNoPresent when a #fragment resolved to one section — markdown is that section, not the page
markdownYesThe page body — the same text carried in content, minus the heading path prefix
mimeTypeYesMedia type of the page body carried in markdown and content
truncatedYesTrue when the page was too large to return whole — markdown holds the leading part only
fragmentMissNoPresent when a #fragment matched no indexed section — markdown is the WHOLE page, not the slice that was asked for

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare read-only, idempotent, non-destructive behavior. The description adds valuable behavioral details: truncation of large pages (with reporting), refusal of non-imqueue URLs, and how fragments affect the returned content. This goes beyond the annotations without contradicting them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is four sentences, each adding meaningful information: purpose, fragment behavior, domain restriction, and truncation. It is front-loaded with the primary action and avoids redundancy, making it efficient and easy to process.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With a single well-documented parameter and annotations covering safety, the description covers everything needed: how to get sections vs. whole pages, allowed domains, and truncation reporting. An output schema exists, so return details are handled separately; no gaps remain for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers the url parameter with a description and example (100% coverage). The tool description adds extra semantics: how fragments change the output, explicit domain whitelist, and truncation behavior, which enriches understanding of the parameter's usage beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action: 'Fetch the markdown of an @imqueue documentation page by its URL'. It also differentiates from siblings by referencing search_docs as the source of URLs and explaining fragment vs. whole-page behavior, distinguishing it clearly from list/search tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly ties usage to search_docs results and describes how to use fragments for sections, which conveys the intended workflow. It does not explicitly contrast with other tools (no obvious alternative exists), but it states constraints like allowed domains and refusal of others, giving clear context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_packagesList @imqueue packagesA
Read-onlyIdempotent
Inspect

The complete, authoritative catalogue of documented @imqueue packages, each with its current version, licence, minimum Node version, a one-line summary and its exact install command. Call this BEFORE adding any @imqueue dependency: search_docs can only find a package you already suspect exists, and this is the list. Covers typed RPC over a message queue, the Redis queue engine, the imq CLI, jobs and scheduling, Prisma and Sequelize database toolkits, method caching, tag-invalidated caching, PostgreSQL LISTEN/NOTIFY, Zod validation, OpenTelemetry or Datadog tracing, async logging, GraphQL N+1 batching across services, CIDR/IP checks and HTTP rate limiting. Some pairs are mutually exclusive — pg-prisma vs pg-sequelize, opentelemetry vs datadog — and installing both of a pair breaks silently, so read the pick rule on those entries before choosing. For one package's release history, links and the framework-wide Node and Redis requirements, use package_status.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
packagesYesOrdered by what to reach for first
frameworkNo
factsUnavailableNoTrue when imqueue.org/status.json could not be read, so no entry carries a version or licence. The catalogue itself is compiled in and still complete

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds valuable context beyond that: it states the list is 'complete, authoritative', enumerates the covered domains, and warns that installing mutually exclusive pairs 'breaks silently'. This enriches the agent's understanding of the tool's scope and side-effects without contradicting annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is moderately long but every sentence serves a purpose: it front-loads the core purpose, then provides usage timing, scope, and warnings. It is well-structured and avoids redundancy, though it could be tightened slightly without losing value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters, an output schema exists, and annotations cover safety, the description fully equips an agent: it explains what is listed, when to call it, how it relates to siblings, and warns about edge cases. Nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and the schema is empty (100% coverage). With no parameters, the baseline is 4. The description meaningfully conveys what the returned catalogue contains, which is the only semantic value needed here.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('list') and resource ('@imqueue packages'), and clearly distinguishes itself from search_docs and package_status by naming what it uniquely provides: a complete catalogue with version, licence, Node version, summary, and install command. It is immediately clear what the tool does and how it differs from siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs to call this tool BEFORE adding any @imqueue dependency, and contrasts it with search_docs (which requires a suspected package name). It also warns about mutually exclusive package pairs and directs the agent to read the 'pick' rule. This leaves no ambiguity about when to use this tool versus alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

local_install_guideHow to install the @imqueue MCP server locallyA
Read-onlyIdempotent
Inspect

Return the setup instructions for running the full @imqueue MCP server on your own machine. The local server adds the CLI-backed tools, which act on your project files and running services and so cannot be offered by a hosted server. Returns instructions only — it installs nothing.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
clientConfigYesDrop into an MCP config file as-is. VS Code and Visual Studio use `servers` with type:'stdio' instead of `mcpServers`.
claudeCodeCommandYesOne-liner for Claude Code

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description explicitly states 'it installs nothing', clarifying the tool is purely informational and has no side effects. This adds value beyond the annotations, which already indicate safe read-only and non-destructive behavior. It also explains why the tool exists (local tools cannot be hosted).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, front-loaded with the action, and contains no filler. Every clause serves a purpose: what it returns, why it matters, and what it does not do.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given there are no parameters, an existing output schema, and a simple informational purpose, the description is complete. It states the return value ('instructions'), clarifies side effects, and sets expectations without requiring further detail.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so there is no param schema to document. The description sufficiently explains the single function of the tool without needing parameter-level detail. The baseline of 4 applies appropriately.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool 'Return the setup instructions' for running the full @imqueue MCP server locally, using a specific verb and resource. It also distinguishes from alternative tools by explaining that the local server adds CLI-backed tools that a hosted server cannot offer.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when this tool is relevant: when a user needs to run the server locally to access project/service acting tools. It does not explicitly name alternatives or exclusions, but the context implies when local setup is necessary versus a hosted server.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

package_status@imqueue package versions and licencesA
Read-onlyIdempotent
Inspect

The current version, licence, minimum Node version and last release date of any published @imqueue package — or of all of them. Use it when the user asks which version of an @imqueue package is current, what licence it is under, or which Node or Redis version it needs. Covers every published package, including @imqueue/cli and @imqueue/mcp, and also returns the framework-wide licence, Node and Redis requirements, with a licenseNote that states the licence terms in a sentence. The facts are read from the npm registry by imqueue.org, and the result says when. Pass package for one entry, with or without the @imqueue/ scope; omit it for all of them.

ParametersJSON Schema
NameRequiredDescriptionDefault
packageNoOne package, with or without the scope: 'rpc', '@imqueue/rpc'. Omit for every package.

Output Schema

ParametersJSON Schema
NameRequiredDescription
sourceYes
packagesYes
frameworkYes
generatedYesWhen the site last read these facts from the npm registry

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable extra context: facts are 'read from the npm registry by imqueue.org, and the result says when', disclosing the data source and freshness indication, plus the `licenseNote` return behavior. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is sized appropriately and front-loaded: purpose first, then when-to-use, then output details, then parameter usage. Each sentence carries useful information and nothing is redundant, though slightly more compact phrasing would be possible.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With one optional parameter fully documented by the schema, an output schema covering returns, and annotations covering the read-only, idempotent safety profile, the description is complete for an agent to invoke it correctly. It also adds operational context on data freshness and package coverage that structured fields don't provide.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the schema already documents the single `package` parameter with scope examples and the omit-for-all behavior. The description repeats this ('Pass `package` for one entry... omit it for all of them') without adding new details, so it stays at the baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a precise verb and resource: it returns the current version, licence, minimum Node version, and last release date of any published @imqueue package, or all of them. It also distinguishes scope by naming specific covered packages (@imqueue/cli, @imqueue/mcp) and the framework-wide data, which separates it from siblings like list_packages or get_doc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says when to use the tool: 'when the user asks which version of an @imqueue package is current, what licence it is under, or which Node or Redis version it needs.' It doesn't mention when-not-to-use or name direct alternative tools, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

scaffold_clientScaffold an @imqueue typed clientA
Read-onlyIdempotent
Inspect

READ-ONLY: returns text and writes nothing to disk, and does NOT run the command it shows you. Explains how to generate and use the fully-typed client for an @imqueue service: @imqueue generates the real client from a running service via imq client generate, so this returns that exact command plus an illustrative usage snippet. The generated file exports a single namespace holding the client class, so the import shape is not the obvious one — take it from namespace rather than guessing. Use generate_client (local install only) if you want the command actually run.

ParametersJSON Schema
NameRequiredDescriptionDefault
methodsNoKnown methods (used to shape the example call)
serviceYesThe service to call, e.g. 'user' or 'UserService'

Output Schema

ParametersJSON Schema
NameRequiredDescription
clientYesGenerated client class name
outputYesThe file that command writes (a compiled .js lands beside it)
exampleYesAn illustrative call — not a file to write
serviceYes
namespaceYesThe ONLY export of the generated file: a namespace holding the client class. Import this, then `new <namespace>.<client>()` — importing the class directly does not resolve.
generateCommandYesRun against the RUNNING service to emit the real typed client

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds meaningful behavioral context beyond those: it writes nothing to disk, does NOT execute the displayed command, and warns that the generated file's import shape comes from a namespace rather than the obvious default. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the critical READ-ONLY caveat and every sentence earns its place: the no-execution warning, the command-generation explanation, the namespace import caveat, and the sibling alternative. It is appropriately sized for the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description fully covers what the tool returns, what it does not do, the key import-shape gotcha, and when to choose the sibling tool. An output schema exists, so return-value details are already structured. Nothing an agent needs to invoke this tool correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents both parameters and the nested methods structure. The description adds context about the overall purpose but does not provide additional parameter-level meaning beyond what the schema already contains. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: it 'returns text' and 'Explains how to generate and use the fully-typed client' for an @imqueue service, and explicitly contrasts itself with generate_client. An agent can distinguish this tool from its siblings without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit when-to-use guidance: use this tool when you want the command shown but not run, and 'Use generate_client (local install only) if you want the command actually run.' It also clarifies the read-only nature and names the alternative directly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

scaffold_serviceScaffold an @imqueue serviceA
Read-onlyIdempotent
Inspect

READ-ONLY: returns generated source code as text and writes nothing to disk, creates no project and runs no command. Generates an idiomatic @imqueue/rpc service (an IMQService subclass with @expose()d, JSDoc-typed methods) plus a bootstrap that starts it. Provide the methods you want, or omit them for a starter template. Any non-primitive parameter or return type also gets a types.ts with the required @classType()/@property() declarations — without those the generated client types it any, which compiles. Use create_service (local install only) if you want files actually written.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesService name, e.g. 'user' or 'UserService'
methodsNoMethods to expose

Output Schema

ParametersJSON Schema
NameRequiredDescription
filesYes
typesYesComplex types the signatures refer to. Each needs @classType() on the class and @property() on every field — types.ts declares them; complete the fields. Empty when every type is a primitive.
installYes
serviceYesClass name used, after normalisation ('user' -> 'UserService')
cliAlternativeYesThe CLI command that creates a full provider-wired project instead

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds beyond them: 'writes nothing to disk, creates no project and runs no command', and explains the automatic types.ts generation for non-primitive types with the consequence for client typing. This enriches the safety and side-effect picture well beyond the annotation booleans.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The content is front-loaded with the critical read-only/side-effect-free behavior, then moves from generated service shape to input usage to type handling to the alternative tool. Each sentence carries unique information, and the structure mirrors the decision process an agent goes through.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Between the annotations, a fully described input schema, the existence of an output schema, and the description, an agent has everything needed to invoke this safely and correctly: side effects are disclosed, the alternative is named, input behavior is explained, and the generated output content is covered. No critical gap remains.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already gives 100% descriptive coverage for both parameters, so the baseline is 3. The description goes further by explaining that omitting methods yields a starter template and that non-primitive types trigger types.ts generation, which gives the agent contextual meaning not present in the schema field descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens by naming the exact output: 'returns generated source code as text' for an 'idiomatic @imqueue/rpc service', identifying the verb and resource. It also differentiates itself from sibling tools by stating it 'writes nothing to disk' and by pointing to create_service as the file-writing alternative, making the boundary unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly gives the condition for when to switch to a sibling: 'Use create_service (local install only) if you want files actually written.' It also tells the user how to control generation ('Provide the methods you want, or omit them for a starter template'), which is actionable guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_docsSearch @imqueue documentationA
Read-onlyIdempotent
Inspect

Search the official @imqueue docs (guides, tutorial, CLI manual, articles) and every exported symbol of every @imqueue package that publishes a generated API reference, returning the most relevant pages with their URLs. Each result names the package it belongs to. Takes a plain question or an exact symbol name such as 'RedisQueue.send', 'PgPubSub.listen' or 'watcherCheckDelay'. Answers 'how do I do X in @imqueue' and confirms a signature before code is written against it. Every result carries the page URL, which get_doc reads in full. Some capabilities are covered by two mutually exclusive packages — @imqueue/pg-prisma vs @imqueue/pg-sequelize, @imqueue/opentelemetry vs @imqueue/datadog — so for a query like 'tracing' or 'database', call list_packages for the choosing rule rather than taking whichever package ranks first, and pass package here to search within the one you settled on.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMax results (default 6)
queryYesA question or a symbol name, e.g. 'expose a service method', 'delayed jobs' or 'IMQOptions.safeDelivery'
packageNoRestrict results to one package, e.g. 'http-protect' or '@imqueue/opentelemetry'. Use it once you know which package you want — the same words appear in several packages' symbols.

Output Schema

ParametersJSON Schema
NameRequiredDescription
countYesNumber of results returned (0 means no matches)
queryYesThe query that was searched
resultsYesMost relevant first
advisoriesNoPresent when the results involve two packages that cover the same ground. Each names both options with the rule for choosing — install exactly one, never both.

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, yet the description still adds substantial behavioral context: the corpus spans both prose docs and generated API references, each result names its package and carries a URL, and queries may be plain questions or exact symbol names. It also discloses the package-ambiguity behavior and the search-then-read workflow, which no annotation could convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is longer than average (~170 words), but every sentence earns its place: scope, result shape, query modes, purpose, and the list_packages routing caveat. Core function is front-loaded before the caveats, and there is no redundancy with the schema or annotations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 100% schema coverage, safety annotations, and an output schema present, the description covers everything an agent needs to invoke this tool correctly: what to search, how to phrase queries, which sibling to use instead in ambiguous package cases, and where results lead next. Nothing material is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: it explains the query parameter's dual mode (plain question vs exact symbol names, with concrete examples like 'RedisQueue.send'), and clarifies the intended use of `package` (search within the package you settled on after list_packages). The `limit` parameter is already fully documented in the schema itself.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a precise verb ('Search'), names the exact corpus ('official @imqueue docs... and every exported symbol of every @imqueue package'), and defines the output ('most relevant pages with their URLs'). It also distinguishes itself from siblings by explicitly noting that get_doc reads the pages it returns, so an agent can tell them apart immediately.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states when to use the tool ('Answers how do I do X in @imqueue' and confirms a signature before code is written) and when not to: for ambiguous queries like 'tracing' or 'database', it directs the agent to 'call list_packages for the choosing rule rather than taking whichever package ranks first' and then pass `package` here. The division of labor with get_doc is also made explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool update
    • Changedlist_packages2 fields changed
      • addedOutput schema / properties / framework / properties / licenseNote
        Added value: +{
+  "description": "The licence terms in a sentence, including what the SPDX id alone does not say",
+  "type": "string"
+}
      • changedOutput schema / properties / framework / required
        Previous value: -[
-  "license",
-  "node",
-  "redis",
-  "commercial"
-]New value: +[
+  "license",
+  "licenseNote",
+  "node",
+  "redis",
+  "commercial"
+]
  2. 2 tool updates
    • Changedlist_packages7 fields changed
      • addedOutput schema / properties / factsUnavailable
        Added value: +{
+  "description": "True when imqueue.org/status.json could not be read, so no entry carries a version or licence. The catalogue itself is compiled in and still complete",
+  "type": "boolean"
+}
      • addedOutput schema / properties / framework
        Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "commercial": {
+      "description": "Where to get a licence for closed-source distribution",
+      "type": "string"
+    },
+    "license": {
+      "type": "string"
+    },
+    "node": {
+      "description": "The Node version the framework as a whole requires",
+      "type": "string"
+    },
+    "redis": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "license",
+    "node",
+    "redis",
+    "commercial"
+  ],
+  "type": "object"
+}
      • addedOutput schema / properties / packages / items / properties / deprecated
        Added value: +{
+  "type": "boolean"
+}
      • addedOutput schema / properties / packages / items / properties / license
        Added value: +{
+  "description": "SPDX identifier of the published package",
+  "type": "string"
+}
      • addedOutput schema / properties / packages / items / properties / node
        Added value: +{
+  "description": "engines.node, or null where the package declares no floor of its own",
+  "type": [
+    "string",
+    "null"
+  ]
+}
      • addedOutput schema / properties / packages / items / properties / released
        Added value: +{
+  "description": "Publication date of `version`, as YYYY-MM-DD",
+  "type": "string"
+}
      • addedOutput schema / properties / packages / items / properties / version
        Added value: +{
+  "description": "Highest published release. Absent only if the status feed was unreachable",
+  "type": "string"
+}
    • Addedpackage_status
  3. 6 tool updates
    • Changedget_doc2 fields changed
      • changedInput schema / $schema
        Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
      • changedOutput schema / $schema
        Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • Changedlist_packages2 fields changed
      • changedInput schema / $schema
        Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
      • changedOutput schema / $schema
        Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • Changedlocal_install_guide2 fields changed
      • changedInput schema / $schema
        Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
      • changedOutput schema / $schema
        Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • Changedscaffold_client2 fields changed
      • changedInput schema / $schema
        Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
      • changedOutput schema / $schema
        Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • Changedscaffold_service2 fields changed
      • changedInput schema / $schema
        Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
      • changedOutput schema / $schema
        Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • Changedsearch_docs2 fields changed
      • changedInput schema / $schema
        Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
      • changedOutput schema / $schema
        Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  4. 1 tool update
    • Changedget_doc6 fields changed
      • addedOutput schema / properties / fragmentMiss
        Added value: +{
+  "additionalProperties": false,
+  "description": "Present when a #fragment matched no indexed section — markdown is the WHOLE page, not the slice that was asked for",
+  "properties": {
+    "anchor": {
+      "description": "The #fragment that was asked for and not found",
+      "type": "string"
+    },
+    "available": {
+      "description": "Anchors the page does index, for a retry",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "anchor",
+    "available"
+  ],
+  "type": "object"
+}
      • addedOutput schema / properties / markdown
        Added value: +{
+  "description": "The page body — the same text carried in content, minus the heading path prefix",
+  "type": "string"
+}
      • changedOutput schema / properties / mimeType / description
        Previous value: -"Media type of the page body carried in content"New value: +"Media type of the page body carried in markdown and content"
      • addedOutput schema / properties / section
        Added value: +{
+  "additionalProperties": false,
+  "description": "Present when a #fragment resolved to one section — markdown is that section, not the page",
+  "properties": {
+    "ancestors": {
+      "description": "Headings above it, outermost first — the path that says which 'Verify' this is",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "heading": {
+      "description": "The section's own heading",
+      "type": "string"
+    },
+    "index": {
+      "description": "1-based position among the page's indexed sections",
+      "type": "integer"
+    },
+    "total": {
+      "description": "How many indexed sections the page has, so a caller can see what it did not read",
+      "type": "integer"
+    }
+  },
+  "required": [
+    "heading",
+    "ancestors",
+    "index",
+    "total"
+  ],
+  "type": "object"
+}
      • changedOutput schema / properties / truncated / description
        Previous value: -"True when the page was too large to return whole — content holds the leading part only"New value: +"True when the page was too large to return whole — markdown holds the leading part only"
      • changedOutput schema / required
        Previous value: -[
-  "url",
-  "mimeType",
-  "bytes",
-  "truncated"
-]New value: +[
+  "url",
+  "markdown",
+  "mimeType",
+  "bytes",
+  "truncated"
+]
  5. 1 tool update
    • Changedsearch_docs1 field changed
      • addedOutput schema / properties / advisories
        Added value: +{
+  "description": "Present when the results involve two packages that cover the same ground. Each names both options with the rule for choosing — install exactly one, never both.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
  6. 4 tool updates
    • Changedget_doc3 fields changed
      • changedInput schema / properties / url / description
        Previous value: -"An imqueue.org page URL, e.g. https://imqueue.org/get-started/"New value: +"An imqueue.org or imqueue.com page URL, e.g. https://imqueue.org/get-started/"
      • addedOutput schema / properties / truncated
        Added value: +{
+  "description": "True when the page was too large to return whole — content holds the leading part only",
+  "type": "boolean"
+}
      • changedOutput schema / required
        Previous value: -[
-  "url",
-  "mimeType",
-  "bytes"
-]New value: +[
+  "url",
+  "mimeType",
+  "bytes",
+  "truncated"
+]
    • Changedscaffold_client3 fields changed
      • addedOutput schema / properties / namespace
        Added value: +{
+  "description": "The ONLY export of the generated file: a namespace holding the client class. Import this, then `new <namespace>.<client>()` — importing the class directly does not resolve.",
+  "type": "string"
+}
      • changedOutput schema / properties / output / description
        Previous value: -"Where that command writes the client"New value: +"The file that command writes (a compiled .js lands beside it)"
      • changedOutput schema / required
        Previous value: -[
-  "service",
-  "client",
-  "generateCommand",
-  "output",
-  "example"
-]New value: +[
+  "service",
+  "client",
+  "namespace",
+  "generateCommand",
+  "output",
+  "example"
+]
    • Changedscaffold_service2 fields changed
      • addedOutput schema / properties / types
        Added value: +{
+  "description": "Complex types the signatures refer to. Each needs @classType() on the class and @property() on every field — types.ts declares them; complete the fields. Empty when every type is a primitive.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
      • changedOutput schema / required
        Previous value: -[
-  "service",
-  "install",
-  "files",
-  "cliAlternative"
-]New value: +[
+  "service",
+  "install",
+  "files",
+  "types",
+  "cliAlternative"
+]
    • Changedsearch_docs3 fields changed
      • addedInput schema / properties / package
        Added value: +{
+  "description": "Restrict results to one package, e.g. 'http-protect' or '@imqueue/opentelemetry'. Use it once you know which package you want — the same words appear in several packages' symbols.",
+  "type": "string"
+}
      • addedInput schema / properties / query / maxLength
        Added value: +200
      • addedInput schema / properties / query / minLength
        Added value: +1
  7. 6 tool updates
    • Changedget_doc1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "bytes": {
+      "description": "Size of the page body, so a caller can decide before reading it",
+      "type": "integer"
+    },
+    "mimeType": {
+      "description": "Media type of the page body carried in content",
+      "type": "string"
+    },
+    "url": {
+      "description": "The markdown mirror actually fetched — not always the URL passed in, which is why it is worth returning",
+      "type": "string"
+    }
+  },
+  "required": [
+    "url",
+    "mimeType",
+    "bytes"
+  ],
+  "type": "object"
+}
    • Changedlist_packages1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "packages": {
+      "description": "Ordered by what to reach for first",
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "install": {
+            "description": "The exact install command, including -g where the package is a CLI",
+            "type": "string"
+          },
+          "name": {
+            "type": "string"
+          },
+          "pick": {
+            "description": "Present only where two packages cover similar ground: the rule for choosing between them",
+            "type": "string"
+          },
+          "summary": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "name",
+          "install",
+          "summary"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "packages"
+  ],
+  "type": "object"
+}
    • Changedlocal_install_guide1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "claudeCodeCommand": {
+      "description": "One-liner for Claude Code",
+      "type": "string"
+    },
+    "clientConfig": {
+      "additionalProperties": false,
+      "description": "Drop into an MCP config file as-is. VS Code and Visual Studio use `servers` with type:'stdio' instead of `mcpServers`.",
+      "properties": {
+        "mcpServers": {
+          "additionalProperties": false,
+          "properties": {
+            "imqueue": {
+              "additionalProperties": false,
+              "properties": {
+                "args": {
+                  "items": {
+                    "type": "string"
+                  },
+                  "type": "array"
+                },
+                "command": {
+                  "type": "string"
+                }
+              },
+              "required": [
+                "command",
+                "args"
+              ],
+              "type": "object"
+            }
+          },
+          "required": [
+            "imqueue"
+          ],
+          "type": "object"
+        }
+      },
+      "required": [
+        "mcpServers"
+      ],
+      "type": "object"
+    }
+  },
+  "required": [
+    "claudeCodeCommand",
+    "clientConfig"
+  ],
+  "type": "object"
+}
    • Changedscaffold_client1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "client": {
+      "description": "Generated client class name",
+      "type": "string"
+    },
+    "example": {
+      "additionalProperties": false,
+      "description": "An illustrative call — not a file to write",
+      "properties": {
+        "content": {
+          "type": "string"
+        },
+        "language": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "language",
+        "content"
+      ],
+      "type": "object"
+    },
+    "generateCommand": {
+      "description": "Run against the RUNNING service to emit the real typed client",
+      "type": "string"
+    },
+    "output": {
+      "description": "Where that command writes the client",
+      "type": "string"
+    },
+    "service": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "service",
+    "client",
+    "generateCommand",
+    "output",
+    "example"
+  ],
+  "type": "object"
+}
    • Changedscaffold_service1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "cliAlternative": {
+      "description": "The CLI command that creates a full provider-wired project instead",
+      "type": "string"
+    },
+    "files": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "content": {
+            "type": "string"
+          },
+          "language": {
+            "type": "string"
+          },
+          "path": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "path",
+          "language",
+          "content"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "install": {
+      "type": "string"
+    },
+    "service": {
+      "description": "Class name used, after normalisation ('user' -> 'UserService')",
+      "type": "string"
+    }
+  },
+  "required": [
+    "service",
+    "install",
+    "files",
+    "cliAlternative"
+  ],
+  "type": "object"
+}
    • Changedsearch_docs1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "count": {
+      "description": "Number of results returned (0 means no matches)",
+      "type": "integer"
+    },
+    "query": {
+      "description": "The query that was searched",
+      "type": "string"
+    },
+    "results": {
+      "description": "Most relevant first",
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "description": {
+            "type": "string"
+          },
+          "section": {
+            "description": "Where it sits in the docs, e.g. 'Guides' or 'API · @imqueue/core property'",
+            "type": "string"
+          },
+          "symbol": {
+            "description": "True for a generated API-reference page rather than prose",
+            "type": "boolean"
+          },
+          "title": {
+            "type": "string"
+          },
+          "url": {
+            "description": "Pass this to get_doc to read the page in full",
+            "type": "string"
+          }
+        },
+        "required": [
+          "title",
+          "section",
+          "description",
+          "url"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "query",
+    "count",
+    "results"
+  ],
+  "type": "object"
+}
  8. 6 tool updates
    • First observedget_doc
    • First observedlist_packages
    • First observedlocal_install_guide
    • First observedscaffold_client
    • First observedscaffold_service
    • First observedsearch_docs

Related MCP Connectors

Related MCP Servers

Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources