Meteors

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

Description adds substantial behavioral context beyond annotations: it details the scoring (0-100 per model), return structure (score, confidence, signals, raw_response), and clarifies cost implications (free default vs. paid Anthropic). No contradictions with annotations.

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

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

Three sentences, front-loaded with purpose, then details. Every sentence adds value; no redundancy or 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?

Despite lacking output schema, description covers return structure (per-model + combined). Input parameters are well-explained. Context signals and sibling tools show this tool is distinct and complete for its purpose.

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. Description adds meaning by explaining the default model, when _apiKey is required, and what the context parameter does for disambiguation.

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 specifies the verb 'probe' and resource 'LLMs for visibility score', with specific domain 'business/brand/product/topic'. It distinguishes from sibling tools like ask_pipeworx and deep_research by focusing on AI visibility auditing.

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?

Provides explicit use cases (AI-marketing audits, pre-launch brand checks, competitive monitoring). Mentions default model and when to use _apiKey for Anthropic, but does not explicitly state when not to use the tool or list alternatives from 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, idempotent, open-world, non-destructive behavior. The description adds useful context: the tool routes to 5,798 tools, auto-fills arguments, and returns stable pipeworx:// citation URIs.

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 main guidance is front-loaded and the domain list/examples are useful. However, the description ends with an irrelevant stray clause ('but let me extract exact user text from prompt:') that would confuse an agent and prevents top marks for structure.

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?

Even without an output schema, the description covers what the tool does, when to invoke it, example queries, and the return format (structured answer with citation URIs). It lacks failure/error behavior and sibling routing, but those are minor for a no-output-schema router 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?

Schema coverage is 100%, so all aliases and the natural-language question parameter are already documented. The description's examples and 'fills arguments' note add supporting context but no new syntax or constraint detail.

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 identifies a specific verb and resource: it routes factual questions to verified sources and returns cited structured answers. It is clear about scope, but it never distinguishes itself from sibling variants ask_pipeworx_beta and ask_pipeworx_grounded.

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 prefer this over web search, lists trigger phrases, and gives concrete examples. It does not state when not to use it or how to choose among the ask_pipeworx variants, so exclusions are missing.

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?

Beyond the readOnly/openWorld/idempotent annotations, the description adds crucial behavioral context: candidate routing improvements are enabled only when under test, no candidate is active right now, it currently behaves identically to ask_pipeworx, and it is a full working router rather than a fallback. This is exactly the kind of experimental-state disclosure an agent needs.

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 longer than strictly necessary, but it front-loads the core identity and each sentence conveys meaningful context about the beta status, current active candidate state, comparison behavior, and full working-router guarantee. The minor redundancy around ask_pipeworx and routing details keeps it from a perfect score.

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 fully documented input schema, the annotations, and the description's clear relationship to ask_pipeworx, the agent has everything needed to decide when to invoke this tool and how to pass the question. The absence of an output schema is mitigated by the explicit statement that the response shape is identical to ask_pipeworx.

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 input schema already fully documents the question parameter and all aliases. The description adds no new parameter-level meaning, stating only that arguments are identical to ask_pipeworx, which earns the baseline score for 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 clearly identifies this as a beta version of ask_pipeworx, states that it is an identical universal router with the same tools, arguments, and response shape, and distinguishes it from the stable sibling by its experimental routing edge. An agent can immediately understand what the tool does and how it differs from ask_pipeworx and ask_pipeworx_grounded.

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 gives explicit when-to-use guidance: use it exactly like ask_pipeworx when you want the newest routing, and know that results are compared against the stable router. It implies ask_pipeworx as the stable alternative, but does not fully spell out a when-not-to-use condition, so it stops just short of the strongest possible guidance.

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 declare readOnly/openWorld/idempotent, and the description adds substantial behavior beyond that: the refusal contract with enumerated refusal_reason values, the guarantee that extraction uses ONLY tool-result content, and the explicit cost tradeoff. No contradiction with annotations.

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

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

Front-loaded with purpose, then mechanism, return contract, usage guidance, and cost tradeoff — logically ordered with no fluff. Slightly dense and with minor redundancy between 'hallucination-resistant' and 'ONLY what the tool result contains,' but every sentence earns its place.

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?

There is no output schema, so the description carries the full return-format burden — and it does so thoroughly, spelling out both the success shape and all five refusal reasons. Combined with the schema and annotations, an agent has everything needed to invoke it correctly 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 coverage is 100% and the schema fully documents the single 'question' parameter including its five aliases. The description adds no param-specific detail, so the baseline of 3 applies since the schema does the heavy lifting.

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+resource: a 'hallucination-resistant answer mode' that routes to the right tool, fetches data, and extracts answers using only tool-result content. The grounding contract is explicit and distinguishes it from siblings ask_pipeworx and ask_pipeworx_beta.

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 ('whenever an answer will be quoted, cited, or acted on' with concrete domains like financial verdicts and legal claims) and when not to ('prefer ask_pipeworx for casual lookups'), backed by a cost rationale of one extra LLM call.

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 indicate read-only, idempotent, non-destructive. Description adds extensive behavioral details: fan-out patterns, response shapes, resolver contract, safety short-circuits, cancellation rules. Contradicts no 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?

