Studio Ghibli

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the base is safe. The description adds valuable behavioral context beyond these: the default model is free, passing `_apiKey` triggers direct billing to Anthropic, and the response structure is specified (per-model {score, confidence, signals, raw_response} + combined view). This gives the agent critical cost and output-shape information.

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 sentences with no filler. It front-loads the core purpose, then adds model/cost details, then the return format and use cases. Every sentence carries information without redundancy, maintaining a compact and scannable 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?

With no output schema, the description compensates by detailing the return shape. It covers all parameters indirectly (defaults and conditions) and provides clear use cases. The tool's complexity (4 params, external API calls, cost implications) is fully addressed within the description, making it self-sufficient for an agent.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds extra semantic nuance: 'Omit for just workers-ai' clarifies the models parameter's default behavior, `_apiKey` is explained as 'only needed if anthropic is in models' and passed straight through, and `context` is described as helping disambiguate common names. These additions provide usage-oriented 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 opens with a specific verb and resource: 'Probe one or more LLMs for what they know about a business / brand / product / topic and score visibility (0-100) per model.' It clearly states the tool's function and differentiates itself from siblings like ask_pipeworx by focusing on visibility scoring rather than answering questions. The use cases ('AI-marketing audits, pre-launch brand checks, competitive monitoring') further clarify its 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 provides explicit use cases ('Useful for AI-marketing audits, pre-launch brand checks, competitive monitoring') and clearly explains when to include optional parameters (e.g., 'pass `_apiKey` to also probe Anthropic'). However, it does not mention alternatives by name or state when not to use this tool, so it falls short of full when/when-not 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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the description doesn't need to restate those. It adds meaningful behavioral context: the tool routes to a large collection, fills arguments, returns structured answers with stable citation URIs, and is described as fast and single-call. This goes beyond annotations without contradicting them.

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

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

The description is longer than average but well-structured: it opens with a strong directive, explains function, lists trigger phrases, gives examples, and then details escalation paths. While every sentence adds value, some phrases like 'works on every tier, one fast call' are somewhat redundant and could be trimmed without losing meaning.

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 complex routing tool with no output schema, the description is remarkably complete. It explains what the tool returns (structured answers with citation URIs), how it operates (routes and fills arguments), when to use it, and when to escalate to specific alternatives. No critical behavioral or usage aspect is left unaddressed.

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 schema has 100% coverage with a simple 'question' parameter and aliases, but the description enriches semantics by listing accepted question types across many domains and providing concrete examples like 'current US unemployment rate' and 'Apple's latest 10-K'. This helps the agent formulate appropriate queries beyond what the schema alone conveys.

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 and resource: it routes questions to one of 5,462 tools across 1,419 verified sources and returns structured answers with pipeworx:// citation URIs. It clearly distinguishes itself from sibling tools like ask_pipeworx_grounded and deep_research by positioning itself as the default entry point.

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 tool over web search for specific domains and gives trigger phrases like 'what is', 'look up', 'find', and 'get the latest'. It also provides when-not-to-use guidance by instructing to step up to ask_pipeworx_grounded for hallucination-resistant answers and to deep_research for broad/multi-part questions.

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 adds valuable behavioral context beyond the annotations: it explains the experimental nature, that candidate routing improvements may be active live, that no candidate is currently active, and that results feed merge decisions. This goes beyond the basic readOnly/idempotent hints and clarifies the tool's role as a live experiment.

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 about three sentences and front-loads the key fact that it's a beta version. It is somewhat detailed with numbers and dates, but each sentence contributes meaningfully to explaining the tool's behavior and usage. It is not as tight as the best examples, but it's effective.

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

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

Given the tool's complexity as a universal router with no output schema, the description covers the essential contextual points: beta status, equivalence to stable, when to use, and experimental nature. It doesn't describe the routing behavior in depth, but that is likely out of scope and the same-response-shape note helps.

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 all parameters (question and its aliases) clearly documented in the input schema. The description does not add parameter-level detail, but the baseline of 3 is appropriate since the schema already fully explains the 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 explicitly identifies this as a beta version of ask_pipeworx, a universal router with the same tools and arguments, and distinguishes it from the stable sibling by noting it may have candidate routing improvements. This clearly states the verb (ask/route) and resource, while differentiating from 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?

The description says 'Use it exactly like ask_pipeworx when you want the newest routing', providing explicit when-to-use context. It also clarifies that it is a full working router, not a fallback, and mentions results are compared against the stable router. However, it doesn't explicitly state when not to use it or mention alternatives like ask_pipeworx_grounded.

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 beyond the safe/idempotent annotations by detailing the grounded extraction behavior ('EXTRACTS the answer using ONLY what the tool result contains'), the refusal mechanism with specific refusal_reason enums, and the cost implication ('Costs one extra LLM call'). This is substantial additional behavioral 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?

The description is information-dense but front-loaded with the core purpose. Each sentence adds essential context (routing, return shape, refusal reasons, usage cases, cost tradeoff) without filler or redundancy. It is longer than average but every clause 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 no output schema, the description fully specifies the success return object ({answer, evidence, confidence, source, fetched_at, refusal_reason:null}) and the explicit refusal object with possible values. It also covers the underlying routing mechanism, the scale of tools/sources, use cases, and the cost comparison, making it complete for the tool's complexity.

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

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

All parameters are aliases for the single 'question' parameter, and the schema provides 100% description coverage. The tool description does not add parameter-level semantics beyond the schema, so the baseline of 3 applies.

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

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

The description opens with 'Hallucination-resistant answer mode for high-stakes reads,' which is a specific and distinct purpose. It explicitly contrasts with the sibling 'ask_pipeworx' by saying 'Same routing as ask_pipeworx... then EXTRACTS the answer using ONLY what the tool result contains,' clearly differentiating this grounded mode. The detailed return format further removes ambiguity.

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 gives explicit when-to-use instructions: 'Use whenever an answer will be quoted, cited, or acted on, and the agent must not invent facts (financial verdicts, legal claims, medical lookups, public statements).' It also states when NOT to use it: 'Costs one extra LLM call vs ask_pipeworx — prefer ask_pipeworx for casual lookups,' naming the alternative directly.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds substantial behavioral context: fan-out to category-specific data packs, resolver contract (market_match_confidence, alternatives), blocking statuses for low-confidence/closed markets, and safety suppression to prevent phantom matches. 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 long but well-structured with labeled sections (CLASSIFIERS, FAN-OUT EXAMPLES, RESPONSE SHAPES, RESOLVER CONTRACT, SAFETY). It is front-loaded with the core purpose in the first sentence. However, it is quite verbose and could be trimmed without losing essential guidance, so 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?

For a complex tool with no output schema, the description is remarkably complete. It details response shapes, resolver contract, parent-event extraction, news-field fallbacks, safety statuses, and resolution-rule risk. The agent has enough context to invoke 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 description coverage is 100%, with detailed descriptions for all three parameters (market, depth, include_raw). The description also reinforces the accepted formats for market but adds little beyond the schema. 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?

