glimind

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

Adds real context beyond the readOnlyHint/openWorldHint annotations: it discloses that the live check performs exactly one handshake plus tools/list and calls no tools, which bounds side effects and latency. It also enumerates what the audit inspects (uptime, breaking changes, tool-list token cost), though it says nothing about rate limits, cost, or failure modes for unreachable URLs.

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

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

Front-loaded with the WHEN TO CALL trigger, then a dense but purposeful specification sentence. Slightly long-tailed in its audit-dimension list, but every clause carries information an agent needs to select and call it.

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

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

Complete for a two-optional-parameter, read-only tool: triggers, inputs, live-vs-cached behaviour, and the shape of the output (0-100 plus prioritised fixes) are all covered without an output schema. Minor gap on error behaviour for bad serverId/url and on result turnaround.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns an extra point by clarifying that serverId and url are alternatives ('Pass serverId ... or url') and by explaining the live-check semantics of url that the schema itself only hints at.

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

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

States a specific verb and resource (audit an MCP server/repo/package/endpoint) and pins the deliverable: a 0-100 agent-readiness score plus prioritised fixes across named dimensions. The 'Lighthouse for MCP' framing plus the enumerated check list makes the tool's identity unmistakable.

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

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

'WHEN TO CALL' gives explicit trigger conditions (building, debugging, configuring, comparing, evaluating a server/repo/package/URL). It does not, however, name or exclude any sibling — verify_tools, scan_tools, preflight_tools and check_tool_reliability all sit adjacent, and the description offers no guidance on when this audit beats those.

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

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

Goes well beyond the readOnlyHint/openWorldHint annotations by disclosing the verdict vocabulary (healthy | degraded | down | unknown), the metrics returned, and that pricing/payment info is included. This is exactly the kind of contextual detail annotations don't carry.

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

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

Dense but front-loaded with the WHEN TO CALL trigger before the return-value inventory, so an agent sees the usage condition first. The single long sentence is packed but every clause carries information; slight trimming of the return list could improve it.

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

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

With no output schema, the description fully compensates by enumerating the returned fields (verdict, success rate, p50/p95, error signatures, breakage, endpoint, pricing), and the single input's accepted formats are covered in the schema and reinforced in prose.

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

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

Schema coverage is already 100%, but the description adds real meaning: the exact Glimind id is not required and the response reports what the input resolved to. That resolution behavior is not captured by the schema alone, justifying above the baseline 3.

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

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

States a specific verb (check reliability) plus resource (an MCP tool/server), and enumerates exactly what it returns: verdict, success rate, latency, error signatures, breakage, endpoint, pricing. An agent can distinguish it from siblings like verify_tools or audit_server because the description frames it as a live reliability lookup rather than a test or audit.

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

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

Explicitly states when to call: before invoking an unfamiliar/external tool and after any failure, timeout, or 4xx/5xx, with the reason (is it down for everyone or local). It does not name sibling alternatives such as preflight_tools or verify_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.

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

Annotations already declare readOnlyHint=true, so the safety profile is covered; the description adds non-obvious behavioral context by specifying that results are live (not cached) and ranked by fit, and what metadata each result carries. It does not cover edge behavior such as zero-match responses or ranking criteria, keeping it short of a 5.

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

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

A single front-loaded sentence keyed to 'WHEN TO CALL', with no filler. It is slightly dense and run-on by the end (three clauses about return shape), but every clause carries information.

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

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

With no output schema, the description correctly spends its words on the return shape (ranked tools, input schema, connection endpoint, free/paid status) so an agent knows it can act on results immediately. Gaps are minor: nothing about no-match handling or how ranking is determined.

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

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

Schema coverage is 100%, so query, limit and category are already documented, including defaults and max. The description's query examples duplicate the schema's own example ('send an email' vs 'send a slack message') and it says nothing about limit or category, so it adds little beyond the schema.

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

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

States a specific verb ('discover') and resource (tools) plus the exact input form (plain-language query) and output form (ranked tools with schema, endpoint, pricing). It explicitly distinguishes itself from route_task's single pick, so an agent can separate it from the closest sibling without reading either schema.

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

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