Description is very long and dense, containing numerous details. It front-loads the main purpose but lacks structural formatting (e.g., bullet points). Length is justified by complexity, but could be more concise.

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?

Covers input, output, error conditions, edge cases, and response interpretation extensively. Even includes cancellation rule parsing and news fallback behavior. Very complete given no 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?

Schema coverage is 100% with clear parameter descriptions. Description adds examples and context for depth and include_raw, but does not significantly augment the schema documentation.

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 researches a Polymarket bet by pulling Pipeworx data. Input types and output are specified. It distinguishes from siblings implicitly by being comprehensive, but does not explicitly contrast with other Polymarket tools like polymarket_edges.

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?

Provides explicit usage cases ('should I bet on X', etc.) and important checks (market_match_confidence, wide spread, cancellation rules). Lacks explicit when-not-to-use or alternatives, but guidance 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, etc. Description adds meaningful behavioral context: it pulls specific financials from SEC EDGAR/XBRL for companies and FAERS/FDA data for drugs, handles off-calendar fiscal years, sorts results by primary metric, and returns citation URIs. No contradiction with annotations.

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

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

The description is a single paragraph that packs in trigger phrases, data sources, sorting, and return format. It is reasonably concise for the detail provided, though a slight structural separation (e.g., bullet points) could improve readability. Still 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?

Given no output schema, the description adequately covers return values: 'paired data + pipeworx:// citation URIs per entity'. It also explains sorting behavior. The tool's wide scope (two entity types with distinct data) is fully described. Sibling tools like 'entity_profile' exist, but this comparison tool is distinct and 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 coverage is 100% (baseline 3), but description adds significant value: it explains that 'type'='company' pulls revenue/net income/cash/debt from latest 10-K, while 'type'='drug' pulls FAERS/FDA/trial counts. It also provides concrete examples of valid values (tickers/CIKs for company, drug names) and clarifies the array limits (2–5).

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 compares 2–5 companies or drugs in a single parallel call, with specific trigger phrases like 'X vs Y' or 'which is bigger'. It distinguishes from sibling tool 'entity_profile' which likely does single entity lookups, making purpose unambiguous.

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 'ALWAYS PREFER over sequential single-pack lookups when comparing entities', providing strong guidance on when to use this tool instead of alternatives. While it doesn't list when not to use, the context makes it 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?

Beyond the readOnly/idempotent annotations, the description discloses account requirements, paid-tier limitations, latency, parallel tool routing, output packet structure, gaps[] for unanswered facets, contradictions[], fetchable citation URIs, and semantic excerpting. This is far richer than the annotations alone and contains no contradiction.

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 dense and front-loaded with the prerequisite and alternative, but it is long and contains some run-on sentences that bundle multiple ideas together. Every sentence carries useful information, though tighter structuring would improve scanability.

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 the findings packet contains, how gaps are handled, how contradictions appear, and what the citation_uri means. It also covers latency, account requirements, and depth-level behavior, so the agent has a complete picture for invoking the tool 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?

The input schema already has 100% coverage with detailed enum descriptions for depth and question. The prose adds meaningful context about paid access for 'thorough' and the gap-recovery/contradiction behavior of specific depth levels, which goes slightly beyond the schema 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?

