Worldbank Climate

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds value by explaining that Workers AI is free while Anthropic incurs costs via a BYO key, and that the tool returns per-model scores, confidence, signals, and raw responses. It does not contradict annotations and provides useful behavioral context beyond what annotations convey.

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

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

The description is concise, using a single paragraph that covers purpose, default behavior, optional parameters, cost implications, output structure, and use cases. Every sentence is informative; no fluff. The most critical information (what it does and output) 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?

Given no output schema, the description adequately describes return values (per-model score, confidence, signals, raw_response, combined view). It explains both inputs and outputs clearly. The tool has moderate complexity (4 parameters, 1 required), and the description covers all aspects: entity, model selection, API key, context. Use cases are provided, making it complete for agent selection.

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 meaning by clarifying the default behavior (omit models for just workers-ai), the purpose of `_apiKey` (only needed if anthropic is in models), and the role of `context` for disambiguation. This goes beyond the schema's parameter descriptions.

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

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

The description clearly states the tool's purpose: probing LLMs for knowledge about entities and scoring visibility. It specifies the default model and optional Anthropic probing with BYO key. The verb 'probe' and resource 'LLMs' are specific, and the output (score 0-100 per model) is well-defined. It distinguishes from siblings like 'scan_competitor_ai_presence' by focusing on multi-model scoring.

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

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

The description provides clear use cases: AI-marketing audits, pre-launch brand checks, competitive monitoring. It explains when to use the default vs. Anthropic model. However, it does not explicitly mention when not to use this tool or differentiate from closely related sibling tools (e.g., 'scan_competitor_ai_presence'), which would be helpful.

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, establishing a safe read-only profile. The description adds valuable context about internal routing (5,462 tools), stable citation URIs, speed ('one fast call'), and tier compatibility, which 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?

Although lengthy, every sentence serves a purpose: it front-loads the strongest guidance ('PREFER OVER WEB SEARCH'), defines scope, provides examples, and explicitly differentiates from siblings. The structure is logical and easy to scan, making the length justified for a default routing 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?

For a tool with no output schema, the description comprehensively covers what it does, when to use it, when not to use it, examples, and behavior (returns structured answer with citations). It even addresses breaking-news use cases and mentions fallback alternatives, making it fully 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 description coverage is 100%, with the 'question' parameter fully documented and aliases (q, text, input, query, prompt) listed. The description doesn't add parameter-level details beyond the schema, but it does provide a broad set of example question categories and phrasing ('what is', 'look up') that clarify the expected input format, earning a baseline-3 score.

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 a router that sends questions to one of 5,462 tools across 1,419 verified sources and returns structured answers with pipeworx:// citation URIs. It explicitly distinguishes itself from siblings 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 is explicit about when to use this tool: 'PREFER OVER WEB SEARCH', 'START HERE for most questions', and lists trigger phrases like 'what is', 'look up', 'find'. It also gives clear guidance on when to use alternatives ('for a hallucination-resistant single answer... use ask_pipeworx_grounded; for a broad/multi-part question... use deep_research').

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 annotations by disclosing that candidate routing improvements may be enabled live, that no candidate is currently active (matching ask_pipeworx exactly), and that it 'Falls back to nothing — this IS a full working router'. This reveals the experimental evaluation nature and potential behavior changes, which is valuable beyond the readOnly/idempotent hints.

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 compact four-sentence paragraph that efficiently covers identity, current state, usage, and operational caveat without redundant filler. It is slightly denser than necessary but each sentence adds distinct information, earning a solid score.

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

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

Given the tool's complexity (a universal router with only a question parameter) and the presence of annotations, the description covers the essential purpose, behavior, and usage guidance. It mentions the response shape matches ask_pipeworx, which is sufficient context given the sibling tools, but could have explicitly stated the return format for full self-containment.

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 schema coverage at 100%, each parameter is already described (e.g., 'Alias for question'). The tool description adds no additional parameter semantics, so the value remains at the baseline 3 for high schema coverage, as the schema fully documents the aliases and the question 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 it is a 'Beta version of ask_pipeworx: identical universal router' with the same tools, arguments, and response shape, while differentiating it from the stable ask_pipeworx and ask_pipeworx_grounded siblings by framing it as the experimental edge. The purpose—routing natural-language questions across many tools—is evident and specific.

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 it exactly like ask_pipeworx when you want the newest routing' and mentions results are compared against the stable router, providing concrete usage context. It does not explicitly list when not to use it, but the implication that stable routing is available via ask_pipeworx is clear.

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

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

The description goes well beyond the annotations (readOnlyHint, idempotentHint, etc.) by detailing the extraction mechanism (only what tool result contains), explicit refusal reasons, and the return structure. It also discloses the additional LLM call overhead. This adds rich behavioral context 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 front-loaded with the key purpose, then provides structured details (routing, extraction, return/refusal, usage guidance, cost tradeoff). Every sentence adds value and the length is justifiable given the tool's complexity. It is well-organized and free of fluff.

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

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