Opens with an explicit WHEN TO CALL condition ('you need a capability and don't know which tool provides it') and names the alternative (route_task) with the deciding criterion: several options vs a single pick. No inference required.

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

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

Annotations only declare readOnlyHint and openWorldHint, so the description carries the real burden and does add value: results are live, ranked by similarity plus real traffic, and include a connection endpoint for immediate use. It does not say what happens on no match, how ranking is weighed, or whether results are cached, which matters for a fallback tool consulted under failure.

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

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

Two sentences, front-loaded with a WHEN TO CALL prefix, then the return shape. No filler and no repetition of the tool name.

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

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

With no output schema, the description usefully covers return contents (ranked live tools plus endpoints) and the input flexibility. Gaps remain around empty-result behavior and whether the endpoint is directly callable, which an agent using this as a recovery path would want.

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

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

Schema coverage is 100% and toolId's schema description is actually richer than the prose (it adds URL and exact id forms). The description's 'server or tool name, package or repo' is a partial restatement, and the optional task tag goes unmentioned entirely. Baseline 3 is appropriate when the schema does the work.

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

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

States a specific verb and resource with scope: returns live substitute tools ranked by similarity and real traffic, each with its connection endpoint. An agent understands the output without opening a schema. However, it never distinguishes itself from the close sibling find_related_tools, which from the name alone could be read as doing the same job.

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

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

The trigger is explicit and concrete: a tool is down, rate-limited, failing or missing. That is a clear context for selection. It stops short of naming alternatives (find_related_tools, discover_tools, verify_tools) or saying when this is the wrong choice, so the agent must infer routing between near-duplicate siblings.

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

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

The annotations already establish read-only and closed-world behavior, and the description adds useful context by saying the relationships come from real agent usage. However, it does not disclose return format, freshness, limitations, or ranking behavior, so the added behavioral detail is moderate.

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

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

Two tight sentences with the core purpose front-loaded, followed by concrete usage scenarios. There is no filler or repetition.

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

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

For a simple one-parameter read-only discovery tool, the description explains the value and intended use adequately. It lacks explicit return-value details, but with no output schema this is a minor gap rather than a blocking omission.

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

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

Schema coverage is 100%, so the toolId parameter and its accepted formats are already documented in the schema. The description only implies that a given tool must be supplied and does not add syntax or example details beyond the schema.

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

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

The description gives a specific verb and resource: discover tools commonly used together with a given tool, based on real usage. It distinguishes itself from a generic discovery tool through the 'used together' relationship, though it does not explicitly name siblings like find_alternatives or discover_tools.

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

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

It clearly states when to call it: to find complementary tools likely needed next, or to discover better-fitting tools. It does not provide when-not guidance or explicitly compare itself to sibling tools, so it stops short of the top score.

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

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

Annotations only cover safety (readOnlyHint=true, openWorldHint=false); the description adds genuinely useful behavior beyond them: this is a stateful cursor poll ('events since your last poll, then the cursor advances') and requires no public endpoint. It does not mention rate limits or what happens when no new events exist.

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

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

Two dense sentences with the core behavior (cursor advance) front-loaded and the usage condition second. 'no public endpoint required' is mildly redundant with the webhook framing, keeping it just under maximum.

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

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

With no output schema, the description compensates by naming the returned fields (tool id, severity, link) and disclosing the cursor-advance side effect. Coverage is solid, though it omits what an empty poll returns and whether the cursor is per-token or global.

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

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

Schema coverage is 100%, so both the token and limit parameters are already documented in the schema, making 3 the baseline. The description reinforces the token's polling semantics but adds no format or edge-case detail for limit beyond the schema's default of 50.

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

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

States a specific verb (fetch) and resource (new reliability alerts) scoped to a subscription token, and names the sibling watch_tool as the setup step. An agent can tell this apart from siblings like watch_tool/unwatch without opening a schema.

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

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

Gives an explicit trigger: 'Use this after watch_tool without a webhook to react to outages/recoveries.' That names both the precondition and the alternative mechanism (webhook), though it does not mention unwatch as the teardown counterpart or state what happens if polled before watching.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description goes beyond them: results are privacy-preserving value-free skeletons, ranked by recent success, accompanied by observed success rate and latency, and explicitly 'currently-working' (i.e., time-sensitive). It does not say what comes back when no recipe is known or how many recipes are returned, which is the notable remaining gap given there is no output schema.

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

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

Front-loaded with the core purpose, then purpose-adjacent detail, then return characteristics — a sensible ordering with no filler. Slightly long for two parameters, and 'privacy-preserving — never real argument values' is a mild restatement, but each sentence still carries information.

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

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

With no output schema, the description does the heavy lifting on returns (shape skeletons, success rate, latency, recency ranking) and covers the optional filter. Missing only edge-case behavior — no-recipe-found responses and result cardinality — which keeps it short of a 5 for a tool whose whole value is its returned data.

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

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

Schema coverage is 100%, so both parameters are already documented, and the description's 'optionally filter by a coarse task tag' largely restates the schema's task field. The only added meaning is that `toolId` tolerates loose identifiers and that returned shapes carry no real values — useful but marginal, so the baseline 3 applies.

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

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

States a specific verb and resource ('Get a CURRENTLY-WORKING call pattern (input shape) for a tool') and immediately qualifies what the artifact is: distilled from real successful calls, value-free skeletons, ranked by recent success. An agent can tell this apart from generic tool-discovery 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.

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

Gives two concrete triggering conditions: 'when you are unsure how to shape a tool's inputs' and 'right after a tool call failed and you want a structure known to succeed now.' That is clear usage context, but it never names the obvious alternative (prepare_tool_call) or states a when-not condition, so it stops short of full alternative routing.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real value by stating what is returned (guide, pricing model, memoryBlock) and implies a follow-up action — persisting the memoryBlock into CLAUDE.md/AGENTS.md/.cursorrules. It doesn't describe the size or format of the guide, so not a 5.

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

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

A single front-loaded sentence that leads with the WHEN TO CALL trigger and then lists the return contents. Every clause carries information; nothing is redundant.

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

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

With no input parameters and no output schema, the description carries the burden of explaining what comes back — and it does, naming all three return components. It could go slightly further by noting that the guide is static reference material versus live tool data, but it's sufficient for correct invocation.

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

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

The tool takes zero parameters, so the baseline is 4 per the rubric. There is nothing for the description to disambiguate, and it doesn't waste space on phantom parameters.

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

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

The description uses a specific verb (returns) and names the concrete artifacts returned: the full tool guide, the free-vs-paid model, and a memoryBlock snippet. This distinguishes it from sibling tools like discover_tools or route_task. It falls short of 5 only because it doesn't explicitly contrast itself with those siblings by name.

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

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

The 'WHEN TO CALL: once per project, or when unsure...' phrasing gives clear triggering conditions, including a frequency cap. It doesn't state when NOT to call it or name a specific alternative for the 'I already know what I need' case, which keeps it below 5.

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

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

Annotations already establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations: sorting order, real-usage outcome data source, and timeliness relative to status pages. It still does not explain return fields or any rate limits.

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

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

Three efficiently packed sentences: purpose and ordering first, then usage guidance, then data-source credibility. Every sentence adds useful information without repetition or filler.

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

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

For a simple read-only list tool with one optional parameter, annotations covering safety, and no output schema, the description is complete enough. It clearly conveys what is listed, how results are ordered, when to use it, and the data basis behind it.

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

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

Schema description coverage is 100% for the single optional limit parameter, which documents the default of 25. The description adds no additional meaning about the limit parameter or filtering beyond what the schema already provides.

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

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

States a specific verb and resource: list tools whose real-world success rate dropped sharply, with active outages/regressions and a newest-and-most-severe ordering. This is distinct from siblings like check_tool_reliability or discover_tools because it focuses on breakages rather than general discovery or per-tool checks.

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

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

Explicitly says when to call it: to steer away from currently broken tools, or to monitor health of tools a task depends on. It does not provide when-not guidance or name alternative sibling tools for those cases.

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

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

Annotations already establish that this is a read-only, non-open-world operation. The description adds useful behavioral context by explaining that it returns a compact verdict and recommendation with proceed, proceed_with_caution, or avoid outcomes, though it does not detail edge cases such as unknown tool names.

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

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

Two tightly written sentences with the batch pre-flight purpose front-loaded and the usage timing immediately after. There is no redundant or filler language.

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

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

Given one simple parameter, read-only annotations, and no output schema, the description provides enough: what to pass, when to call it, and what kind of verdict to expect. Nothing essential for correct invocation appears to be missing.

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

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

Schema coverage is 100%, so the single toolIds parameter and its up-to-50 limit are already documented in the schema. The description reinforces that the parameter should include every tool the agent might use, but does not add format or validation details beyond the schema baseline.

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

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

States a specific verb and resource: pre-flight a whole task by passing multiple tools in one call. It clearly distinguishes this batch pre-flight action from checking tools one at a time, which differentiates it from sibling reliability/verification tools.

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

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

Explicitly says to call it once at the beginning of a multi-tool task instead of checking tools individually. This gives clear timing and alternative behavior, leaving little ambiguity about when to use it.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered; the description adds that one round-trip yields verdict, recipe and fallbacks, which is genuine context. Minor tension: 'live verdict' implies external live state while openWorldHint=false suggests a closed catalog, and nothing is said about latency, caching, or what 'recipe' and 'verdict' actually contain. Not a contradiction, but not rich either.

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

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

Three sentences, no filler, with the trigger condition first and the payload description second. Every sentence adds a distinct fact: when to call, what comes back, and what input forms are accepted.

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

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

With no output schema, the description still sketches the return payload (verdict, recommendation, recipe, alternatives) and the forgiving input matching, which is enough to call correctly. A little more on the shape or size of the recipe/alternatives payload would close the remaining gap.

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

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

Schema coverage is 100% and the schema already enumerates the accepted forms of toolId (short name, package, repo slug, URL, exact id) and the task tag's purpose. The description's only addition, 'the exact id is not required', largely restates that, so the schema is doing the work and baseline 3 applies.

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

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

The description states concretely what a call returns – a live verdict, a recommendation, a known-good input recipe, and live alternatives – so an agent knows this is a composite preflight check rather than a plain lookup. It does not distinguish itself from close siblings such as preflight_tools, check_tool_reliability, get_working_recipe or find_alternatives, even though it appears to aggregate their outputs.

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

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

The WHEN TO CALL clause is explicit and front-loaded: right before invoking an external MCP tool, or right after a schema/validation error from one. That is a clear triggering context, though it gives no exclusions (e.g., when a cheaper sibling like get_working_recipe suffices) and names no alternative.

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

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

Annotations already mark this as a non-destructive write, but the description goes further: it discloses the global side effect (updating shared reliability scores for everyone), that the call is free and keyless, and a privacy contract (never send inputs, outputs, or prompts). It stops short of saying what happens to duplicate or malformed reports, so not quite a 5.

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

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

Trigger condition is front-loaded in a labeled clause, then payload, then effect, then the caveat about auto-reporting. Four sentences, each carrying distinct information, no filler.

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

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

Five simple flat parameters, full schema coverage, no output schema required, and the description still covers the trigger, the payload, the side effect, and the privacy boundary. An agent has everything needed to call it correctly and knows when not to.

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

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

Schema coverage is 100%, so every parameter including the enumerated error classes is already documented in structured fields. The description only restates the send list and flags errorClass as failure-only, adding marginal meaning beyond the schema — baseline 3 applies.

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

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

Names a concrete verb (report) and resource (outcome of an external MCP tool call Glimind routed/checked) plus the effect: Glimind updates live reliability scores. That clearly separates it from read-only siblings like check_tool_reliability, list_breakages, and audit_server.

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

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

Opens with an explicit WHEN TO CALL trigger — after a routed/checked call succeeds or fails — and adds a real exclusion: the SDK's execute() already reports automatically, so agents shouldn't double-report there. Alternatives and the condition for skipping are both stated.

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

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

Annotations already say readOnly (consistent — routing does not mutate anything), and the description adds substantial context the annotations do not: it enumerates the full response payload (endpoint, input schema with example args, call hints, reliability verdict, price and payment method, ranked fallbacks) and explains that freeOnly/requireAutomatable/maxPricePerCall narrow the candidate set. It could go one step further on latency/caching behavior, but it already carries far more than its annotations.

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

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

Front-loaded with the trigger conditions and then a compact payload description; both sentences earn their place. It is dense and slightly long for one paragraph, but there is no filler and the WHEN TO CALL / what-you-get / narrowing / supersedes order is logical.

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

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

For a tool with no output schema, the description must explain the return shape — and it does, itemizing every field of the routed result including fallbacks and pricing. Combined with the trigger conditions and parameter narrowing notes, an agent has everything needed to call and interpret it correctly.

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

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 value by grouping the constraint parameters into a single clause ('freeOnly / requireAutomatable / maxPricePerCall narrow the choice') and by tying requireAutomatable to the unattended-agent use case. It gives the agent a mental model of how 'task' vs. the filter parameters interact, which the schema alone does not.

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

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

States a concrete action — resolve a plain-language task to a single best live tool with endpoint, schema, and fallbacks — which is clearly distinct from siblings like discover_tools or prepare_tool_call. It even names the four sibling tools it supersedes, so an agent can route unambiguously.

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

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

Opens with an explicit 'WHEN TO CALL: first' plus three enumerated trigger conditions (missing capability, failing connected tool, user asking which tool to use). This is the strongest possible form of when-to-use guidance and leaves nothing to inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, yet the description still adds real value: it discloses the response payload shape and that output is 'compact by default' with a full variant available. It stops short of disclosing cost/latency of the lookup itself or how results degrade when no tool matches a sub-task.

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

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

The core action and scope are front-loaded in the first clause, and the second sentence is a single short usage sentence. The parenthetical output list is slightly dense but every element carries information an agent would otherwise have to discover by calling.

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

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

With seven parameters, no output schema, and only read-only annotations, the description is complete enough: it names the input concept, the batch constraint context, the default view, and the per-task result fields. Gaps are minor — nothing on ordering of results relative to input tasks or on behavior when a sub-task yields no match.

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

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

Schema description coverage is 100%, so all seven parameters are already documented in the schema, and the description only echoes two of them ('compact by default', free/paid/fallbacks in the result list). It adds no insight into interactions such as how category narrows all tasks or how maxPricePerCall composes with freeOnly, so the baseline 3 applies.

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

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

The description states a specific verb (batch route) and resource (plain-language sub-tasks resolved to live tools) and explicitly contrasts with the singular route_task sibling via the 'Batch route_task' framing and the 'in one call' batching scope. It also enumerates what each result contains (endpoint, input schema, example args, free/paid, fallbacks), so an agent knows exactly what it gets back.

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

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

'Use it to plan a multi-step task' gives a clear positive trigger, and the batching framing implies the alternative is the single-task route_task. However, it never explicitly says 'for a single task use route_task instead' or states exclusions such as the max-10 limit being a reason to split work, so the boundary with the sibling is implied rather than stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered structurally. The description adds genuinely new context beyond that: what the scan reports (token cost, manifest hash) and a privacy guarantee that nothing sent is stored. It stops short of describing the finding format or output volume.

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

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

Three sentences, each earning its place: purpose and scope first, then invocation cadence, then the privacy reassurance. No filler, no repetition of the name or schema, and the most important information is front-loaded.

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

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

With no output schema and a single fully-documented parameter, the description carries the remaining burden well: it states what is scanned for, what information accompanies the results, when to call it, and that inputs are not persisted. An agent has everything needed to invoke it correctly.

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

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

Only one parameter exists and the schema already documents it at 100% coverage ('Tool definitions as tools/list returned them'). The description's phrase 'loaded in your session' adds session context but no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

The description names a specific verb (scan) and a specific resource (the tool definitions loaded in your session), then enumerates what it looks for: tool poisoning via hidden instructions, concealment, secret access, shadowing, plus quality problems, token cost, and manifest hash. It is far more concrete than a tautology, but it does not explicitly differentiate itself from the many similarly-named siblings (audit_server, verify_tools, check_tool_reliability).

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

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

Gives explicit invocation timing: 'Call once per session or when a server's tools change.' This is actionable frequency guidance rather than vague context. It does not, however, name an alternative sibling or state when a different tool would be the better choice.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: the retrieval mechanism ('hybrid semantic + keyword retrieval with operation-aware reranking') and a privacy guarantee ('Nothing you send is stored'). Those are behaviors an agent could not infer from annotations or schema.

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

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

Three sentences, no filler, and the core purpose is front-loaded before mechanism and privacy details. Every sentence adds distinct information (what it does, how to call it, how it works, data handling).

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

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

With no output schema, the description correctly explains what comes back (a ranked minimal set plus token savings). Input source, retrieval method, and privacy posture are all covered. Minor gaps remain around ranking/tie behavior and error cases, but nothing essential to a correct invocation is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description earns above baseline by clarifying the provenance of the otherwise opaque 'tools' array ('from tools/list across your servers') and by describing the return shape ('minimal set ranked by fit, with the tokens saved'), which the schema does not convey.

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

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

States a specific verb and resource ('Pick which of YOUR connected tools a task needs') plus the outcome ('load a handful of definitions instead of all of them'). An agent immediately understands the job. It does not, however, differentiate itself from near-siblings like discover_tools, route_task, or route_tasks, which appear to overlap in scope.

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

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

Gives a clear trigger condition (loading a subset of definitions rather than all) and explains the input flow ('pass the task and the tool definitions you have from tools/list'). But with route_task, route_tasks, discover_tools and preflight_tools in the sibling set, the absence of any explicit when-to-use-this-vs-that guidance leaves the agent guessing.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the mutation profile is covered structurally. The description adds only that the token identifies a subscription created by watch_tool; it does not say what is destroyed (pending notifications), whether an already-cancelled token errors, or what a success response looks like. With annotation coverage this is a modest but positive addition.

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

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

A single front-loaded sentence with zero filler; the action, the object, and the token requirement all land in one pass.

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

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

For a one-parameter teardown tool with a full annotation safety profile and no output schema, the description covers what an agent needs to select and call it. It could note the effect of a stale token or the expected confirmation, but nothing essential is missing.

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

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

One parameter with 100% schema description coverage, so the schema already explains 'token' as the subscription token. The description merely restates that the token belongs to a watch_tool subscription, adding no format or sourcing detail beyond structured data. Baseline 3 applies.

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

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

States a specific verb (cancel) plus the resource (a subscription) and explicitly ties it to the sibling that creates it (watch_tool). An agent can distinguish this from watch_tool and the other 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.

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

The phrase 'a subscription created by watch_tool' identifies the precondition for use and the counterpart tool, so the when-to-use case is clear. It stops short of stating when not to use it (e.g., token unknown/expired) or naming alternatives, so it is not fully explicit.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds rich behavioral context beyond that — it explains the three possible outcomes (match, earlier version, never recorded), mentions a diff, a tool-poisoning scan, and a Merkle inclusion proof. This is valuable operational detail not covered by annotations.

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

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

Two sentences, front-loaded with the core action. The second sentence efficiently lists return details and usage guidance. Slightly dense but no wasted words.

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

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

Given the tool's complexity and that no output schema exists, the description adequately explains what is returned (match status, diff, poisoning scan, Merkle proof) and when to use it. It covers the necessary context for an agent to invoke and interpret results.

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

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

Schema description coverage is 100%, so parameters are already documented in the schema. The description doesn't add parameter-level detail, but it clarifies the conceptual input (tools received from an MCP server) and the optional serverId hint context. Given high coverage, baseline is 3; the description's framing adds modest value.

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

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

States a specific verb and resource: check client-received tool definitions against Glimind's signed transparency log. It clearly distinguishes itself from siblings like scan_tools or audit_server by focusing on verifying a specific received tool list against recorded history.

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

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

Explicitly states when to use it: 'before trusting a server's tools, especially after they change.' This gives a clear trigger condition and contrasts with other verification siblings implicitly.

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

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

Annotations already declare idempotentHint=true, destructiveHint=false, and readOnlyHint=false; the description adds the meaningful stateful behavior — push webhook vs pull token modes, webhook auto-detection (generic/Slack/Discord), and that it returns a token to manage/poll. It doesn't cover subscription lifetime or cleanup, but adds real context beyond the annotations.

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

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

Front-loaded with the core action and scoping, then the push/pull distinction, then the trigger. Dense but every sentence carries information; slightly long with some redundancy between 'Subscribe' and 'Call this to be told...'.

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

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

With no output schema, the description usefully explains that a token is returned for managing/polling the subscription, and covers both delivery modes. It leaves subscription lifecycle details (expiry, cleanup) unstated, but the essentials for correct invocation are present.

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

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 genuine meaning: it explains the webhook parameter's auto-detection behavior and the semantic split (webhook present = push, omitted = pull token), which the schema only hints at. minSeverity and allCritical are left to the schema.

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

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

States a specific verb (subscribe) and resource (reliability alerts for tools, or all critical outages), clearly differentiating it from siblings like unwatch and get_notifications. An agent can tell immediately this is the subscription-creation tool.

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

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

Gives a clear trigger ('Call this to be told the moment a tool you depend on breaks or recovers') and names the pull alternative (get_notifications) plus the condition that selects it (omit webhook). It does not explicitly say when NOT to use it versus unwatch, so it falls short of a full 5.

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