The description names a specific verb ('researches') and resource ('Pipeworx's 1517 STRUCTURED data sources'), and immediately contrasts itself with open-web search. It also explicitly distinguishes this tool from ask_pipeworx for single-lookup cases, so an agent can tell them apart.

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 says exactly when to use this tool ('broad/multi-part questions over structured data'), when not to ('single lookup'), and names the alternative (ask_pipeworx) plus the account/tier caveat. The guidance is explicit, not just implied.

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 indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false; description adds that it returns top-N relevant tools with full schemas ready to call, which complements annotations. 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?

Description is slightly long but front-loaded with purpose. Every sentence adds value; could be tightened but still 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?

Given no output schema, description fully explains what is returned (top-N, names, descriptions, schemas). Covers all needed context for a discovery 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?

Schema description coverage is 100%, so description adds limited value beyond schema. It provides examples and mentions aliases, but the schema already documents all parameters. Baseline 3 is appropriate.

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 'find tools by describing the data or task' with specific verb+resource. Distinguishes from sibling tools which are narrow (e.g., get_fireballs, bet_research) by positioning it as a discovery 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?

Explicitly says 'Use when you need to browse, search, look up, or discover what tools exist' and 'Call this FIRST when you have many tools available'. Does not explicitly state when not to use, but context implies 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?

The annotations already mark the tool read-only, open-world, and idempotent, and the description adds substantial behavioral detail beyond that: it lists all fanned-out external sources, discloses the USPTO API sunset soft-fail, explains that empty sections mean real 'no data,' and clarifies the resolved:false behavior for private companies. This is exemplary transparency.

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 front-loaded with examples and core purpose, which is good, but it is very long and dense, with parentheticals and inline lists that are hard to scan. It also repeats parameter semantics already covered by the schema, so a bulleted structure would preserve completeness while improving conciseness.

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 to lean on, the description thoroughly enumerates every return section, from cik and recent_filings to fda_products and sources_used/sources_failed. It also covers expected failures and edge cases, so an agent has nearly everything needed to invoke the tool 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 a baseline of 3 is appropriate. The description restates nearly the same parameter facts already in the schema (ticker/CIK/name values, 'company' and 'ticker' accepted interchangeably), adding only marginal extra context such as SEC EDGAR name resolution and zero-padded CIK formatting.

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?

It names a specific capability—'full cross-source profile of a US public company'—and opens with multiple concrete user intents ('Tell me about X', 'research Acme'). It also draws a boundary against chaining single-pack lookups, giving enough shape to distinguish it from narrower sibling 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 explicitly says to prefer this tool 'over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view,' which is clear when-to-use guidance. It doesn't spell out when to choose a narrower sibling like compare_entities, but the preference and acceptable input forms are well defined.

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 indicate destructiveHint=true and readOnlyHint=false, so the description's mention of deletion aligns. No contradiction, but the description adds minimal behavioral 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?

Two sentences, front-loaded with purpose, no extraneous information. Every sentence earns its place.

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 parameter and annotations, the description is complete: covers purpose, usage context, and sibling pairing.

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 description does not add extra meaning beyond the schema's 'Memory key to delete' for the parameter 'key'. Baseline score of 3 is appropriate.

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 explicitly states 'Delete a previously stored memory by key', including a specific verb (delete) and resource (memory). It distinguishes from sibling tools like remember and recall.

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?

Provides explicit guidance on when to use: 'when context is stale, the task is done, or you want to clear sensitive data the agent saved earlier. Pair with remember and recall.'

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?

Description details the process: fetches page, extracts title/description/key links, emits standard markdown. Annotations already declare readOnlyHint and idempotent, and description aligns and adds context.

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 concise sentences: first states action, second explains process and uses. Every sentence is necessary and front-loaded with 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?

Given 2 params, no output schema, and no nested objects, the description covers purpose, process, output format, and use cases completely. No gaps.

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 descriptions fully cover parameters (100% coverage). The description adds context about output format (markdown blob for site-root), which is beyond schema, justifying above-baseline 4.

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 verb 'Generate' and the resource 'llms.txt file'. It explains the purpose for AI crawlers and distinguishes from siblings by being unique among the list.

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 lists use cases: getting a client's site indexed, drafting for own project, auditing a competitor. No sibling tool performs this function, so 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?

Annotations already declare readOnlyHint, idempotentHint, and no destructiveness. The description adds the return fields and the 0.05 AU threshold but does not disclose any additional behavioral traits beyond what annotations provide.

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, no wasted words. Efficient and to the point.

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 low parameter count and presence of output schema, the description is fairly complete. It lists key return fields but does not specify the time frame for close approaches, which could be ambiguous.

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. The description does not add meaning beyond the schema for the 'limit' parameter. It mentions the 0.05 AU distance but that is not a parameter.

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 finds near-Earth asteroids making close approaches within 0.05 AU and returns specific fields. It is a specific verb-resource pair and distinguishes from siblings like get_neo_feed and get_fireballs.

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 implies usage for identifying potentially hazardous objects but does not explicitly state when to use this tool versus alternatives like get_neo_feed. There is no guidance on exclusions or prerequisites.

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, idempotentHint, and openWorldHint, covering core safety. The description adds that data comes from US government sensors and lists returned fields, providing some additional behavioral context. However, it does not mention rate limits, data freshness, or that the result set may vary (open world). The description does not contradict 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 with no unnecessary words. The first sentence front-loads the purpose; the second sentence succinctly lists return fields. Every word is informative and earns its place.

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 optional param, no required fields, output schema exists), the description is reasonably complete. It identifies the data source (US government sensors) and return fields, which is helpful. It omits pagination or empty result behavior, but these are minor given the output schema. The description adequately complements the structured fields.

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 clear description for the 'limit' parameter. The description adds no additional meaning beyond what the schema provides (default 10, max 100). Thus, the description adds marginal value over schema alone, meeting the 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?

