glimind

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

With no annotations, description carries full burden. It discloses return values (verdict, success rate, latency), indicates it is 'cheap and fast' and 'safe to call routinely', implying no destructive side effects. However, it does not specify authentication requirements or error handling for missing tool IDs.

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 key instruction, all sentences are informative and earn their place. Slightly long but no fluff. Could be slightly more concise but still effective.

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 simplicity (1 param, no output schema), the description covers purpose, usage timing, return values, and behavioral safety. It also mentions endpoint and pricing info, making it complete for agent decision-making.

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 with schema description coverage 100%. The description adds context by explaining the parameter format with examples (server id or 'server/tool_name'), exceeding the schema's basic description.

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?

Clearly states the verb 'check' and resource 'tool reliability', with explicit purpose 'Call this BEFORE invoking any external MCP tool or API to check if it is working RIGHT NOW.' Distinguishes from sibling tools like discover_tools and preflight_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 states when to use: 'before invoking any external MCP tool or API'. Provides decision guidance: 'use it to decide whether to call a tool, choose a fallback, or tune timeouts and retries'. Also mentions that it prevents wasted calls.

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?

Describes return fields (tool ids, input schema, endpoint, pricing) and filtering criteria (live, semantically similar). Discloses the on-demand discovery style. No annotations provided, so description carries full burden; lacks explicit statement of idempotence or rate limits but sufficient given the tool's nature.

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?

Single paragraph packs substantial information without redundancy. Could be broken into shorter sentences for readability, but every sentence earns its place. Appropriate length for complexity.

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?

Despite no output schema, the description comprehensively explains what is returned (tool ids, schema, endpoint, pricing) and the ranking/filtering logic. Also situates the tool in the workflow (discovery entry point). No gaps identified.

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 baseline is 3. The description adds context on how the query is used (plain-language, semantic similarity) and default/max limits, enhancing understanding 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?

Clearly states the verb (find/discover), resource (LIVE tools), and scope (by plain-language task description). Explicitly distinguishes from siblings find_alternatives/find_related_tools that require a tool ID, leaving no ambiguity about what the tool does.

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 instructs 'call this when you do NOT yet know which tool to use' and contrasts with alternatives that need a known tool ID. Provides clear context for when this tool is appropriate.

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?

No annotations provided, so description carries full burden. It discloses search based on capability similarity and real traffic, returns live endpoints. No contradictions, but could mention if any side effects or permissions needed.

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 purpose and actionable guidance. No fluff, every word contributes.

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 no output schema, description adequately explains return format (tool ids with endpoints) and ranking criteria. Covers all necessary context for the find operation.

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 baseline is 3. Description adds minimal new meaning beyond schema: restates that toolId is the given tool and task is optional coarse tag. Does not enhance understanding.

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?

Description explicitly states the tool finds LIVE tools similar to a given tool, with specific use cases (when tool is down, rate-limited, missing). It distinguishes from siblings like find_related_tools by emphasizing real working substitutes and endpoints.

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?

Clearly specifies when to call (tool down, rate-limited, missing) and what it returns (ready-to-use ids with endpoints). Lacks explicit when-not or alternatives, but context is sufficient.

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?

With no annotations, the description carries full burden. It discloses that results are based on 'real usage' data, indicating a data-driven approach. However, it omits details like whether results are deterministic, how data is aggregated, or any security/reliability implications.

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 description is two sentences: first states purpose and data source, second gives use cases. No wasted words, information is front-loaded and easy to parse.

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 tool with one required param and no output schema, the description covers the core purpose, data source, and use scenarios. It could mention the output format (e.g., list of tool names) but is not incomplete given the lack of output schema.

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 only parameter, toolId, is described as 'The tool to find companions for.' Schema coverage is 100%, so baseline is 3. The description adds no extra meaning beyond the schema, which is adequate but not enhanced.

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 clearly states the tool discovers tools commonly used together with a given tool, based on real usage. It distinguishes itself from siblings like 'discover_tools' (broader) and 'find_alternatives' (replacements) by focusing on complementary co-use.

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 description provides explicit use cases: finding complementary tools for a task or discovering better-fitting tools. While it doesn't explicitly state when not to use it, the context is clear and aligns with the tool's purpose.

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?