The description explicitly states it 'Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call.' This is a specific verb+resource, and the use cases ('should I bet on X', 'what does the data say about Y', 'is there edge in Z') clearly distinguish it from sibling tools like polymarket_edges or 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 gives explicit when-to-use guidance: 'Use for ...' and adds detailed context like checking resolution-rule risk before sizing. However, it does not name alternative tools or explicitly state when not to use it, so it stops short of a 5.

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

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

Annotations already indicate read-only, open-world, idempotent, non-destructive behavior, but the description adds substantial context: it performs a single parallel call, pulls specific financial metrics from SEC EDGAR/XBRL, handles off-calendar fiscal years, sorts results by primary metric, and returns paired data with citation URIs. This goes well beyond the annotation baseline.

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?

Though the description is moderately long, every sentence contributes value: trigger examples, preference rule, type-specific data sources, sorting behavior, and output notes. The structure front-loads the key purpose and usage, and there is no fluff or redundancy.

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

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

With no output schema, the description adequately explains what the tool returns (paired data + citation URIs) and covers edge cases like off-calendar fiscal years. Given the moderate complexity, annotations, and full schema coverage, the description is complete enough for an agent to select and 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?

The input schema already provides 100% coverage for the two parameters, but the description enhances meaning by detailing what each type ('company' vs 'drug') entails, giving concrete examples (AAPL, MSFT, ozempic, mounjaro), and explaining the metrics retrieved. This adds significant practical guidance 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 performs side-by-side comparisons of 2-5 companies or drugs in one parallel call, with a specific verb ('compare') and resource ('entities'). It is immediately distinguishable from sibling tools like entity_profile by emphasizing multi-entity comparison and replacing sequential single-pack lookups.

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 usage triggers ('Compare X and Y', 'X vs Y', 'which is bigger'), and explicitly instructs to ALWAYS PREFER this tool over sequential single-pack lookups when comparing entities. It also specifies type-specific data sources and behavior, effectively guiding the agent on when to invoke it.

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

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

Annotations already indicate read-only, open-world, idempotent behavior; the description adds substantial context beyond that: account requirements, parallel routing to 5,462 tools, gaps[] for unanswered facets, contradictions[], semantic excerpting, citation URI resolvability, and latency expectations. 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 long (~250 words) but every sentence carries useful information: prerequisites, use cases, alternatives, behavior, limitations, and performance. It is front-loaded with the critical account requirement. Could be more scannable with bullet points, but is not bloated with filler.

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

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

Despite no output schema, the description thoroughly explains the return structure (findings packet with evidence, confidence, source, fetched_at, citation_uri, gaps[], hop, contradictions[]) and edge cases (large records excerpted, citation always fetchable). It also covers account/auth requirements and latency, making it complete for a complex research 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% for both parameters, so baseline is 3. The description adds meaningful extra semantics: explains depth behavior (gap recovery, contradiction scan, paid tier), clarifies question accepts broad/multi-part input, and reinforces that results are grounded with citations. This goes beyond the schema's basic enum and 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 performs multi-source structured research in one call, explicitly contrasting with ask_pipeworx and noting it is NOT open-web search. It identifies the resource (Pipeworx's 1419 structured data sources) and the action (decomposes questions, routes to tools in parallel), distinguishing it from siblings.

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 when-to-use guidance: best for broad/multi-part questions over structured data, and gives direct alternatives for single lookups (ask_pipeworx), breaking/current-news topics (ask_pipeworx), and unsigned-in users (ask_pipeworx). Also specifies depth-level requirements, including the paid plan for 'thorough'.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds behavioral context beyond annotations by explaining that it returns top-N relevant tools with full input schemas and curated examples, so no second lookup is needed. This conveys the operational behavior and return format well, though it does not detail pagination or edge cases.

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 information-dense; every sentence serves a distinct purpose: purpose, usage, return format, and guidance to call first. The domain list is somewhat extensive but valuable for a discovery tool. It is structured and front-loaded with the core 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?

The description is complete for a discovery tool: it specifies the input (query), the output format (top-N tools with names, descriptions, schemas, examples), and the operational context (call first when unsure). With no output schema, the description adequately tells the agent what to expect. The only missing detail is the default/max limit, which lives in the schema anyway.

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 description doesn't need to compensate for missing parameter docs. The description adds a bit of semantics by framing the 'query' as a natural language task description, and the 'top-N' references the limit parameter, but most parameter meaning is already in the schema. This meets the baseline for high schema coverage.

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

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

The description states a clear, specific purpose: 'Find tools by describing the data or task.' It distinguishes itself from siblings by positioning as a meta-tool for discovery, rather than a direct data-querying tool. The explicit 'Call this FIRST' guidance further differentiates it from the list of domain-specific 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?

The description explicitly states when to use it: 'Use when you need to browse, search, look up, or discover what tools exist' and 'Call this FIRST when you have many tools available.' It implies when not to use it (when you already know the exact tool, the 'not just one answer' caveat) and points to the tool results as the alternative set.

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/openWorld/idempotent/non-destructive. The description adds crucial behavioral context: parallel fan-out across sources, the exact data returned (CIK, filings, fundamentals, patents, news, LEI), soft-failing patents due to API sunset, and GDELT→GNews fallback. 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 dense paragraph, but every clause adds value: examples, data sources, return fields, limitations, and alternatives. It's front-loaded and structured with semicolons for easy scanning. Slightly long but justified given the tool's richness.

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 documents the return structure (cik, company_name, recent_filings with URIs, fundamentals sorted, patents, news, LEI). It also covers the 'one parallel call' architectural detail and the API sunset soft-fail. Nothing critical is missing for an agent to select and invoke it.

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

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

Schema coverage is 100%, so baseline is 3. The description adds extra value by giving concrete examples ('AAPL' or '0000320193'), reinforcing zero-padding for CIK, and stating that names are not supported and should be resolved upfront. This goes beyond the schema's field 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 immediately states this is a 'full cross-source profile of a US public company in ONE parallel call,' with clear verbs and scope. It lists numerous example prompts and explicitly contrasts with chaining individual lookups, distinguishing it from siblings like resolve_entity.

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 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view.' It also provides a specific alternative: 'use resolve_entity first if you only have a name,' giving clear when-to-use and when-not-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?

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds no behavioral details beyond the schema, but for such a simple lookup there are no other behaviors to disclose, and there is 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 only four words, front-loaded with the core information. It is extremely concise and every word earns its place, making it easy to parse.

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

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