Given the tool's complexity and no output schema, the description covers all critical aspects: routing, extraction guarantees, refusal modes, return fields, and usage scenarios. It is complete for an agent to know what results to expect and when to 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 description coverage is 100%, so the baseline is 3. The description does not add parameter-specific details beyond the schema, but it does mention the question is in natural language and the tool handles high-stakes reads. No additional semantics are needed, so 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 is a 'hallucination-resistant answer mode for high-stakes reads', specifying a distinct purpose from siblings. It explicitly differentiates from ask_pipeworx by the extraction and refusal behavior, and provides a concrete use case ('financial verdicts, legal claims, medical lookups'). This is a specific verb+resource with clear scope and sibling differentiation.

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 ('whenever an answer will be quoted, cited, or acted on... must not invent facts') and when not to use it ('prefer ask_pipeworx for casual lookups'). It also names the alternative tool and mentions the extra LLM call cost, providing clear context and exclusions.

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

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint=true, destructiveHint=false. The description goes far beyond by detailing low-confidence resolution short-circuiting, closed market handling, wide spread tradeability flag, resolution-rule risk (cancellation_rule), parent event extraction, news fallback fields, and the resolver contract with market_match_confidence. No contradictions.

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

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

The description is long but well-structured with section headers (CLASSIFIERS, FAN-OUT EXAMPLES, RESPONSE SHAPES, etc.). Every sentence adds value given the tool's complexity. Could be slightly trimmed, but the structure aids readability and information density.

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 details response shapes (result.market, result.analysis, result.evidence), resolver contract, parent event extractor, news fields, and safety/edge cases. It covers all necessary context for an AI agent to use the tool correctly, including what to inspect before trusting analysis.

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?

Input schema has 100% coverage; every parameter has a description. The description adds meaning: market parameter accepts slug, URL, or question text; depth parameter has quick/thorough with defaults; include_raw explains when to use false vs true. Examples in schema and description enhance understanding.

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

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

The description clearly states it researches a Polymarket bet by pulling relevant Pipeworx data. It specifies the action (research), the resource (Polymarket bet), and the method (resolves market, classifies, fans out). It distinguishes from sibling tools like polymarket_edges, polymarket_arbitrage, etc., which focus on different aspects.

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 for "should I bet on X", "what does the data say about Y", or "is there edge in Z"'. It provides usage examples and explains when the tool returns blocking statuses (low_confidence_match, market_closed_or_inactive). It does not directly compare to all siblings but the specific use cases are 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?

In addition to the annotations (readOnly, idempotent, etc.), the description discloses key behaviors: data sources for company (SEC EDGAR/XBRL with off-calendar handling) and drug (FAERS, FDA, trials), sorting by primary metric, and return of citation URIs. No contradictions with annotations.

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

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

The description is one dense paragraph, but every sentence adds value. It is front-loaded with example phrases and usage guidance. While concise, a slight restructuring could improve readability, but no unnecessary 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?

Given the tool's complexity (two entity types, multiple data sources, no output schema), the description is comprehensive. It covers data sources, edge cases (off-calendar fiscal years), sorting behavior, output format, and efficiency benefits. It fully compensates for the lack of an output schema.

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

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

Schema coverage is 100% with descriptions for both parameters. The description adds significant semantic meaning: explains that 'company' type returns 10-K financial metrics and 'drug' type returns adverse-event counts, approval counts, and trial data. This goes well beyond the schema's enum labels.

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 comparison of 2–5 companies or drugs in a single parallel call. It uses specific action verbs ('compare', 'rank') and explicitly distinguishes from sequential single-entity lookups, which are common among siblings like 'entity_profile'.

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 'ALWAYS PREFER over sequential single-pack lookups when comparing entities', providing clear guidance on when to use this tool. It also quantifies efficiency by stating it replaces 8–15 sequential lookups, but does not explicitly list scenarios where it should not be used.

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

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

Beyond annotation flags (readOnly, openWorld, idempotent), the description discloses account requirements, latency expectations (15-60s, thorough up to ~90s), the gap[] behavior (never invented), contradictions[] for standard/thorough, semantic excerpting of large records, and a guarantee that citation_uris are fetchable. This goes well beyond what annotations alone 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?

Though a single dense paragraph, every sentence is functional: the account requirement and alternative are front-loaded, followed by the core purpose, use cases, exclusions, output structure, depth behaviors, and latency. There is no filler or redundant restating of the name/title; it is appropriately sized for a complex 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?

With no output schema, the description provides a thorough explanation of the return value: a findings packet with 'verbatim evidence + confidence + source + fetched_at + a stable pipeworx:// citation per finding', plus gaps[], contradictions[], hop field, and citation_uri. It covers auth, latency, iteration, data scope, and exclusions, making it fully contextual 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 coverage for both parameters is 100%, with a detailed depth description already in the schema. The tool description adds the meaningful constraint that depth:'thorough' requires a paid plan, plus explains the 'second-hop iteration' behavior in context. While the schema covers most parameter details, the paid-tier requirement and higher-level iteration semantics provide extra value not present in the schema.

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

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