The description clearly states the tool tracks recent meteor impacts and atmospheric explosions, returning specific data fields. While it does not explicitly differentiate from siblings like get_close_approaches or get_neo_feed, the focus on 'impacts' and 'explosions' implies a distinct scope. A more precise verb like 'retrieve' would improve clarity, but purpose is not vague.

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 implies usage for tracking recent meteor impacts but provides no explicit guidance on when to use this tool versus alternatives (e.g., get_close_approaches for asteroid close approaches, get_neo_feed for near-Earth objects). There are no exclusions or context about prerequisites, so the agent must infer from the description alone.

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, idempotentHint=true, and destructiveHint=false. The description adds context about the return data (asteroid names, sizes, velocities, etc.), which is useful beyond the annotations. No contradictions are present, and the description aligns with the read-only nature of the 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?

The description is two sentences with no wasted words. The first sentence clearly states the tool's purpose and scope, and the second enumerates return fields. It is 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?

Given the low complexity (2 parameters, read-only) and the presence of an output schema, the description covers all essential aspects: purpose, parameter semantics via schema, and return field summary. No additional information is needed for an agent to correctly invoke 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?

Schema coverage is 100%, with detailed descriptions and examples for both parameters. The description adds a date range example ('2024-01-01' to '2024-12-31') but does not provide significant new semantic meaning beyond what the schema already offers. Baseline score of 3 is appropriate.

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 retrieves near-Earth objects passing Earth during a date range. It lists specific returned fields (names, sizes, velocities, miss distances, hazard status), distinguishing it as a focused NEO feed tool. Although sibling tools like get_close_approaches exist, the description is sufficiently specific to convey its unique purpose.

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 implies usage for obtaining NEO data over a date range but provides no explicit guidance on when to use this tool versus alternatives like get_close_approaches. No exclusions or when-not-to-use advice is given, leaving the agent to infer context from the tool name.

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, idempotentHint, and non-destructive behavior. The description adds value by specifying the exact return fields and the distinction between active and inactive subscriptions, though it omits potential details like pagination 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?