Given the tool's simplicity (one parameter, output schema present, annotations provided), the description sufficiently covers what the tool does. It does not mention edge cases or where the ID comes from, but these are not critical for a straightforward lookup 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 schema has one parameter 'id' of type string with 0% description coverage. The description's 'by id' confirms that the parameter is the film identifier, slightly clarifying its purpose. However, it does not provide format details or sourcing context, relying on the schema's example for that.

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 'Single film by id' clearly states the tool's function: retrieving one film using its ID. This is specific and distinguishes it from the sibling tool 'films' which likely returns multiple films.

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

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

The phrase 'by id' implies the usage context: use this tool when you have a film ID and need that specific film. However, it does not explicitly mention when not to use it or point to alternatives like 'films' for listing all films, so the guidance is implied rather than explicit.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds return fields and the optional limit but does not disclose potential performance characteristics, pagination, or other behavioral traits beyond what annotations and schema imply.

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 sentence, front-loaded with the action 'List', and includes all necessary details without redundant or filler 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?

The tool is simple with one optional parameter, has an output schema, and rich annotations. The description covers the core purpose, return fields, and limit semantics, which is sufficient for a read-only listing 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 schema has one parameter 'limit' with no description (0% coverage). The description compensates by stating 'up to optional limit', clarifying it as a maximum count. This adds meaning beyond the bare schema, though it doesn't specify defaults or maximum values.

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 the specific verb 'List' and clearly identifies the resource as 'all Studio Ghibli films' with an optional limit. This distinguishes it well from siblings like 'film', which likely targets an individual film.

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 listing films but does not explicitly contrast it with alternatives like 'film' or provide when-not-to-use guidance. The 'optional limit' gives some context but no clear decision 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 already declare destructiveHint=true and idempotentHint=true, so the description doesn't need to restate those. It adds minor context by mentioning 'clear sensitive data', but does not disclose additional behavioral traits like irreversibility or error handling beyond what annotations imply.

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 that are front-loaded with the core action, followed by usage guidance. Every sentence earns its place with no redundancy or filler.

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

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

For a simple single-parameter delete tool with strong annotations, the description is sufficiently complete. It covers purpose, usage triggers, and related tools. It does not explicitly state permanent deletion, but the destructiveHint annotation covers that, so no major 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 description coverage is 100% with 'Memory key to delete' explicitly documented. The description only says 'by key', adding no extra meaning beyond the schema. 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?

The description clearly states the tool deletes a stored memory by key, using the specific verb 'Delete' and the resource 'memory'. It distinguishes itself from siblings like 'remember' (store) and 'recall' (retrieve) by focusing on the deletion operation.

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 use cases: when context is stale, task is done, or to clear sensitive data. It also names related tools ('Pair with remember and recall'), effectively providing alternatives and contextual 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 already declare the tool read-only, idempotent, and non-destructive. The description adds value by detailing the operational behavior: fetches the page, extracts title/description/key links, and emits standard llms.txt markdown as a single text blob. This goes beyond the annotations and provides context on output structure.

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 sentences: purpose, process, and use cases. It is front-loaded with the main action, and every sentence carries meaningful information without redundancy. No unnecessary words or filler.

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

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

For a tool with two parameters and no output schema, the description adequately covers the return format ('single text blob ready to drop at site-root/llms.txt') and the workflow. It could mention potential error cases (e.g., invalid URL, fetch failures), but this is not critical given the annotations and simple parameter set.

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 covers both parameters (url and max_links) with clear descriptions, achieving 100% coverage. The description does not add extra detail about parameter syntax, constraints, or behavior beyond the schema. Since the schema is sufficient, the 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?

The description clearly states the tool's verb and resource: 'Generate a production-ready llms.txt file for any URL.' It also outlines the process (fetches, extracts, emits) and the specific output format. However, it does not explicitly differentiate from sibling tools like scan_competitor_ai_presence, though the unique llms.txt focus makes the 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?

The description provides explicit use cases under 'Useful for,' including getting a client's site indexed, drafting llms.txt for your own project, and auditing a competitor's AI visibility. It lacks direct comparison with alternatives or exclusions, but the use cases give 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?

Beyond the readOnly/idempotent annotations, the description discloses the exact return fields (id, type, params, created_at, last_fired_at, fire_count) and caller-specific scoping. It does not mention pagination, but the tool is simple enough that this is acceptable.

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: purpose, return fields, and usage guidance. Every sentence adds distinct value with no redundancy, filler, 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?

The description covers purpose, return values, and when to use the tool. Combined with annotations that declare it safe and idempotent, it is fully complete for this simple read-only operation. No output schema is necessary because return fields are explicitly listed.

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 schema already provides 100% coverage for the single parameter 'include_inactive' with a clear description. The tool description adds the context of 'active' but does not elaborate on the parameter itself, warranting the baseline score of 3.

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

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

The description precisely states 'List the caller's active subscriptions' with a clear verb, resource, and scope. It distinguishes itself from sibling tools by mentioning 'before adding more' (subscribe) and 'to find an id to cancel' (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?

It provides explicit use cases: 'review what you're monitoring before adding more' and 'find an id to cancel.' However, it does not name sibling tools as alternatives directly, so it falls slightly short of a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, fully conveying the safety profile. The description adds no extra behavioral context such as response format, rate limits, or prerequisites. Since annotations carry the burden, this is acceptable but not enhanced.

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 short sentence, 'Single location by id.', with no filler words or repetition. It is maximally concise and front-loaded, appropriate for a trivial lookup tool.

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 (one parameter), the presence of an output schema, and rich annotations, the description covers the essential purpose. It doesn't explain return values, but the output schema makes that unnecessary. The main gap is lack of usage context, but that is already reflected in the usage_guidelines score.

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

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

The only parameter 'id' is documented in the schema with type string and an example. The description's 'by id' adds minimal semantic clarity that this is the location identifier. With only one parameter and schema examples present, the description provides basic but sufficient compensation for the 0% schema description coverage.

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

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

The description 'Single location by id' clearly indicates the tool retrieves one location based on an identifier. Its singular form distinguishes it from sibling 'locations', which presumably lists multiple locations, and the 'by id' phrase specifies the access pattern. It lacks an explicit verb but is 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?

No guidance is given on when to use this tool versus alternatives. The description implies it is for looking up a specific location when an id is available, but it doesn't mention alternatives like 'locations' for listing or other relevant tools. There are no exclusions or context cues.

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, and destructiveHint=false, covering safety. The description adds 'up to optional limit,' which implies pagination/limiting behavior, but does not disclose additional traits like ordering or default behavior beyond the limit. Since output schema exists, return fields are already documented, so the incremental value is modest.

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, front-loaded sentence that states the action, resource, scope, limit behavior, and return fields without redundancy. Every element 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 simple list operation, a single optional parameter, and comprehensive annotations plus an output schema, the description fully covers the tool's behavior. It explains what is listed and the limit constraint; no further details are necessary for a tool of this complexity.

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

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