The description is highly specific: 'Grounded multi-source research across Pipeworx's 1419 STRUCTURED data sources' with the verb 'research', a defined resource, and an explicit contrast to 'NOT open-web search'. It clearly distinguishes itself from siblings like ask_pipeworx by stating it decomposes questions into facets and routes to 5,462 tools in parallel.

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

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

Provides explicit guidance: 'Best for broad/multi-part questions over structured data', and directly names alternatives: 'For a single lookup use ask_pipeworx', 'For BREAKING or colloquial CURRENT-NEWS ... prefer ask_pipeworx'. Also mentions account/tier restrictions and tells unsigned-in users to use ask_pipeworx instead, offering both when-to-use and when-not-to use.

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

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

Annotations already provide readOnlyHint and destructiveHint. Description adds that it returns top-N tools with full schemas ready to call, which is useful context without contradicting annotations.

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

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

Front-loaded with purpose and usage, though the list of domains makes it slightly lengthy. Overall efficient and well-structured.

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

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

Despite no output schema, description fully explains what is returned (names, descriptions, input schemas). Helps agent understand complete 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?

Schema coverage is 100%, but description adds value by explaining alias parameters and the limit parameter, as well as the behavior of returning top-N results.

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

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

The description clearly states the tool finds tools by describing data or task, lists many domains, and distinguishes itself from siblings as the first tool to call for browsing.

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

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

Explicitly says 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' Provides 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds context about fanning out across multiple sources, patent soft-fail until May 2025, and return details. No contradictions.

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

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

Description is front-loaded with purpose and examples, then details sources and return fields. Somewhat dense but every sentence adds value. Could be slightly more concise but still effective.

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

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

Despite no output schema, description thoroughly explains what is returned (cik, company_name, filings with URIs, fundamentals, patents status, news, LEI) and covers limitations (patents sunset, name not supported). Complete for a complex tool.

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

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

Schema coverage is 100% with both parameters described. Description reinforces meaning and adds critical constraint 'Names not supported — use resolve_entity first,' going beyond schema.

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

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

The description clearly states the tool's purpose: 'full cross-source profile of a US public company in ONE parallel call.' It provides multiple example queries and distinguishes from sibling tools that would require chaining multiple calls.

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

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

Explicit when-to-use guidance: 'ALWAYS PREFER over chaining single-pack lookups when the user asks for a holistic view.' Also specifies when not to use: 'names not supported (use resolve_entity first if you only have a name).'

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

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

Annotations provide destructiveHint and idempotentHint. Description adds context about why to delete but doesn't disclose behavior for non-existent keys or return value.

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

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

Two concise sentences: first states purpose, second gives usage guidance. No redundant or unnecessary text.

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?

Simple tool with one param and no output schema. Description adequately explains use cases and provides context. Could mention permanence of deletion, but sufficient overall.

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

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

Schema covers 100% with parameter 'key' described as 'Memory key to delete'. Description adds no extra meaning beyond schema.

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

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

Clear verb 'delete' and resource 'memory by key'. Distinguishes from sibling tools 'remember' and 'recall'.

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

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

Explicitly states when to use: stale context, task done, clear sensitive data. Mentions pairing with remember and recall, but lacks explicit when-not-to-use.

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

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

Annotations already declare read-only, idempotent, non-destructive behavior. The description adds context on fetching the page, extracting title/description/key links, and emitting standard markdown format. 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?

Four sentences: first states main purpose, second explains process, third describes output format, fourth lists use cases. No wasted words, front-loaded with key information.

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

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

Despite no output schema, the description adequately explains the output (single text blob in llms.txt format). Together with annotations (read-only, etc.), it provides sufficient context for agent correct invocation.

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

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

Schema coverage is 100% with clear parameter descriptions. The tool description does not repeat or add to parameter details, but it implicitly relates to the 'url' and 'max_links' parameters. 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 it generates a production-ready llms.txt file for any URL, specifying the exact output and its use for AI crawler indexing. It distinguishes itself from sibling tools like 'ai_visibility_check' and 'scan_competitor_ai_presence' by focusing on file generation rather than analysis or checks.

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

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

Explicit use cases are provided: getting a client's site indexed, drafting for own projects, auditing competitors. However, it does not offer explicit when-not-to-use guidance or compare directly with siblings.

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

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

Beyond annotations indicating readOnly and non-destructive behavior, the description reveals key behavioral traits: automatic indicator code assembly, return format (ISO3 keys, startYear-07), and failed API testing for era5/cru collections. This adds substantial value.

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

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

The description is front-loaded with purpose and includes detailed worked examples. While somewhat long, the examples are verified and earn their place. Slight room for brevity, but well-structured.

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

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