No annotations, so description carries full burden. Discloses cursor advancement on each poll, return fields (tool id, severity, link), and implies read-only fetching. Does not discuss rate limits or error handling, but sufficient for understanding core behavior.

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 concise sentences: first defines core action and cursor, second gives usage context, third describes return. Every sentence essential, no redundancy, front-loaded with main action.

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, description explains return fields. For a simple poll tool, it provides sufficient context: how to use, what happens on each call (cursor advances), and integration with watch_tool. Could mention token expiration but still complete for basic usage.

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%, but description adds context that token acts as a cursor from watch_tool, and explains polling behavior. This supplements the schema descriptions, adding value beyond parameter names.

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?

Description clearly states it fetches new reliability alerts for a subscription token, specifies cursor behavior, and differentiates from sibling watch_tool by stating 'Use this after watch_tool without a webhook'.

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 use after watch_tool without a webhook for reacting to outages/recoveries. Implies alternative use of webhooks with watch_tool but does not explicitly state when not to use. Provides clear context for usage.

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?

Discloses privacy-preserving nature (value-free skeletons, never real values), ranking by recent success, and inclusion of success rate and latency. No annotations provided, so description carries full burden and does well.

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?

Concise single paragraph of 4 sentences, front-loading purpose and usage, with no redundant 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 thoroughly explains what is returned (shape skeletons, privacy, ranking, success rate, latency). Adequate for the tool's low complexity.

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 baseline 3. Description reinforces the purpose of each parameter but adds minimal new detail beyond the schema's descriptions.

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?

Description clearly states the tool retrieves a currently-working call pattern for a tool, distilled from real successful calls. This distinguishes it from siblings like discover_tools or 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?

Explicitly advises to use when unsure how to shape inputs or after a tool call failed, with optional filtering. Lacks explicit when-not-to-use cases, but guidance is clear.

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?

No annotations provided, so the description carries full burden. It explains the tool returns a memoryBlock containing the usage guide, is non-destructive, and should be saved. This is transparent about behavior, though it could explicitly state no side effects.

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 description is fairly concise given the amount of context it conveys. It front-loads the key instruction and then expands. While slightly long, every sentence serves a purpose.

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 zero parameters and no output schema, the description fully explains what the tool does (returns a guide), what to do with the result (save to project memory), and its relation to other tools (consult Glimind first, use route_task). Complete for its context.

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?

No parameters exist (0 params, 100% schema coverage). Baseline is 4. The description adds value by explaining what the returned content covers, going beyond the empty 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 clearly states the tool's purpose: to teach how to use Glimind fully and optimally. It specifies the action (read once, save the returned memory block) and distinguishes it from siblings like route_task or discover_tools by focusing on onboarding and system understanding.

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 description provides clear when-to-use guidance: call at session start or when unsure how to get external data. It implies it's a one-time setup tool, but does not explicitly exclude re-use or list alternatives. Still, the context is strong.

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?

No annotations provided, so description carries full burden. Discloses it's backed by real-usage outcome data and catches breakages before status pages, implying near-real-time read-only listing. No destructive implications, no contradictions.

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 with no waste. First sentence states core purpose and ordering; second adds usage guidance and data-source credibility. Front-loaded and efficient.

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 list tool with one optional parameter, no output schema, and no annotations, the description provides purpose, ordering, data source, and usage guidance. Lacks return format but acceptable given specification.

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% (single limit parameter with description 'Max results (default 25).'). The description adds no extra parameter-level detail beyond the schema, meeting the baseline expectation for high coverage.

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?

Clearly states the tool lists tools with dropped success rates due to outages/regressions, newest and most severe first. This specific verb+resource distinguishes it from siblings like check_tool_reliability (targets single tool) and discover_tools (general discovery).

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 call this to steer away from broken tools or monitor health of dependencies. Provides clear context but no explicit exclusions (e.g., when to use check_tool_reliability instead), though sibling names imply alternatives.

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?