Schema coverage is 0%, so the description must clarify the single 'limit' parameter. The phrase 'up to optional limit' explicitly indicates that limit caps the number of results and is optional. This adds meaningful semantics that the input schema lacks.

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 the specific verb 'List' with the resource 'fictional locations' scoped to 'Studio Ghibli films'. It also names the return fields (name, climate, terrain, surface water, films) and notes the optional limit, clearly distinguishing it from the sibling 'location' tool (singular) by implying a collection return.

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 its usage—when you want to list locations—but provides no explicit when-to-use vs alternatives, no exclusions, and no mention of the singular 'location' tool for fetching a single location. It lacks the explicit guidance seen in high-scoring examples.

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 read-only, non-destructive, and idempotent behavior. The description adds value by disclosing the optional limit and the set of returned fields, which goes beyond the annotations. It does not describe edge cases like pagination or default when limit is omitted, but these are minor.

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, well-structured sentence with no wasted words. It front-loads the primary action and then lists the returned attributes, which is efficient and easy to scan.

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

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

For a simple list tool with one optional parameter and an output schema (context signal), the description fully covers the necessary behavioral and return information. It could mention what happens when 'limit' is omitted, but the phrase 'up to optional limit' implies a cap, and the output schema handles return structure.

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 schema has only a bare 'limit' number with no description (0% coverage). The description compensates by calling it 'optional' and explaining it limits the number of characters returned, providing semantics that the schema lacks. It does not specify a default or maximum, but the meaning is clear.

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

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

The description uses a specific verb ('List') and resource ('Studio Ghibli characters'), clearly distinguishing it from sibling tools like 'person' (which likely retrieves a single character). It also enumerates the returned fields, making the 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?

The description implies usage by stating it lists characters, but it does not explicitly contrast with alternatives like 'person' or mention when to choose this tool over other list/entity endpoints. Usage context is present but not directly stated.

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

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

Annotations already establish readOnlyHint, idempotentHint, and non-destructive behavior. The description adds the 'single' cardinality and id-based lookup, but does not disclose behavior for missing ids or any open-world nuances; with strong annotations this is acceptable but minimal.

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 five-word sentence, immediately front-loaded with the tool's core function. No wasted words.

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

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

Given the tool's low complexity (one required parameter), rich annotations, and presence of an output schema, the brief description covers the essential invocation detail. However, it could be more helpful by naming sibling tools or noting when to use this vs people/entity_profile, so it is not 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?

The schema has no description for the 'id' parameter (0% coverage), and the description only says 'by id', adding minimal semantic value. The parameter name and example UUID in the schema already convey most of the meaning, so the description does not substantially compensate.

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 the resource (person) and the access pattern (by id), clearly distinguishing it from sibling list tools like 'people'. It lacks an explicit verb, but 'single person by id' unambiguously implies retrieval of one record.

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?

No guidance is provided on when to choose this tool over siblings such as people, entity_profile, or compare_entities. The description only implies that it is for direct id lookups, with no exclusions or 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?