Given 8 parameters, no output schema, and no nested objects, the description provides comprehensive coverage: default values, return format, collection caveats, and fallback mechanism. It leaves little ambiguity for correct invocation.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds value by explaining composite indicator code construction, parameter defaults, and warnings (e.g., collection preference). This elevates the score above 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 explicitly states the tool retrieves World Bank CCKP climate data, listing data types (historical observations, projections), variables (temperature, precipitation), and the automatic assembly of indicator codes. It is specific and distinguishes from unrelated 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 includes worked examples demonstrating typical use cases and explains when to use the indicator_code fallback. It does not explicitly state when not to use the tool, but given no direct siblings for climate data, this is a minor gap.

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

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

Discloses that it takes no arguments and returns a static reference object. Annotations already indicate read-only, open-world, idempotent, non-destructive, and description adds value by detailing return content.

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

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

Description repeats 'Takes no arguments' and similar phrases twice. Could be more concise 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?

No output schema, but description fully explains the components of the returned object, making it complete for a reference 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?

No parameters; schema coverage 100%. Baseline 4 is appropriate as description adds context about the return object's contents beyond the empty schema.

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

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

The description clearly states it returns a static reference object documenting CCKP indicator-code components, listing specific elements. It distinguishes from sibling get_climate_data by indicating it should be called first.

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

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

Explicitly instructs to call before get_climate_data to choose valid parameter combinations, providing clear when-to-use guidance.

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

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

Annotations already declare readOnlyHint and idempotentHint. The description adds specific return field details (id, type, params, timestamps, fire_count) and implies default filtering to active subscriptions, going beyond the annotations.

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

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

Two sentences, front-loaded with functionality and return fields, then usage guidance. No redundant information.

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

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

For a simple tool with one optional parameter and no output schema, the description covers purpose, usage, and return fields adequately. It could mention pagination or limits, but these are not required 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?