Two concise sentences: the first states purpose and return fields, the second provides usage guidance. Every sentence earns its place with no extraneous content.

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, the description fully covers what it does, what it returns, and when to use it. The optional parameter is documented in schema, and no output schema is needed given the listed fields.

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 for the single parameter include_inactive is 100%, and the description does not add meaning beyond what the schema already provides. Baseline score of 3 is appropriate.

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 ('List') and resource ('the caller's active subscriptions'), and explicitly lists the return fields, distinguishing it from sibling tools like subscribe and unsubscribe.

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 advises using this tool 'to review what you're monitoring before adding more or to find an id to cancel', providing clear context and when-to-use guidance relative to 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?

All annotations are false (readOnlyHint, openWorldHint, idempotentHint, destructiveHint), so the description carries the full disclosure burden. It does so comprehensively: it reveals the claim_token retry mechanism, rate limiting ('5 per identifier per day'), quota exemption, content guidelines, and the team's daily digest process. This far exceeds minimal behavioral disclosure and contradicts nothing in the structured 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?

The description is long, but every sentence contributes distinct value: purpose, usage triggers, exclusions, tool identification, content guidance, token recheck workflow, and operational details. It is front-loaded with the core purpose and organizes increasingly specific information, justifying its length without 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?

Given the tool's complexity (4 parameters, 1 nested object, no output schema), the description covers all essential aspects: when to use it, boundaries, formatting requirements, claim_token retrieval/usage, and rate limits. It leaves no significant context gap for an agent to misuse 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?

The input schema already describes all parameters at 100% coverage, so the baseline is 3. The description adds meaningful semantics beyond the schema, particularly for claim_token (explaining the exact usage pattern `pipeworx_feedback({claim_token:"pwfb_…"})`) and message (advising against pasting the end-user prompt). This enriches parameter understanding beyond what the schema alone 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?

The description opens with a specific verb and resource: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' This unambiguously identifies the tool as a feedback submission mechanism and clearly distinguishes it from sibling tools like ask_pipeworx or discover_tools by focusing on reporting issues rather than querying information.

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 enumerates use cases (bug, feature/data_gap, praise) and, critically, states when NOT to use it: 'if the tool came from a different MCP server... file it with that server instead.' It also clarifies how to identify Pipeworx tools, giving precise when-to-use/when-not-to-use guidance that no other tool offers.

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 it as readOnly, openWorld, idempotent, and non-destructive. Description adds valuable context: data source (CF analytics-engine), no PII, caching behavior (5min-1h). 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 and well-structured: opens with main output, then use cases (numbered), then technical details (data source, privacy, caching). Every sentence serves a purpose with 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?

Despite no output schema, description adequately describes output (top tools, packs, volume). Covers caching, privacy, and data source. Missing output format details, but not critical for this simple 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?

Only one parameter (window) with 100% schema coverage. Description adds extra context: shorter windows for 'hot right now', longer for 'steady-state demand', enhancing the enum 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?

Clearly states it returns top tools, top packs, and total call volume over a window. Provides three specific use cases that distinguish it from sibling tools like discover_tools or ask_pipeworx.

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 lists three use cases (discovery, confirmation, alignment). Does not explicitly state when not to use, but the use cases imply appropriate contexts. No alternative tools mentioned, but the specificity 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?

The description goes far beyond the annotations (readOnlyHint, openWorldHint) by detailing internal mechanics: Jaccard similarity threshold (≥0.30), placeholder filter, partition check, and fill check (including realizable_edge_pp vs theoretical). It warns when a signal is not actionable. No contradictions with annotations.

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

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

The description is long but well-structured, front-loading the core purpose and then detailing each mode. It contains no redundancy and every sentence adds valuable information. It could be slightly more terse, but given the complexity, it earns a 4.

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 lacking an output schema, the description thoroughly explains the response structure (opportunities array, partition_check fields, fill_check results) and provides example inputs. It covers edge cases (placeholders, fill check) and references a sibling tool for custom sizing. The tool is complex, yet the description makes it actionable.

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?

Although the input schema already describes the parameters (100% coverage), the description adds significant context: for event, it explains the partition check and date-axis/threshold-axis ordering; for topic, it explains cross-event scanning and the semantic anchor. This adds meaning 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: finding arbitrage opportunities on Polymarket via monotonicity violations and partition-sum checks. It specifies three modes (trending_scan, event, topic) and their scopes, making it distinct from sibling tools like polymarket_edges or polymarket_fill_risk.

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 guidance on when to use each parameter: no args for trending scan, event for a specific market (recommended), and topic for cross-event scanning. However, it does not explicitly compare this tool to the sibling Polymarket tools, leaving some ambiguity for users unfamiliar with the ecosystem.

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 declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description confirms read-only scanning and adds rich behavioral context: caching (1h KV-level), slippage assumptions, zero fees, and model family details. No contradiction with annotations.

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

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

The description is front-loaded with purpose and then structured into model families, knobs, and response layout. It is dense but not wasteful; however, it could be slightly more concise without losing critical detail. Every sentence earns its place.

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 9 parameters, no output schema, and high complexity, the description explains the response structure (by_segment, fed_candidates, diagnostics) and why segments might be empty. It covers all necessary aspects for an agent to understand and use the tool effectively.

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 extra context for parameters beyond the schema, e.g., explains slippage_pp with Polymarket fee structure, suggests values for min_liquidity and max_spread_pp, and describes min_kelly usage. This significantly enriches 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?

The description states a specific verb+resource: 'Scan top Polymarket markets and return opportunities where Pipeworx data disagrees with market price.' It distinguishes from sibling tools by detailing five model families and response segments, making clear what this tool does versus others like polymarket_arbitrage.

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 frames the tool for 'what should I bet on today' and notes that Fed bets are excluded from ranking due to unreliable signal without paid data. It provides guidance on knobs and caching but does not explicitly contrast with alternatives or state when not to use.

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 the tool as read-only, open-world, idempotent, and non-destructive. The description adds valuable behavioral info: snapshot gaps, decay computation methods, and history depth limits. No contradiction with annotations.

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

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

The description is moderately long but well-structured: purpose first, then detailed output format, then limits. Every sentence provides useful information, though it could be slightly more concise without losing clarity.

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 fully explains the return structure (tracked[], expired[], snapshot_dates[]), including field meanings and edge cases (e.g., gaps). It also covers limitations, making the tool behavior transparent and 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%, so baseline 3. The description adds context by specifying defaults (14 and '1wk'), max for days (30), and explains the response structure in detail, which compensates for the lack of parameter-specific nuance in 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 explicitly states it provides 'Edge persistence and decay telemetry' and answers a specific question about edge freshness. It clearly distinguishes itself from sibling tools like 'polymarket_edges' by focusing on historical persistence rather than just current edges.

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 gives strong context for when to use: to differentiate between fresh and old edges. It mentions limits (60-day TTL, snapshot gaps) but does not explicitly list alternatives or when not to use. Still, the guidance is clear enough for an AI agent to decide.

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 indicate read-only, idempotent, open-world hints. The description adds extensive behavioral context: walks the order book ladder, returns specific fields for each mode, warns about forced directional risk and thin legs. No contradiction with annotations.

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

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

The description is dense but slightly verbose. It is front-loaded with purpose and includes all necessary information, but could benefit from bullet points or subheadings for faster agent parsing. Still, every sentence adds value.

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 thoroughly explains return values for both modes, including edge cases like thin legs and forced directional risk. For a tool with 4 parameters and no output schema, this is fully 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%, but the description adds significant meaning beyond schema: explains side defaults for basket mode, interprets size_usd differently for single-market vs basket (spend vs settlement notional), and details the outcome parameters. This compensates fully for any lack of param documentation.

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 performs a realizable-vs-theoretical edge check against live order-book depth. It distinguishes single-market and basket modes, and explicitly contrasts with sibling tools polymarket_arbitrage and polymarket_edges by advising use before acting on their signals.

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 specifies when to use (before arb signals or trades >$500) and provides required parameters and default behavior. It warns about partial basket fills converting arbs into unhedged positions, but does not explicitly list conditions where the tool should not be used.

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 description provides extensive behavioral disclosure beyond the readOnly/idempotent annotations: the token-overlap matcher, compatibility codes, fee disclaimer, skipped-leg counters, and the fact that unknown legs are never paired. It explains caveats such as `temporal_alignment_unknown` being distinct from confirmed alignment. No contradiction with annotations exists.

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 very long, but the complexity of the tool justifies most of it, and the structure uses bold labels like 'TWO MODES', 'RESPONSE', and 'SAFETY FIELDS' to aid scanning. Some redundancy exists around 'in EITHER mode' and repeated compatibility-code warnings, which keeps it from a perfect score.

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 there is no output schema and only three optional parameters, the description fully compensates by documenting return fields, compatibility flags, skip counters, fee treatment, and failure modes. An agent has enough detail to call the tool, interpret results, and recognize when matches are unreliable.

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 adds meaningful semantics: `topic` auto-fetches a matching event, explicit parameters override the topic-mapped side, and both modes run the same matcher. This enriches the schema beyond its terse parameter 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?

The description opens with a specific verb and resource: 'Cross-venue spread between Kalshi and Polymarket for the same resolving question.' It clearly distinguishes its two modes, making it easy for an agent to understand the tool's role and how it differs from a simple price lookup.

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 gives explicit mode-level guidance: use `topic` for pre-mapped shortcuts and explicit `kalshi_event_ticker` + `polymarket_event_slug` for custom pairings. It also warns that pre-mapped topics are not guaranteed tradeable. It lacks an explicit comparison to sibling tools like `polymarket_arbitrage`, but internally the usage guidance 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?

Annotations already declare readOnly, idempotent, non-destructive. Description adds scoping to identifier and behavior of omitting key, 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 four-sentence paragraph, front-loaded with main purpose, 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?

Lacks explicit mention of return format or type, but given simplicity and annotations, it's nearly complete. Minor 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 covers key parameter 100%. Description explains omission behavior for listing, adding meaning 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?

Clearly states retrieval and listing. Distinguishes from sibling tools remember/forget with concrete use cases.

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 use (look up stored context) and how to use (omit key for listing). Scoping and pairing with remember/forget mentioned.

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?

Adds significant behavioral detail beyond annotations: describes returned fields (source, citation_uri, raw event payload), explains mark_read side-effect ('next call only shows newer ones'), and confirms idempotent behavior aligns with annotations.

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

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

Four concise, information-dense sentences. Front-loaded with main purpose, then details and examples. 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 read-only polling tool with 5 optional parameters and no output schema, the description fully explains return values, filtering, side-effects, and alternative access method. Annotations cover safety, idempotency, and open-world semantics.

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 descriptions for all 5 parameters. Description adds value with example type ('sec_8k'), clarifies ISO timestamp format for since, and explains the functional effect of mark_read beyond basic boolean toggle.

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?

Explicitly states 'Pull fired events from your subscription feed' with specific resource and verb. Distinguishes from sibling tools like list_subscriptions and get_neo_feed by focusing on alert events from a feed.

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?

Provides guidance on polling ('Polls work fine') and alternative REST endpoint for scripts/dashboards. Mentions filtering options (type, since) and mark_read behavior, though does not explicitly contrast with 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?

Annotations already indicate safe read-only behavior. The description adds details: fans out to multiple sources, fallback from GDELT to GNews on rate limits or 5xx, USPTO soft-fail until reactivated, and output structure. This provides behavioral context beyond annotations without contradiction.

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 front-loaded with example queries and packs useful information without significant fluff. It is somewhat lengthy but each sentence contributes value. Could be slightly tighter but overall 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?

No output schema exists, but the description adequately explains return structure (changes[] grouped by source, total_changes count, citation URIs). It covers purpose, parameters, behavior, and alternatives, making it complete for a complex multi-source 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?

Schema coverage is 100%, so baseline 3. The description adds meaning: examples for `since` (ISO date and relative shorthand), typical monitoring value ("30d" or "1m"), and clarifications for `value` (ticker or CIK) and `type` (only "company"). This exceeds schema 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?

The description clearly states it provides a change feed for a company in a recent time window, listing specific data sources (SEC EDGAR, GDELT→GNews, USPTO) and explicitly distinguishes from the sibling tool entity_profile by advising when to use that instead.

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 example queries and guidance on when to use entity_profile instead. It explains fallback behavior and `since` format. However, it does not explicitly list when not to use this tool beyond the one sibling 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 indicate idempotent and not destructive; description adds scoping, persistence details (auth vs anonymous), and pairing info, going beyond 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?

Five sentences, front-loaded with purpose, no fluff, efficiently conveying all necessary 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?

Given low complexity (2 params, no output schema) and rich annotations, description covers scope, persistence, and companions, making it fully 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 covers 100% with descriptions; description adds examples of key names and value types, enhancing understanding 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?

Description uses specific verb 'Save' and resource 'data the agent will need to reuse later', clearly distinguishing from siblings like recall and forget.

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 'Use when you discover something worth carrying forward' and pairs with recall/forget, providing excellent guidance on when to use.

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 the tool as read-only, open-world, idempotent, and non-destructive. The description adds meaningful behavioral context: internal cascading through multiple lookup endpoints, graceful degradation when GLEIF or OpenFIGI is unavailable, ambiguous names returning figi_candidates instead of asserting, and unresolved identifiers explicitly listed. There is no contradiction with 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?

The description is long and dense, but it is front-loaded with user-facing examples and a 'Use FIRST' directive. The main supported-types section is heavy with nested parentheticals and could be parsed more easily, but almost every clause adds distinguishing information, so it earns its length for a complex resolver.

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 carries the full burden of explaining what the tool returns. It covers returned identifiers, candidate ambiguity, unresolved values, enrichment failure behavior, and the internal cascade. There are no critical gaps for an agent to call this tool 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%, but the description goes far beyond it. It explains the accepted input forms for the value parameter (ticker, CIK, ISIN, name, brand/generic), provides the 'ENTITY NAME ONLY' rule, shows the issuer-name example, and warns that trailing security-class words will break FIGI matching. This is exactly the kind of parameter guidance an agent needs.

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 starts with natural-language queries and states a clear verb-resource relationship: 'resolve a user-spoken NAME to the canonical/official identifiers other tools require as input.' It names two supported entity types and the specific identifiers produced (CIK, LEI, FIGI, RxCUI), which distinguishes it from siblings like entity_profile or validate_claim.

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 gives an explicit trigger: 'Use FIRST whenever you have a name but need an ID.' It also details accepted inputs for company and drug lookups. However, it does not explicitly name when-not-to-use it or name sibling tools as alternatives, so it stops just short of the highest guidance standard.

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 (readOnlyHint, idempotentHint, destructiveHint=false) already indicate safety. The description adds valuable behavioral details: it probes each entity using 'ai_visibility_check', ranks by score, and returns per-entity metrics (score, confidence, signal density). 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?

The description is three well-structured sentences: purpose, process, real-world use case, and output summary. Every sentence adds essential information without 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?

The description explains that the tool produces a ranked list with score, confidence, and signal density, which is sufficient for an agent to understand the return format. Given no output schema, this covers the key expectations. Minor completeness gap: no mention of pagination or error handling, but not critical for this 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?

Parameter schema coverage is 100%, so baseline is 3. The description adds meaning beyond the schema by specifying that the first entity in the array is treated as the 'subject' for narrative and the rest as competitors. This clarifies behavioral intent.

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 specific verbs ('compare', 'probes', 'ranks') and a clear resource ('AI visibility across multiple entities'). It explicitly distinguishes itself from the sibling tool 'ai_visibility_check' by describing its batch comparison function and competitive audit use case.

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 states when to use the tool ('competitive AI-marketing audits') and provides a concrete question example. While it does not explicitly list alternatives or when not to use it, the context is sufficiently clear for an agent to select this over a single-entity check.

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 provide readOnly, idempotent hints, but the description adds valuable behavioral details: fans out across deps.dev and bundlephobia, returns specific fields, partial failures degrade gracefully, and Bundlephobia timing issue. This adds significant context beyond 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?

The description is detailed but front-loaded with core purpose. Each sentence adds value, though slightly long. Could be tightened without losing 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?

Despite no output schema, the description lists all returned fields in parentheses, covers partial failures, timing, and ecosystem scope. It is complete for a composite 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?

Schema coverage is 100% but description adds context: package name is required, accepts scoped packages, version defaults to latest. This adds value beyond schema, but schema already documents parameters well.

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: a composite check for adding an npm package, covering licenses, advisories, version history, and bundle size. It distinguishes from siblings by focusing on npm ecosystem and mentioning alternatives for other ecosystems.

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 (e.g., 'is X safe/popular/small') and provides limitations (NPM only, partial failures, timing). It could be improved by explicitly saying when not to use (e.g., for non-npm packages).

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?

Adds details beyond annotations, such as the embedding model (BGE-base-en), window size (500-char overlapping), character cap (200K), truncation flagging, and offset-based verification. No contradictions with annotations.

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

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

The description is concise with no wasted words. It front-loads the purpose, then provides additional context and technical details in a structured manner.

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 adequately communicates return format (passages with offsets and scores), covers limitations, and integrates with sibling tools, making it complete for an agent to use.

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 with natural-language query examples, explains the text parameter's character limit, and specifies the default and range for limit.

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 'Semantic search INSIDE a fetched record,' specifying the verb and resource. It distinguishes the tool from siblings by explaining when to use it: when the record is too large for the prompt.

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 provides usage context: 'Use when the record is too big to cram into the prompt' and mentions pairing with ask_pipeworx_grounded for grounding over relevant passages.

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?

Adds significant context beyond annotations: OAuth requirement, SMS rate limit (10/day), webhook signing secret, auto-disable after 10 failures. Aligns with annotations (readOnlyHint=false, idempotentHint=true).

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?

Well-structured with clear sections: purpose, return, requirement, types, delivery channels. Slightly long (~150 words) but every sentence adds value.

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?

Covers prerequisites, type-specific params, delivery options with details. No output schema, but description adequately explains return value (subscription id). Complete for 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 100% and description adds examples and explanations (e.g., item code meaning for sec_8k) that go 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?

Clearly states 'Create a proactive monitoring subscription to a live-data event stream' and mentions returning subscription id. Distinguishes from siblings like list_subscriptions and unsubscribe.

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?

Explains when to use (proactive monitoring) and prerequisites (OAuth account). Does not explicitly contrast with polling alternatives but covers requirements and type options.

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, openWorldHint, idempotentHint, destructiveHint. The description adds value by explaining the returned output structure (category-bucketed examples with exact tool+argument shape) and the no-args vs topic behavior, which are 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?

The description is moderately long but front-loaded with common queries and structured with a clear purpose statement, usage guidance, and return format. Every sentence contributes meaning, though could be slightly more concise without losing completeness.

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 fully explains the return value (category-bucketed example questions with tool and argument shape). It covers both invocation modes (no args vs topic) and is sufficient for an agent to understand and use the tool 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% with single optional parameter. The description adds context by listing example topic values ('finance', 'pharma', etc.) and explaining the effect of omitting the parameter, augmenting the schema's minimal 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 returns category-bucketed example questions drawn from the live catalog, positioning it as the onboarding entry point. It specifies verbs like 'returns' and resource 'example questions', distinguishing it from sibling tools focused on specific queries or research.

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 using this tool first when the agent does not know what Pipeworx can do. Also explains how to narrow by topic or omit for full spread, providing clear when-to-use guidance.

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 the row is deactivated (not deleted) and historical events remain, adding value beyond annotations which indicate non-destructive and non-read-only.

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 action, no unnecessary words. Highly concise and well-structured.

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 single-param tool with no output schema, the description covers ownership, deactivation, and linkage to recent_alerts, fully meeting completeness needs.

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?

With 100% schema coverage, the description adds context that the id comes from 'subscribe', improving parameter understanding for the agent.

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 resource 'subscription', and distinguishes from siblings like 'subscribe' and 'list_subscriptions'.

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 ownership enforcement and deactivation behavior, guiding when to use. Lacks explicit alternatives but context from sibling names suffices.

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?

Beyond the readOnly/idempotent annotations, the description discloses a critical trap: 'could_not_verify means the check did not happen... must not be shown as one' and distinguishes 'unsupported' as 'we looked and cover no source for it.' It also explains internal routing and the percent-delta math, all beyond annotation defaults.

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 long, but every sentence earns its place—trigger phrases, scope, routing, verdict list, error caveat, and efficiency claim. It is front-loaded with the most actionable content (when to use) and uses bullet-like structure within prose.

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 enumerates the return values: verdict categories, 'grounded or structured actual value with pipeworx:// citation, and reasoning.' It also explains error semantics, unsupported vs. could_not_verify, and the two pipeline paths, making the tool's behavior unambiguous.

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% for both params, but the description adds practical guidance: tolerance_pct 'overrides the tolerance implied by the claim wording' and recommends 'set 1–2 for hallucination detection.' The claim parameter is illustrated with examples in the schema, so the description's added value is moderate but real.

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 opens with clear trigger phrases and explicitly states the tool performs 'natural-language claim verification against authoritative sources.' It distinguishes itself from sibling research/query tools by emphasizing a structured verdict (confirmed, refuted, etc.) and a combined pipeline that replaces multiple sequential 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?

It directly states 'Use whenever the agent needs to check whether something a user said is factually correct' and provides concrete routing rules (company-financial claims via SEC EDGAR, all others via the grounded pipeline). The final line 'Replaces 4–6 sequential calls' gives a strong reason to prefer this tool over composing alternatives.

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