With no annotations, the description carries the burden. It states the verdict output (proceed, proceed_with_caution, avoid) but does not disclose side effects, authentication needs, or error handling. It implies read-only behavior but lacks full transparency for a safety-conscious agent.

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 description is concise and front-loaded with the purpose. It uses efficient language but could be slightly more structured, e.g., explicitly listing the verdict options. Still, it earns its place without fluff.

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 a simple single-parameter tool with no output schema, the description fully covers what the tool does, what it returns, and when to use it. It is complete for the tool's complexity.

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% with a single parameter 'toolIds' described as 'Tool identifiers you plan to use (up to 50).' The description adds context about passing every tool but does not significantly enhance understanding 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 clearly states the tool's purpose: 'Pre-flight a WHOLE task in one call' to get a compact verdict and recommendation for each tool. It distinguishes from checking tools one at a time, likely referencing sibling tools like 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?

The description explicitly says to call this once at the beginning of a multi-tool task instead of checking tools individually. It provides clear context but does not explicitly list when not to use it or name alternatives, though the context implies the alternative is checking one by one.

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?

Discloses that it returns a health verdict, recipe, and live alternatives, and indicates whether the tool is down or risky. No annotations are present, so the description adequately covers the behavioral aspects for a non-destructive meta-tool.

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 concise, front-loaded sentences with no wasted words. Each sentence serves a distinct purpose: what it does, how it combines calls, and what information it provides.

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 no output schema, the description adequately explains the return values (verdict, recipe, alternatives). However, it lacks details on how alternatives are identified or what 'coarse task tag' entails fully.

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%, but the description adds value by explaining that 'task' tailors the recipe/alternatives, going beyond the schema's basic description.

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 clearly states the tool is a preparatory step before using another tool, returning health status, recipe, and alternatives. It uses specific verbs ('prepare', 'returns') and distinguishes it from similar sibling tools by consolidating multiple calls.

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 'Make right before using a tool' and 'Use this instead of calling check + recipe + alternatives separately', providing clear when-to-use instructions and naming alternatives.

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?

With no annotations provided, the description carries full burden. It discloses that the tool is free, keyless, privacy-preserving, and that it helps Glimind learn. It specifies exactly what data to send and what to avoid. It does not mention potential side effects like rate limiting or state modifications, but for a lightweight feedback tool, this is adequate.

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 description is a single paragraph of about 6 sentences, front-loaded with the core purpose. It covers key details without excessive verbosity. While it could be slightly tighter, it is well-structured and efficient for an AI agent to parse.

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 simplicity and the full schema coverage, the description is complete enough. It explains the purpose, usage pattern, privacy considerations, and integration with other tools. There is no output schema, but for a reporting tool the return value is likely minimal (acknowledgment). The description adequately prepares an agent to use the tool.

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?