Annotations are all false, so description carries full burden. It discloses return behavior (claim_token), how to retrieve status later, rate limits (5/day), cost (free/no quota), and content rules (don't paste end-user prompt). This is far beyond minimal disclosure.

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

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

The description is long but each sentence serves a purpose: usage triggers, exclusions, claim-token mechanics, rate limits, and cost. It is front-loaded with the primary action and uses clear paragraph structure. Slightly heavy on operational details but justified by the tool's dual-mode behavior.

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 tool has two usage modes (file feedback and retrieve status with claim_token), a nested context object, no output schema, and a rate limit—all are covered in the description. It also guides what to include vs exclude, making it self-contained for an agent.

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% of parameters, but the description adds key semantics: claim_token has dual use (file vs retrieve) and message should reference Pipeworx tools/packs rather than user prompts. This enriches the raw schema descriptions for more effective invocation.

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

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

The description clearly states the tool's purpose: to tell the Pipeworx team about broken, missing, or needed capabilities. It enumerates feedback types (bug, feature/data_gap, praise) and explicitly differentiates from sibling tools like ask_pipeworx by limiting scope to Pipeworx connection 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?

Provides explicit when-to-use conditions: bug reports, feature/data_gap requests, and praise. It also states an exclusion (do not use for other vendors' MCP servers) and gives a verification heuristic ('Pipeworx tool names are the ones this connection lists').

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 adds significant context beyond the annotations: it discloses the data source (CF analytics-engine), privacy (no PII), return format (pack, tool, count), and caching behavior (5min-1h). This enriches the agent's understanding of the tool's behavior without contradicting any 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 well-structured and front-loaded with the core statement, followed by a useful-for list and a concise data provenance note. It is appropriately detailed but not overly verbose, though the list of use cases adds length.

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 (one optional parameter, no output schema), the description fully covers what the tool returns, the meaning of windows, use cases, and behavioral nuances like caching and privacy. It is complete for an agent to understand the tool's value and invocation.

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

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

The schema already provides full coverage (100%) for the only parameter 'window', including enum values, default, and semantics ('Shorter windows surface what's hot right now; longer windows show steady-state demand'). The description mentions the window options but adds no new parameter-specific meaning, so the baseline 3 applies.

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

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

The description clearly states the tool's function with a specific verb ('Returns') and resource (top tools, top packs, total call volume). It differentiates itself from siblings like discover_tools by focusing on what other AI agents are calling, making it a unique analytics/trending 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?

The description provides explicit use cases with three numbered scenarios, giving clear context for when to use the tool. However, it does not mention alternatives or when not to use it, so it lacks the full 'when-not' guidance for a score of 5.

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

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

Beyond the readOnly and idempotent annotations, the description discloses the semantic anchor threshold (≥0.30 Jaccard), placeholder filter behavior, and the fill check against live CLOB depth, including the critical rule that realizable_edge_pp ≤ 0 means don't trade. This is rich behavioral 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?

The description is long but densely structured with clear mode labels (trending_scan, event, topic) and sub-sections for semantic anchor, partition filter, response, and fill check. Every sentence carries operational guidance, and the most important purpose is front-loaded.

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

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

No output schema is provided, but the description outlines response structure (opportunities[], partition_check fields, fill check outputs). It covers edge cases (placeholder tolerance, low similarity rejection, thin legs) and states a clear trading rule, making the tool fully usable.

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?

Both parameters have descriptions in the schema, but the description adds depth: event accepts slugs or full URLs, topic uses seed question examples, and the modes' exact behavior is explained. This exceeds the schema baseline.

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

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

The description opens with a specific verb and resource: 'Find arbitrage opportunities on Polymarket via monotonicity violations + partition-sum checks.' It clearly distinguishes between event and topic modes, and names polymarket_fill_risk as a sibling for custom sizing, separating it from this 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 states when to use each mode: no args for trending_scan, event for a specific market, topic for cross-event scanning. It even gives examples and recommends event mode for specific markets, and points to polymarket_fill_risk for custom sizing.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds substantial behavioral detail beyond those: the exact computation of edge_pp_net, the structure of by_segment with three model families, the 24h-move warning, the diagnostics funnel counters, and the 1h KV-level caching keyed on knobs. It even discloses limitations (e.g., 'partition_overround... per-leg favorite-longshot bias correction with per-sport α', and the Fed signal being 'unreliable at meeting-month horizons'). This far exceeds 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?

The description is information-dense and well-structured with clear section headings (MODEL_DRIVEN, STRUCTURAL_ARBITRAGE, CONCENTRATED_LONGSHOT, RESPONSE TOP-LEVEL, TRADEABLE-EDGE KNOBS). However, it is overly verbose, including detailed internal parameters that are not needed for tool invocation (e.g., specific per-sport α values, exact gate relaxations from 'Run 8', funnel counters). While every segment serves a purpose, the sheer length risks burying the key usage instructions in implementation detail.

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 (9 parameters, no output schema), the description does a strong job of covering the response top-level structure, diagnostics for empty segments, and the caching behavior. It thoroughly explains what the caller will receive (edge_pp_net, kelly_fraction, liquidity, spread, diagnostics) and why certain segments may be empty. It falls just short of a 5 because it doesn't provide an explicit response schema or examples, relying on dense prose to convey the output shape.

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_description_coverage, the baseline is 3. The description does add some contextual value by explaining how knobs interact (e.g., 'min_liquidity / max_spread_pp drop opportunities where edge isn't realizable' and 'min_partition_leg_kelly filters partitions by best per-leg Kelly'), but most of this is already present in the schema parameter descriptions. The description leverages existing schema detail rather than compensating for missing coverage.

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

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

The description opens with a specific, action-oriented purpose: 'Scan top Polymarket markets and return opportunities where Pipeworx data disagrees with market price.' It further distinguishes the tool by detailing three distinct model families (model_driven, structural_arbitrage, concentrated_longshot) and the intended use case ('what should I bet on today'), making it clear this is a discovery/edge-finding tool, not a general market scraper.

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 clearly states when to use the tool ('agents discover opportunities without paging hundreds of markets') and provides concrete guidance on how to tune knobs (e.g., 'Set to 2 to require tight books', 'Set to 5000 to drop thin-book opportunities'). It also includes an implicit exclusion: Fed bets are surfaced separately and excluded from ranking due to data reliability concerns. However, it does not explicitly contrast with sibling tools like polymarket_arbitrage or polymarket_edge_tracker, so the guidance is good but not exhaustive.

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 well beyond the readOnlyHint annotation, disclosing the 60-day snapshot TTL, that snapshots are written on cache-miss, and that gaps in snapshot_dates indicate no scan occurred. It also explains that decay numbers are computed from daily closes of edge_pp_net, net of default slippage, adding critical context for interpreting results and reinforcing the read-only nature.

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

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

The description is well-structured with labeled sections for args, response, and limits, and every sentence conveys meaningful information. It is longer than strictly necessary (e.g., the illustrative phrase about nobody being willing to take a stale edge), but the complexity of the tool justifies the length, so 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?

Given that there is no output schema, the description fully compensates by detailing the response structure (tracked[], expired[], snapshot_dates[]) and key fields like first_seen, trend, and decay_pp_per_day. It also covers limitations such as TTL, data gaps, and the basis of decay calculations, making it highly complete for a read-only telemetry 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 provides comprehensive descriptions for both parameters (coverage 100%). The description adds no significant semantic detail beyond restating the defaults and 'snapshot family' concept, so it rests at the baseline of 3.

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

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

The description opens with a specific verb+resource scope: 'Edge persistence and decay telemetry built from daily polymarket_edges snapshots,' and explicitly states the question it answers ('how long has this edge existed and is it shrinking?'). This clearly distinguishes it from sibling tools like polymarket_edges by focusing on historical persistence rather than 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 implies its use case: evaluating edge age and decay for trade decisions, contrasting fresh vs old edges with the illustrative phrase 'a fresh wide edge and a 3-week-old wide edge are different trades.' However, it does not explicitly name alternative tools or provide when-not-to-use guidance, so it earns a 4 rather than 5.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description goes beyond these by detailing behavior: walks the order-book ladder, returns specific fields like top_of_book, vwap_fill_price, slippage_pp, and warns about 'forced_directional_risk' and 'partial basket fills convert an arb into an unhedged directional position.' 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 long but each sentence carries information: mode distinctions, return fields, risk warnings. It is front-loaded with the core purpose and structured with mode labels. It could be slightly more scannable, but the density is justified by the tool's complexity.

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

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

With no output schema, the description thoroughly enumerates return values for both modes (top_of_book, vwap_fill_price, slippage_pp, shares_filled, max_fillable_usd, verdict; theoretical_sum vs realizable_sum, capture_ratio, profit_usd, per-leg fill detail, thin_legs[], max_clean_notional_usd, forced_directional_risk). It also covers input constraints, defaults, and the risk scenario, making the tool fully self-contained.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds meaningful context: clarifies the REQUIRES one-of constraint (market or event), explains size_usd interpretation (max spend on buys vs target proceeds on sells; settlement notional in basket mode), and documents the default auto side selection. This goes beyond the schema's per-parameter descriptions, though some is redundant.

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: 'Realizable-vs-theoretical edge check against live CLOB order-book depth.' It clearly distinguishes two modes (single-market and basket) and explicitly references sibling tools (polymarket_arbitrage, polymarket_edges) in the usage guidance, making its unique role unmistakable.

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

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

Explicitly states when to use this tool: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500.' It also explains why (theoretical overround on thin books is not capturable, partial fills create directional risk) and differentiates single-market vs basket modes, including which parameter to pass.

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' readOnly/idempotent hints by explaining concrete behavioral edge cases: compatibility_warning triggers, temporal_alignment semantics, and skipped_cross_type/subtype counters. This level of detail tells the agent exactly when the tool's output is trustworthy and when it is not, providing immense value beyond the structured fields.

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, covering modes, output structure, and safety fields in dense prose. It could benefit from bullet points for readability, but the flow is logical and the content is appropriately sized for the tool's complexity.

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

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

With no output schema present, the description takes full responsibility for explaining the response structure, including leg-by-leg prices, top_spreads_pp, compatibility_warning, and temporal_alignment. It also covers both operation modes comprehensively, making it fully complete for a complex cross-venue 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 three parameters (100% coverage), so the baseline is 3. The description adds meaningful context by enumerating the exact pre-mapped topic shortcuts and clarifying that explicit tickers override the topic-mapped side, which is not obvious from the schema alone. This extra semantic layer justifies a 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?

The description opens with 'Cross-venue spread between Kalshi and Polymarket for the same resolving question,' which precisely identifies the tool's unique function. It further elaborates on two distinct modes (topic shortcuts vs. explicit tickers), making its purpose unmistakable and differentiating it from sibling tools like polymarket_arbitrage and 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?

The description gives clear guidance on when to use each mode and warns that 'most pre-mapped topics return compatibility_warning today; pre-mapped ≠ tradeable,' which sets expectations for real-world usage. However, it does not explicitly compare this tool with alternative sibling tools, so it stops short of being a 5.

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

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

Annotations already declare readOnlyHint and destructiveHint false, so the description adds value by disclosing the scoping behavior ('Scoped to your identifier') and the special behavior of omitting the key to list all keys. 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 only three sentences, front-loaded with the core action, and each sentence provides distinct value: the main operation, usage context, and scoping/related tools. No filler or 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?

For a simple one-parameter read-only tool with no output schema, the description covers behavior, use cases, scoping, and related tools. It does not specify the return format or behavior for missing keys, but that is a minor gap given the tool's simplicity.

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 has 100% coverage with a clear description of the key parameter. The description adds some examples of key values (ticker, address, notes) but does not add syntax or format details beyond the schema, so baseline 3 applies.

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

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

The description opens with a specific action: 'Retrieve a value previously saved via remember, or list all saved keys.' This clearly distinguishes recall from sibling tools (remember and forget) by naming the operation and the resource.

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 states when to use the tool: 'Use to look up context the agent stored earlier' and gives concrete examples (target ticker, address, research notes). It also names alternatives: 'Pair with remember to save, forget to delete,' providing clear usage context.

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 readOnly/idempotent, but the description adds important behavioral details: each event carries source, citation_uri, and raw payload; mark_read:true mutates read state to affect subsequent calls. This goes beyond annotations and reveals the side-effect of the mark_read parameter, which is critical for correct invocation.

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 with no fluff. The first sentence states the core purpose, the second details return fields and filters, the third covers mark_read and an alternative access endpoint. Every sentence carries load and the structure is front-loaded.

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

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

With no output schema, the description compensates by listing return content (source, citation_uri, raw payload). It covers all key usage patterns: filtering, limits, mark_read semantics, unread_only is in schema, and even provides the external feed URL. For a read/poll tool with good annotations, this is 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 has 100% coverage, so the baseline is 3. The description adds practical meaning beyond schema: it gives a concrete type example ('sec_8k'), clarifies the 'since' format (ISO timestamp), and explains the behavioral effect of mark_read. It does not repeat schema verbatim, only enhancing it.

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 'Pull' and the resource 'fired events from your subscription feed', making it obvious what the tool does. It distinguishes itself from siblings like list_subscriptions and recent_changes by focusing on alert events and their payload details.

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 concrete usage context: filtering by type and since, using mark_read for incremental polling, and notes that polling works fine. It doesn't explicitly contrast with alternative tools, but the context is sufficiently clear for an agent to know when to use it.

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

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

Beyond the read-only/idempotent annotations, the description details the fan-out to SEC EDGAR, GDELT→GNews fallback, and USPTO with a soft-fail note, plus the return structure (changes[], total_changes, citation URIs). This adds substantial behavioral 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 somewhat long, but every sentence carries functional value—examples, source behavior, fallback logic, and alternative tool. The front-loaded examples effectively convey intent without being verbose.

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 having no output schema, the description explains the return format (changes[] grouped by source, total_changes, citation URIs) and covers source-specific behaviors and limitations. The alternative tool reference completes the context.

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

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

Schema coverage is 100%, but the description adds helpful guidance: `since` accepts ISO or relative shorthand with examples, and recommends '30d' or '1m' for typical monitoring. It also clarifies `value` as ticker or CIK, enriching 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 clearly identifies the tool as a change feed for a company over a time window, with multiple natural-language examples. It explicitly contrasts with entity_profile (static profile) to distinguish from a key sibling 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?

The description gives concrete usage contexts ('What's new with X', 'latest on Y') and explicitly directs users to entity_profile for static profile needs, providing a clear alternative. It also specifies that the tool makes a single parallel call, implying efficiency.

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 annotations, the description adds critical behavioral context: 'Stored as a key-value pair scoped by your identifier' and 'Authenticated users get persistent memory; anonymous sessions retain memory for 24 hours.' This explains scope and persistence semantics not available from annotations. It does not cover duplicate-key overwrite behavior, but the idempotentHint already implies repeat-call safety.

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 sentences, each adding distinct value: purpose, when to use, storage scope, and companion tools. No filler or redundancy; the most important information is front-loaded.

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

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

For a simple two-parameter tool with no output schema, the description covers purpose, usage triggers, persistence rules, and related tools. No needed context is missing, and the lack of a return-value description is acceptable for such a straightforward store operation.

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

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

Schema description coverage is 100%, with both 'key' and 'value' fully described in the input schema. The description says 'Stored as a key-value pair,' which matches the schema but adds no new meaning beyond what the parameter descriptions already provide. Thus the 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 opens with a precise action: 'Save data the agent will need to reuse later,' and specifies the resource as a key-value pair scoped by identifier. It clearly distinguishes from siblings like 'recall' and 'forget' by stating 'Pair with recall to retrieve later, forget to delete.'

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 when-to-use guidance: 'Use when you discover something worth carrying forward (a resolved ticker, a target address, a user preference, a research subject)'. It also names complementary alternatives ('Pair with recall to retrieve later, forget to delete'), making the usage context 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 indicate read-only, idempotent, open-world behavior, so the description adds value by disclosing that each call cascades through multiple lookup endpoints internally, effectively replacing 2-3 manual lookups. This is beyond annotation coverage and gives insight into performance and complexity. 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 a single, dense paragraph that starts with concrete user phrases, states the core purpose, then details supported types and return values. While it is a bit long, every sentence provides useful information, and the structure flows logically from usage to technical details.

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 moderate complexity and absence of an output schema, the description fully covers input variations, output contents, and internal behavior. Both 'company' and 'drug' cases are explained, including what identifiers are returned and the citation URIs. The description is complete enough for an agent to use it correctly without further documentation.

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 basic descriptions for both parameters. The tool description significantly enriches parameter semantics: for 'type', it details what each enum value returns (ticker+CIK+company_name vs. RxCUI+ingredient+brand) and includes citation URIs. For 'value', it explains accepted formats and auto-disambiguation for company names. This adds substantial 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 function: resolving names to canonical identifiers (e.g., tickers, CIKs, RxCUIs). It provides concrete example queries and distinguishes itself by emphasizing that other tools require these IDs as input. This is a specific verb+resource with clear scope.

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

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

It explicitly says 'Use FIRST whenever you have a name but need an ID,' providing a clear when-to-use directive. It also explains the two supported entity types and their input formats. It does not explicitly list when-not-to-use or alternative tools, but the usage context is 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 declare readOnlyHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds meaningful behavioral context: that it probes with ai_visibility_check, ranks by score, and returns a structured list with score, confidence, and signal density. This goes beyond the annotations without contradicting them.

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

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

The description is four sentences, front-loaded with the main purpose, and every sentence adds value: mechanism, ranking behavior, use case, and output summary. No fluff or repetition.

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

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

Given the tool has no output schema, the description appropriately explains the return format (ranked list with score, confidence, signal density). It also covers the competitive audit use case, internal workflow, and parameter semantics sufficiently. The schema covers parameters fully, so the description completes the picture.

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 extra meaning by specifying that the first entity is treated as the 'subject' for narrative while the rest are competitors, which is not in the schema. This helps the agent understand the semantic role of the entities 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 uses a specific verb ('Compare') and resource ('AI visibility across multiple entities side-by-side'), clearly distinguishing it from the single-entity sibling ai_visibility_check. It also states it ranks and surfaces most/least recognized, fully conveying the tool's core function.

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 positions the tool for competitive AI-marketing audits with an illustrative question, making the use case clear. It doesn't explicitly name alternatives or exclusions, but the comparison to ai_visibility_check is implied through the description of probing each entity, giving adequate situational 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?

The description discloses multiple behavioral aspects beyond the annotations: it returns a structured summary block, degrades gracefully on partial failures, notes that bundlephobia's first measurement can take 5-30s, and that sources_failed will list timeouts. This adds valuable operational context not present in the readOnly/openWorld/idempotent 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 front-loaded with the primary purpose and densely packed with essential information: sources, output fields, usage triggers, ecosystem limitation, and failure behavior. Every sentence contributes value, though a slight trim for readability would make it tighter.

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 fully covers the tool's functionality, output format, edge cases (timeouts, partial failures), ecosystem restrictions, and alternatives. Since there is no output schema, the description successfully carries the responsibility of explaining return values and behavior.

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 schema already provides 100% coverage for both parameters, including package name details and version defaulting. The description adds minimal additional parameter semantics beyond confirming the NPM-ecosystem scope, so the 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's purpose with a specific verb and resource: a composite 'should I add this npm package to my project' check that fans out across deps.dev and bundlephobia. It distinguishes itself from sibling tools by describing a unique, specialized function not present in any sibling names.

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 describes when to use the tool ('Use whenever an agent asks...') and also provides exclusions for non-NPM ecosystems ('PyPI / Maven / Cargo / Go fall under deps.dev:version directly'). This clear guidance helps agents choose the correct tool.

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 read-only/idempotent annotations, the description discloses concrete behavior: character offsets for verification, BGE-base-en embeddings with cosine similarity over 500-char overlapping windows, and a 200K char cap with truncation flagging. This adds substantive context about outputs and limitations.

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?

Every sentence earns its place: purpose is front-loaded, use case and pairing are explained, and technical constraints are packed into a tight final sentence. The description is dense but not bloated, with no filler.

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

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

Given no output schema, the description compensates by explaining return values (top-N passages with character offsets and similarity scores), truncation behavior, and the pairing with ask_pipeworx_grounded. It covers inputs, outputs, and usage context comprehensively for a search 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 the baseline is 3. The description adds meaning by clarifying the 'text' parameter as 'the text you already pulled' and provides concrete examples (SEC 10-K body, article), enriching the schema's terse 'document text' description. The query parameter is also given a natural-language framing in context.

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

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

The description opens with 'Semantic search INSIDE a fetched record,' which clearly states the verb, resource, and scope. It distinguishes itself from siblings by emphasizing it searches within pre-fetched text rather than across the whole corpus, and explicitly contrasts with 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?

Explicit when-to-use guidance: 'Use when the record is too big to cram into the prompt' and 'search_within saves context.' It also names a complementary tool ('Pairs with ask_pipeworx_grounded') and states the prerequisite ('Pass the text you already pulled'), providing clear context for choosing this tool over 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?

Annotations already declare the tool safe (readOnly, idempotent, non-destructive), and the description adds useful details about the optional limit and the specific fields returned. These are behavioral insights beyond the annotations, and there is 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 a single, efficiently structured sentence that begins with the verb and resource. It contains no filler or redundant repetition of the title or schema.

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 (one optional parameter, no required parameters), existing output schema, and rich annotations, the description covers all essential aspects: purpose, scope, optional limit, and return content. No critical information is missing.

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

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

The schema has only one parameter with 0% description coverage, but the description clarifies that 'limit' is optional and caps the number of results ('up to optional limit'). This adds meaning beyond the bare parameter name and partially compensates for the missing schema 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 uses the specific verb 'List' with the resource 'species that appear in Studio Ghibli films' and enumerates the returned fields, clearly establishing the tool's purpose. It distinguishes itself from the sibling tool 'species_one' by implying a list operation rather than a single-entity 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 phrase 'List species...' provides clear context for when to use this tool, and 'up to optional limit' further defines the usage shape. It does not explicitly name alternatives or exclusions, but the intended use case is unambiguous.

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, so the safety and idempotency profile is well-covered. The description adds no extra behavioral context, such as not-found behavior, response format, or rate limits, but with such strong annotations, the description need not repeat them; it simply lacks additional transparency 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?

The description is a single four-word sentence with no fluff, making it very concise and easy to parse. It is arguably under-specified for a complete tool description, but for such a simple tool with strong annotations and an output schema, this brevity is acceptable and no words are wasted.

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 tool is very simple with one parameter and an output schema, so the description need not explain return values. However, it lacks any usage guidance or behavioral nuances, and given the low schema coverage, the overall description is minimally adequate but not thorough for an agent that has no other context.

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

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

The schema has 0% description coverage, and the only param 'id' is a bare string with an example UUID. The description 'by id' merely restates the parameter name and does not explain the expected format, whether it is a UUID, or any constraints. Since schema coverage is low, the description should compensate but does not.

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

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

The description 'Single species by id.' clearly identifies the resource and retrieval scope, distinguishing it from the plural sibling tool 'species' for listing all species. While it lacks an explicit verb like 'retrieve' or 'get', the phrase 'by id' strongly implies a fetch operation for a single entity, making the purpose clear enough.

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 no guidance on when to use this tool versus alternatives such as the sibling 'species' tool for listing. There is no mention of prerequisites, exclusions, or scenarios where this tool is preferred, leaving the agent to infer usage solely from the name and context.

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 states 'Create a proactive monitoring subscription' and 'Returns the new subscription id,' implying each call creates a distinct subscription. This contradicts the annotation idempotentHint=true, which suggests retries are safe and side-effect-free. While the description does disclose auth requirements and delivery caps, the contradiction forces a score of 1.

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 each clause earns its place, covering purpose, auth, type examples, delivery, and return value. It is a single paragraph that is somewhat long but justified by the tool's complexity. Better formatting with bullets could improve scannability.

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 purpose, auth, type-specific params, delivery channels, and return value. However, it omits idempotency behavior contrary to the annotation, and doesn't mention the webhook option (though schema covers it). Overall quite complete for a multi-type subscription 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 the description adds valuable concrete examples for each subscription type (e.g., sec_8k item codes, polymarket_edge topic, fred_series series_id) and clarifies delivery behavior (feed always on, SMS cap, phone verification). This goes beyond the generic 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 the verb and resource: 'Create a proactive monitoring subscription to a live-data event stream.' It distinguishes from siblings like list_subscriptions and unsubscribe by emphasizing creation and returning a new subscription id.

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 clear context: requires an OAuth account, specifies supported types with examples, and explains delivery channels. It implies when to use (setting up ongoing monitoring) and mentions pulling via recent_alerts, but does not explicitly contrast with sibling alternatives like list_subscriptions or unsubscribe.

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, and idempotentHint. The description adds meaningful context: it returns category-bucketed example questions 'drawn from the live catalog', and explains the optional `topic` filtering behavior. This goes beyond the annotations by describing the result structure and dynamic nature.

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

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

The description is a single dense paragraph containing all necessary information, but it lacks visual structure. While no sentence is wasted, the long stream of examples and clauses could be more effectively organized with bullets or breaks for readability.

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 meta-tool with no output schema, the description fully explains what the tool returns (category-bucketed examples with exact tool and argument shapes), how to invoke it (no args or topic), and when to use it (onboarding). It is complete for the tool's purpose and complexity.

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

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

Schema coverage is 100% (one optional `topic` parameter with description). The description adds value by providing concrete example values ('finance', 'pharma', 'betting') and clarifying that omitting the parameter yields a cross-category spread, which reinforces the schema's meaning.

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: it's the onboarding entry point for an agent that wants to know what questions Pipeworx can answer. It specifies the output (category-bucketed example questions with tool and argument shapes) and distinguishes itself from sibling tools by framing itself as a meta-tool for discovery.

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

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

The description explicitly says 'Use this FIRST when you do not yet know what Pipeworx can do for you' and explains how to call it with or without a topic. It stops short of listing when-not-to-use scenarios or naming direct alternatives, but the 'FIRST' instruction provides strong usage 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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description adds key behavioral details: 'The row is deactivated (not deleted) so its historical events stay available via recent_alerts.' It also discloses the ownership enforcement. This provides useful context that annotations don't cover.

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 filler. The first sentence front-loads the action, and the second adds necessary ownership and side-effect details. 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 one-parameter tool with no output schema, the description covers the core action, ownership constraint, and the important non-destructive side effect. It is complete enough for an agent to select and 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 description coverage is 100%: the parameter 'id' is fully described as 'Subscription id (uuid) returned by subscribe.' The description adds little beyond what the schema already provides, matching the baseline for high coverage.

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

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

The description clearly states the action: 'Cancel a subscription by id.' The verb 'Cancel' plus resource 'subscription' is specific, and the title 'Unsubscribe from Alerts' clarifies the domain. It 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?

The description gives clear context: ownership is enforced, so you can only cancel your own subscriptions. It implies the tool is for ending a subscription, and even mentions the alternative recent_alerts for historical events. However, it doesn't explicitly state when not to use this tool or name a direct alternative for cancellation.

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 annotations (read-only, open-world, idempotent, non-destructive), the description reveals detailed internal behavior: the structured fast path for company-financial claims, the automatic fall-through to a grounded pipeline for other claims, the exact percent-delta math, the return of verdict types with citations, and the consolidation of multiple sequential calls. This gives the agent a clear understanding of what happens under the hood.

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 trigger phrases and uses a logical structure: what the tool does, when to use it, how it routes, what it returns, and its efficiency. While it is somewhat long, every sentence serves a purpose and avoids redundancy. A slightly tighter focus would earn a 5.

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 (two pipelines, multiple verdict types, tolerance handling), the description is remarkably complete. It covers the full processing flow, return values (verdict, value with citation, reasoning), and the specific behaviors like the percent-delta math. Since there is no output schema, the description adequately explains the return structure.

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 provides 100% coverage, fully describing both parameters (`claim` with examples, `tolerance_pct` with range/default/behavior). The description does not add additional parameter-level meaning beyond what the schema states, so the baseline of 3 applies.

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

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

The description clearly defines the tool as natural-language claim verification against authoritative sources, with explicit trigger phrases and examples. It distinguishes itself from siblings by specifying the two distinct pipelines (structured SEC EDGAR for financial claims, grounded pipeline for all others) and the consolidated nature of the tool, replacing 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?

The description explicitly states when to use the tool: 'Use whenever the agent needs to check whether something a user said is factually correct.' It also differentiates between financial and non-financial claim handling. However, it does not explicitly mention when not to use it or name alternative tools, which would make it a 5.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds no behavioral details such as missing-ID behavior, authentication needs, or rate limits. It simply restates the 'by id' retrieval pattern, which is already evident from the schema.

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

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

The description is a single, short, front-loaded sentence with no filler. It conveys the essential purpose in four words, making it appropriately concise for a simple getter tool.

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 (one required parameter, no nested objects), rich annotations, and presence of an output schema, the description is nearly sufficient. It lacks explicit notes about not-found behavior, but for an idempotent read with an output schema, this is acceptable. The description covers the core semantics 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?

With 0% schema description coverage, the description should compensate by explaining the id parameter. 'Single vehicle by id' confirms id is the lookup key, but does not detail format, constraints, or semantics beyond the schema's type 'string' and example UUID. The description adds minimal value over 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 'Single vehicle by id' clearly identifies the tool's function as retrieving one vehicle based on an ID, which distinguishes it from the sibling 'vehicles' tool that presumably lists multiple. While no explicit verb like 'get' is used, the intent is unmistakable and the resource is specified.

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 when a single vehicle ID is known, but does not explicitly state when to prefer this over the plural 'vehicles' tool or other sibling list tools. No alternatives or exclusionary conditions are mentioned, making the guidance solely implicit.

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

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

Annotations already establish the tool as read-only, idempotent, and non-destructive. The description adds behavioral context about the optional limit and the fields returned, which is not specified in the annotations or schema. It does not address edge cases like default limits or empty results, but is adequate.

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

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

The description is a single, well-structured sentence that front-loads the primary purpose and includes the parameter in a concise parenthetical. No extraneous information is present.

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 (one optional parameter, output schema present, and strong annotations), the description sufficiently covers the tool's purpose, return fields, and parameter semantics. It is complete for an agent to select and invoke this tool appropriately.

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 schema's only parameter, 'limit', lacks a description. The description compensates by explaining the parameter's role as an optional cap on the number of results, which is the key semantic information. It doesn't specify validation rules but is sufficient for a single optional 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 action ('List'), the resource ('vehicles'), and the scope ('from Studio Ghibli films'). It enumerates the returned fields, distinguishing it from the singular 'vehicle' sibling tool by implying a plural listing.

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 its use case as a list endpoint and mentions the optional limit, but it does not explicitly contrast with the singular 'vehicle' tool or state when to prefer one over the other. There is no explicit when/when-not guidance.

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