Schema coverage is 100% and the parameter is well-described in the schema. The description does not add new semantic detail beyond stating 'active subscriptions,' 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 states the tool lists the caller's active subscriptions and specifies return fields. While it distinguishes from sibling subscribe/unsubscribe by context, it lacks an explicit differentiation statement, so it's not a perfect 5.

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 advises using this tool to review subscriptions before adding more or to find an id to cancel, providing clear context for when to invoke it. It doesn't mention alternatives or when not to use, but the sibling tools are obvious complements.

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 important behavioral traits beyond the annotations, such as rate-limiting ('Rate-limited to 5 per identifier per day'), no quota impact ('doesn't count against your tool-call quota'), and processing cadence ('team reads digests daily'). It also warns against pasting the end-user's prompt, adding context not present in the schema. No contradiction with the annotations exists.

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

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

The description is dense but every sentence serves a purpose: it states the tool's function, enumerates use cases, provides exclusions, gives formatting guidance, and notes rate limits. It is front-loaded with the most critical information and avoids redundancy, making it both thorough and efficient.

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

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

For a feedback tool with nested context, an enum parameter, and no output schema, the description covers all necessary ground: what to report, when to use it, what not to do, and behavioral consequences. It fully equips an agent to decide when and how 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?

The input schema already provides thorough descriptions for all three parameters (100% coverage), including enum meanings and field constraints. The description adds value by instructing to 'Describe the issue in terms of Pipeworx tools/packs — don't paste the end-user's prompt,' which clarifies the expected content beyond the schema's generic 'plain text' guidance.

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 what the tool does with a specific verb and resource: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It clearly distinguishes this feedback tool from any sibling tool by specifying it's for Pipeworx-only issues, making its 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 gives explicit when-to-use guidance: 'Use when a tool returns wrong/stale data (bug), when a tool you wish existed isn't in the catalog (feature/data_gap), or when something worked surprisingly well (praise).' It also provides clear exclusions: 'if the tool came from a different MCP server in your client... file it with that server instead,' naming the alternative action.

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 context beyond annotations by revealing the data source (CF analytics-engine), privacy (no PII), and caching behavior (5min-1h). Annotations already declare safety traits (readOnly, openWorld, idempotent, non-destructive), and description aligns without contradiction.

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

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

The description is three sentences with no wasted words. It leads with the core purpose, then lists use cases, then adds technical detail. Efficient and well-structured.

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

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

Given the single parameter with full schema coverage, strong annotations, and no output schema needed, the description provides complete context: purpose, use cases, source, caching, and data types. Nothing essential is missing.

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

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

The schema covers 100% of parameters (just 'window') with enum and description. The description does not add new parameter semantics beyond what the schema provides, so 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 returns top tools, top packs, and total call volume over a window, with a specific verb and resource. It distinguishes from sibling tools by focusing on trending data rather than search or 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 description lists three explicit use cases for when to use the tool and explains how window selection affects results (short window for hot trends, long for demand). It does not explicitly state when not to use, but the guidance is clear and helpful.

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 and idempotent behavior. The description goes far beyond by detailing internal logic: Jaccard similarity threshold, partition filter, fill check against CLOB depth, and conditions for not trading. No contradictions with annotations.

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

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

The description is thorough but lengthy, packed with technical details. It is front-loaded with the core purpose and structured by mode, but could be slightly more concise without losing content. Nonetheless, 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?

Given the complexity of arbitrage detection with multiple modes and no output schema, the description fully explains input choices, algorithmic details, response shape, and caveats (fill check, placeholder filters). No important gaps remain.

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 both parameters described. The description enhances each parameter by explaining the mode behavior (e.g., event mode walks child markets, topic mode searches related events) and provides examples, adding significant value 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 finds arbitrage opportunities on Polymarket via monotonicity violations and partition-sum checks. It distinguishes three modes (trending_scan, event, topic) and provides specific usage scenarios, making the purpose extremely clear.

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

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

The description provides explicit guidance on when to use each mode: trending_scan for top markets, event for specific events (recommended), and topic for cross-event scanning. It also references polymarket_fill_risk for custom sizing, giving clear alternatives 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?

Annotations already indicate safe, read-only behavior. The description goes far beyond by detailing caching (1h KV cache keyed on all knobs), model families (crypto_price, news_momentum, etc.), edge calculations, tradeable-edge knobs, and diagnostics. This exceeds the required transparency.

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

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

The description is very long and includes extensive technical details that, while valuable, may overwhelm an AI agent. It is well-structured with sections, but a more concise front-loading of key information would improve usability for quick decision-making.

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 9 parameters, no output schema, and complex behavior, the description is exceptionally complete. It covers all three model segments, tradeable-edge knobs, diagnostics, and even notes about unreliable Fed signals and caching behavior. The agent has all necessary context to use the tool effectively.

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

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

Schema coverage is 100%, so baseline is 3. The description adds context beyond the schema, such as default values and usage hints (e.g., 'Bump for very thin partitions; drop to 0 if you have a smarter fill model'). This additional guidance justifies a score above baseline.

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

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

The description clearly states the tool's function: scanning Polymarket markets to return opportunities where Pipeworx data disagrees with market price, with a specific use case of 'what should I bet on today'. It distinguishes itself from siblings like polymarket_arbitrage and polymarket_edge_tracker by detailing its model families and unique methodology.

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 a clear use case and mentions knobs for filtering tradeable edges, but it does not explicitly outline when to use this tool versus alternatives like polymarket_arbitrage or polymarket_edge_tracker. While the context is helpful, explicit exclusions or comparisons would improve this dimension.

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

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. The description adds valuable behavioral context: history depth bounded by 60-day TTL, snapshots written on cache-miss, decay from daily closes not intraday. 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 relatively long but every sentence adds essential detail like response structure and limits. It is front-loaded with purpose. Could be slightly tightened but remains 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?

Despite no output schema, the description thoroughly explains the response fields (tracked[], expired[], snapshot_dates[]) and their meaning. Also covers limits and data freshness, making it complete for a complex time-series tool.

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

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

Schema coverage is 100% with descriptions for days and window. The tool description adds default values, max bounds, and clarifies what each parameter controls (lookback, snapshot family), going beyond the schema.

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

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

The description uses specific verbs and nouns: 'edge persistence and decay telemetry', 'answers how long has this edge existed and is it shrinking?'. It clearly distinguishes from siblings like polymarket_edges by focusing on time-series behavior.

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 explains the use case (comparing fresh vs old edges) and implicitly differentiates from alternatives like polymarket_edges (which likely gives current edges). However, it lacks explicit '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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds valuable behavioral context: walks the ladder, returns specific fields (top_of_book, vwap_fill_price, etc.), and explains the risk of partial fills. 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 well-structured with clear sections (required, single-market, basket, usage note) but is somewhat verbose. Every sentence adds value, though some could be tightened. Front-loaded with the main purpose, making it 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?

Despite no output schema, the description enumerates all return fields for both modes (e.g., top_of_book, vwap_fill_price, verdict, capture_ratio, thin_legs). It fully addresses the tool's complexity (4 params, 2 modes, 0 required) and provides enough context for correct invocation.

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

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

Schema coverage is 100% with descriptions for all four parameters. The tool description adds significant semantic value by explaining how parameters behave differently in single-market vs basket mode (e.g., size_usd interpretation, side auto-detection). This goes beyond the schema's basic 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 tool performs a 'realizable-vs-theoretical edge check against live CLOB order-book depth' with two distinct modes (single-market and basket). It distinguishes itself from sibling tools like polymarket_arbitrage and polymarket_edges by specifying when to use it before acting on their signals.

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

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

Explicit guidance is provided: use this tool before polymarket_arbitrage signals or polymarket_edges trades above $500. It also warns against assuming capturable overround on thin books and the risk of partial basket fills converting arb into unhedged positions, which is the dominant loss mode.

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

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

Annotations declare readOnly, openWorld, idempotent, non-destructive. Description substantially adds behavioral context: explains compatibility conditions (non-equivalent bet shapes, semantic mismatch), temporal alignment constraints, and counters for dropped comparisons. No contradictions with annotations.

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

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

Description is well-structured: purpose first, then modes with shortcuts, then response fields and safety fields. Some redundancy (e.g., repeatedly mentioning compatibility_warning) but every sentence adds value. Could be slightly more concise but remains clear and informative.

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, description fully describes the response structure: leg-by-leg prices, top_spreads_pp, safety fields (compatibility_warning, temporal_alignment, skipped counts). Covers all aspects a user needs to understand the tool's behavior and outputs.

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 all 3 parameters with descriptions. Description adds significant meaning by explaining the two modes, listing all topic shortcuts, describing override behavior, and providing examples. Goes beyond schema by clarifying how parameters interact and their typical usage.

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

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

Description clearly states it computes cross-venue spread between Kalshi and Polymarket for the same resolving question. It distinguishes from sibling tools like polymarket_arbitrage by specifying the two-venue comparison and using 'cross-venue spread' which is unique among the listed tools.

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

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

Explicitly describes two modes (topic shortcuts or explicit ticker/slug), explains when spreads are meaningful vs not via compatibility_warning and temporal_alignment fields, and cautions that most pre-mapped topics return warnings ('pre-mapped ≠ tradeable'). Users know exactly when to use it and when results may be invalid.

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

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

Annotations indicate read-only, idempotent, non-destructive. Description adds scoping to identifier and the behavior of listing all keys when key omitted, which is useful 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 two sentences, front-loaded with the action, and every sentence adds value. No redundancy.

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

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

For a simple tool with one optional parameter and no output schema, the description covers both modes, use cases, and scoping. It does not explain return format or errors, but it's adequate.

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

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

Schema coverage is 100%, and the description restates the key behavior (omit to list). No additional semantic information is provided 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 retrieves a saved value or lists all keys, with concrete examples (ticker, address, research notes). It distinguishes from siblings by naming 'remember' and 'forget'.

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

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

The description explains when to use the tool: to retrieve previously stored context without re-deriving. It mentions scoping and pairing with remember/forget, but does not explicitly exclude other use cases.

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

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

Adds value beyond annotations by describing return fields (source, citation_uri, raw payload), mark_read behavior, and filtering options. Annotations already indicate safe read operation (readOnlyHint, idempotentHint), and description does not contradict 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?

Four sentences, front-loaded with main purpose, no redundant or misleading information. Every sentence serves a clear role.

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 essential aspects: return format, filtering parameters, mark_read side effect, polling suitability, and alternative access. Lacks error handling details but sufficient for a read-only tool with minimal side effects.

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 with descriptions, so description adds limited extra meaning. It groups parameters and explains purpose informally, but does not significantly augment schema information.

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

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

Clearly states it pulls fired events from the subscription feed, returning recent alerts with specific fields. Distinguishes from siblings like list_subscriptions by focusing on reading alerts versus managing 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?

Provides clear guidance on when to use: to get recent alerts with optional filtering by type and since, and mark_read behavior. Mentions polling works and alternative HTTP endpoint for scripts, but does not explicitly exclude scenarios or compare with all siblings.

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

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

Annotations already declare safe, idempotent, non-destructive. Description adds that it fans out to multiple sources in one parallel call, has fallback behavior, and return structure (changes grouped by source, total_changes, citation URIs).

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

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

Front-loaded with example queries. Every sentence adds value. Length appropriate for complexity of multi-source tool. Clear 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?

Despite no output schema, description explains return structure. Covers all three parameters, source behavior, fallbacks, and distinguishes from sibling. Complete for a complex 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%. Description adds examples for 'since', explains 'value' accepts ticker or CIK, and clarifies 'type' only supports 'company'. Provides recommended 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 clearly states the tool is a change feed for a company, listing example user queries. It distinguishes from sibling entity_profile and details the sources (SEC EDGAR, GDELT/GNews, USPTO).

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

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

Explicitly says to use entity_profile for static profile. Provides guidance on when to use relative shorthand vs ISO dates and recommends '30d' or '1m'. Mentions GDELT preferred over GNews and USPTO soft-fail.

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 write, idempotent, non-destructive. The description adds valuable context: scoped by identifier, persistence differences for authenticated vs anonymous sessions (24 hours), and session-spanning capability. No contradictions.

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

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

The description is concise with five sentences, front-loading the core purpose and usage. Every sentence adds value without redundancy.

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

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

For a simple two-parameter tool, the description fully covers purpose, usage, persistence behavior, and pairing with siblings. No gaps given the annotations and schema.

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

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

Schema coverage is 100% with clear parameter descriptions. The description adds concrete examples for key and value (e.g., 'subject_property', 'any text'), enhancing understanding beyond the schema fields.

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 'save data' and clearly states the resource (key-value store) and purpose (reuse later). It distinguishes from sibling tools 'recall' and 'forget' by explicitly pairing with them.

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

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

The description provides clear use cases (e.g., 'a resolved ticker, a target address') and when to use it (when something worth carrying forward). It mentions pairing with recall and forget but does not explicitly exclude alternative tools beyond that.

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

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

Annotations already declare readOnly, idempotent, and openWorld hints, but the description adds substantial behavior: internal cascade through lookup endpoints, auto-disambiguation, and exact return fields for each type (e.g., 'returns ticker + 10-digit CIK + company_name from SEC EDGAR + citation URI'). This exceeds annotation value.

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

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

The description is moderately long but well-structured. It front-loads user query examples and then packs dense, useful details for both entity types. Slight verbosity in examples, but every sentence contributes value.

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

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

With no output schema, the description fully explains return values for both types, input variations, and internal behavior. It provides a complete mental model for how to invoke and interpret results, including citation URIs.

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 both parameters 100% with examples. The description adds minor context like 'auto-disambiguated' and reiterates accepted input forms, but largely repeats schema information. 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 purpose: 'resolve a user-spoken NAME to the canonical/official identifier other tools require as input.' It lists supported entity types (company, drug) and explicitly distinguishes from siblings by positioning it as a prerequisite for other 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 an explicit usage instruction: 'Use FIRST whenever you have a name but need an ID.' It also notes the tool replaces 2-3 manual lookups, giving a clear when-to-use heuristic. While alternatives aren't named, the role as a first-step lookup 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 indicate safe, read-only, idempotent behavior. The description adds that it probes each entity with ai_visibility_check, ranks by score, and returns per-entity metrics (score, confidence, signal density), providing operational insight without contradicting annotations.

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

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

The description is three sentences: first states the core action, second explains the probing and ranking process, third gives a concrete use case and return format. It is front-loaded, concise, and contains no redundant information.

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

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

Given 4 parameters, 1 required, 100% schema coverage, and no output schema, the description fully explains the tool's behavior and return value (ranked list with score, confidence, signal density). It covers the probing mechanism and the special role of the first entity.

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

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

Schema coverage is 100% with descriptions for all parameters. The description adds value by clarifying that the first entity in the array is treated as the 'subject' for narrative, and that models defaults to workers-ai, requiring _apiKey only for anthropic model.

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 compares AI visibility across multiple entities, using ai_visibility_check to probe and rank. It specifies the use case for competitive AI-marketing audits with an example question, distinguishing it from single-entity tools like ai_visibility_check.

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 context for when to use the tool ('competitive AI-marketing audits') and gives an example query. It implicitly contrasts with ai_visibility_check by describing the multi-entity comparison, but lacks explicit alternative guidance or when-not-to-use instructions.

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 idempotentHint, but the description adds significant behavioral context: it fans out across multiple services, mentions potential latency (5-30s for new versions), describes the return format (summary block, per-advisory detail, links, alternative versions), and explains that partial failures degrade gracefully with a sources_failed list. No contradictions with annotations.

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

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

The description is a single dense paragraph but front-loaded with the main purpose. Every sentence adds value, though breaking it into sections could improve readability. It is appropriately sized given the 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 explains the return value: a summary block with fields like is_latest, license, bundle sizes, etc., plus per-advisory details, links, and alternative versions. It also covers edge cases like partial failures, making the tool's behavior fully understandable.

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 are described in the schema (100% coverage). The description adds value by clarifying that scoped packages (e.g., '@types/node') are accepted for the 'package' parameter and that the 'version' defaults to latest, which reinforces 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 states the tool's purpose as a composite check for evaluating whether to add an npm package, aggregating data from deps.dev and bundlephobia. It distinguishes itself from siblings by specifying the npm-only scope and directing users to other tools for other ecosystems.

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

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

The description explicitly tells when to use the tool ('when an agent asks is X safe / popular / small'), and when not to use it (other ecosystems: PyPI, Maven, etc. fall under deps.dev directly). It also provides guidance on graceful degradation for partial failures.

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. The description goes beyond by revealing the underlying model (BGE-base-en), algorithm (cosine over 500-character overlapping windows), character limit (200K chars with truncation and flagging), and output structure (passages with offsets and scores). No contradictions.

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

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

The description is compact (4 sentences) with front-loaded purpose. Every sentence serves a distinct purpose: stating the action, explaining benefits, pairing with a sibling, and detailing technical constraints. 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?

Despite lacking an output schema, the description clearly states the return format (top-N passages with offsets and similarity scores). It covers input constraints (max chars, truncation), usage context, and pairing with another tool. For a tool with this complexity and given existing schema coverage, the description provides complete 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%, so baseline is 3. The description adds value by giving concrete examples for the query parameter (e.g., 'supply-chain risk') and clarifying the text parameter's maximum size with examples (SEC 10-K, article). It also explains the limit parameter's default and range. This extra context warrants 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 clearly states the tool performs semantic search inside a fetched record, with concrete examples like SEC 10-K bodies and articles. It distinguishes itself from sibling tools by emphasizing that it saves context by returning only relevant passages, implying it's for large documents rather than general Q&A.

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 when the record is too big to cram into the prompt' and pairs with ask_pipeworx_grounded, providing clear when-to-use guidance. However, it does not explicitly state when not to use the tool or mention alternatives like using the document directly for small records.

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

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

Annotations indicate mutability (readOnlyHint=false) and idempotency. The description adds context such as account requirements, type-specific parameter examples, delivery channel specifics (e.g., one-time webhook secret, auto-disable after 10 failures). It does not contradict annotations.

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

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

The description is moderately lengthy but well-structured: it starts with the core action, then prerequisites, supported types with examples, and delivery details. Every sentence adds value, though some redundancy with schema parameter descriptions exists. It remains clear and scannable.

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 complexity (multiple subscription types, nested delivery object, no output schema), the description is remarkably complete. It covers prerequisites, type-specific parameters, delivery channel behaviors (including verification, limits, and webhook auto-disable), and what the tool returns (subscription ID). No critical gaps remain.

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

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

Parameter schema coverage is 100%, and the description adds significant meaning beyond the schema: it provides detailed examples for each type (e.g., items codes for sec_8k), explains delivery fields with constraints (e.g., phone verification, webhook signing), and clarifies required vs optional fields. This greatly aids correct parameter selection.

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 creates a proactive monitoring subscription to a live-data event stream and returns a subscription ID. It distinguishes from siblings like list_subscriptions and unsubscribe by specifying the creation action and output.

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 explains when to use the tool (to set up subscriptions) and provides prerequisites (Pipeworx OAuth account, non-anonymous). It details supported types and delivery channels, including constraints like phone verification and SMS caps. However, it doesn't explicitly state when not to use or compare with 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 readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds behavioral detail: returns category-bucketed example questions with live tool shapes. No contradictions.

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

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

Description is efficient with no wasted words; front-loads trigger phrases and purpose. Slightly long but each 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?

Tool is simple (optional param, no output schema). Description covers behavior, output, usage ordering, and customization. Fully adequate for an onboarding 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 100%, so baseline is 3. Description adds value by listing example topics and explaining the optional parameter's purpose, going beyond 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?

Description clearly states this is an onboarding entry point to discover what Pipeworx can do, listing specific categories and that it returns example questions with tool+argument shapes. Distinguishes from sibling tools by being the first call for an agent uncertain of capabilities.

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

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

Explicitly says 'Use this FIRST' and provides guidance on when to call (when you do not yet know capabilities) and how to call (no arguments vs topic). Lacks explicit when-not to use, but the context is clear.

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

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

Annotations indicate destructiveHint=false and the description clarifies that rows are deactivated, not deleted, adding behavioral context. Ownership enforcement is also disclosed. Description adds value 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?

Two sentences, no wasted words. First sentence states core action, second provides critical nuance about ownership and deactivation.

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 (one param, no output schema). Description fully explains the effect, ownership rules, and references a sibling tool for historical data. No gaps identified.

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

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

Only one parameter 'id' with schema coverage 100% (description includes source: 'returned by subscribe'). Description adds minimal extra 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?

Description clearly states the verb 'Cancel' and the resource 'subscription by id'. It distinguishes from siblings like 'subscribe' and 'list_subscriptions' by specifying cancellation and ownership enforcement.

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?

States ownership enforcement ('you can only cancel your own subscriptions') and mentions that historical events remain available via 'recent_alerts', indicating a related tool for viewing past events. No explicit when-not-to-use, but context is clear.

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

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

Annotations indicate read-only, open-world, idempotent, non-destructive. The description adds detailed behavior: returns a verdict with five options, actual value with citation, and reasoning. It also mentions replacing 4-6 sequential calls. No contradictions.

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

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

The description is comprehensive but slightly long. It front-loads trigger phrases and then explains behavior. Every sentence adds value, but some restructuring could improve 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?

Given the tool's complexity (two routing paths, multiple verdicts, citation), the description is thorough and complete. No output schema is provided, but the description adequately details the return format. Sibling tools include many research tools, making the purpose clear.

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. The description provides examples for the claim parameter and explains tolerance_pct usage including default and override scenarios. This adds context beyond the schema descriptions.

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

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

The description clearly states it performs natural-language claim verification with specific trigger phrases. It distinguishes from siblings by detailing the two processing paths (structured SEC for financial claims, grounded pipeline for others).

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 when to use: 'whenever the agent needs to check whether something a user said is factually correct.' It does not provide explicit when-not-to-use scenarios, but the context is sufficiently clear.

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