All parameters are described in the input schema (100% coverage), so the description does not need to repeat basic details. However, it adds value by reinforcing the expected format for toolId (from route_task's chosen.toolId) and explaining the errorClass normalization. This contextual information helps the agent use the parameters effectively.

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 clearly states the tool's purpose: to report the outcome of a tool call, specifically for tools routed by Glimind. It uses specific verbs ('report what happened') and resource ('outcome of tool call'), and distinguishes itself from sibling tools like 'route_task' and 'check_tool_reliability' by focusing on feedback.

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 description explicitly states when to use the tool ('after you call a tool... especially one Glimind routed you to' and 'Call it every time you use a routed tool'). It also provides guidance on what not to send (inputs, outputs, prompts). However, it does not explicitly mention when not to use it or list alternatives.

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?

No annotations are provided, so the description carries the full burden. It thoroughly discloses what the tool returns: verdict, reliability score, input schema, recipe, call hints, endpoint, pricing, fallback chain, bestFree, bestValue. It also explains output variations (full vs compact) and parameter behavior (freeOnly, requireAutomatable). This gives the agent a comprehensive understanding of the tool's behavior.

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 description is verbose and contains detailed information that could be condensed. It front-loads the main purpose but then lists many return fields in a single sentence. While no information is wasted, the length may exceed optimal conciseness. It adequately structures the information with key points emphasized.

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 (7 parameters, no output schema, many siblings), the description is fairly complete. It covers purpose, output fields, parameter usage, and comparisons to siblings. It lacks details on error handling, rate limits, or edge cases, but the core functionality is well-documented.

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 baseline is 3. The description adds value by explaining the purpose of parameters like freeOnly ('only consider FREE tools') and requireAutomatable ('only tools an agent can pay for autonomously'), which goes beyond the schema descriptions. It also clarifies that view can be 'full' or 'compact'. Thus, it provides meaningful context.

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 clearly states the tool's purpose: given a plain-language task, it returns the single best live tool to do it, with verdict, reliability, schema, recipe, call hints, endpoint, pricing, and fallback chain. It explicitly distinguishes itself from siblings by stating it replaces discover_tools, check_tool_reliability, prepare_tool_call, and find_alternatives.

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 description explicitly says when to use the tool: 'Call this at the start of a task when you don't already know which tool to use.' It provides context on alternatives and mentions parameters like freeOnly and requireAutomatable. However, it does not explicitly state when not to use it, only implying that it is the initial choice before other sibling tools.

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?

Describes what the result carries (endpoint, input schema, example args, free/paid, fallbacks) and mentions default compact format. No annotations are provided, so the description carries the full burden. No contradictions.

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?

Concise single paragraph with front-loaded purpose. Efficient use of words, no fluff.

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 no output schema, description adequately describes return content. Covers essential aspects for a routing tool used at planning stage. Could mention error handling but not critical.

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 baseline is 3. Description adds minimal extra semantics (e.g., 'compact by default' relates to view parameter). No elaboration beyond 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 clearly states it's a batch version of route_task, takes an array of sub-tasks, and returns tool info for each. It distinguishes from the sibling route_task (single task) and explains the benefit of collapsing N round-trips into one.

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 'Use this at the start of a multi-step task to plan every step at once', and contrasts with route_task for single tasks. Does not explicitly state when not to use, but the context is clear.

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?

No annotations provided, so description carries full burden. It mentions cancellation but lacks details on success/failure, side effects, or permissions. Minimal disclosure.

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?

Single sentence, 11 words. Extremely concise and efficient with 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?

For a simple one-parameter tool with no output schema, the description adequately covers what it does and how to use it. Could mention return value, but not essential.

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 parameter 'token' has a description. The description adds context that the token comes from watch_tool, which is helpful and goes beyond 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 clearly states the verb 'Cancel' and the resource 'subscription created by watch_tool'. It is specific and distinguishes from the sibling watch_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?

It states when to use (when you have a subscription token from watch_tool and want to cancel it). No explicit when-not or alternatives, but context is clear.

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?

No annotations provided, so description carries full burden. It explains push vs pull behavior, auto-detection of webhook type, and return of a token for pull mode. It does not detail side effects like subscription limits or potential overwrites, but the core behaviors are transparent.

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 description is concise at four sentences, each serving a distinct purpose: aim, modes, use case, and return value. No redundancy.

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 adequately covers the return (a token) and the two modes. It could mention error handling or subscription management details, but for a tool with 5 optional parameters, it is sufficiently complete.

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% with clear parameter descriptions. The description adds value by explaining the usage pattern for webhook (auto-detected) and token mode, and the relation to get_notifications, going 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 clearly states the tool subscribes to reliability alerts for tools or all critical outages. It distinguishes from siblings like get_notifications (poll) and unwatch (cancel), using specific verbs and resources.

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?

Describes two modes (push with webhook, pull with token) and when to call it (to be alerted on breakage/recovery). Implicitly contrasts with one-time check (check_tool_reliability) and polled notifications (get_notifications). Could explicitly mention alternatives, but context is clear.

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