Bts

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

Disclosures beyond annotations: default model (free), Anthropic cost implications (BYO key), per-model return format {score, confidence, signals, raw_response}, combined view. Annotations already indicate read-only, idempotent, open-world; description adds valuable operational 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?

Three sentences, front-loaded with purpose, no redundant details. Every sentence contributes meaning. Ideal length and 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?

Given no output schema, the description sufficiently explains return values. It covers all 4 parameters, behavioral context, and usage cases. The sibling list is diverse, and this tool's purpose is clearly differentiated.

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%. The description adds examples for entity and explains the BYO key cost for _apiKey, plus the optional role of context. This provides slight additional semantic value over the schema alone.

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

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

The description clearly identifies the tool's purpose: probing LLMs for knowledge about an entity and scoring visibility (0-100). It specifies the verb 'probe' and the resource ('visibility'), distinguishing it from siblings like scan_competitor_ai_presence or bet_research.

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

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

Explicitly states use cases: 'AI-marketing audits, pre-launch brand checks, competitive monitoring.' It implies when not to use (e.g., not for prediction markets) but lacks explicit exclusions. Still, provides clear context for selection.

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 adds valuable context: it 'routes the question' and returns 'structured answer with stable pipeworx:// citation URIs'. 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 front-loaded with its key directive ('PREFER OVER WEB SEARCH') and organized by use case. While slightly verbose, every sentence adds value—listing supported domains, example queries, and output format. No wasted words.

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

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

For a tool that accepts a simple question string and returns structured data, the description fully covers its capabilities: supported domains, routing behavior, citation format, and example queries. No output schema exists, but description sufficiently explains what to expect.

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% because all six parameters are aliases for 'question', each with a description. The main description does not add parameter-specific meaning beyond the schema, but the included schema examples are helpful. Baseline 3 applies.

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

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

The description is extremely specific about what the tool does: it routes factual questions to 3,300 domain-specific tools, covering authoritative data sources like SEC filings, FDA, and weather. It distinguishes itself from sibling tools (e.g., bet_research, entity_profile) by being a general-purpose question router.

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

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

Explicitly advises preference over web search, lists broad categories of questions, provides concrete examples (unemployment rate, Apple 10-K, bitcoin price), and defines trigger phrases like 'what is' or 'find'. Could mention when not to use, but coverage is thorough.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds substantial behavioral details: resolver contract with match confidence levels, low-confidence match short-circuiting, closed market handling, wide spread warnings, and extensive transparency about internal fan-out and error handling (e.g., GDELT 429 fallbacks). 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 lengthy but well-organized with capitalized section headers (CLASSIFIERS, FAN-OUT EXAMPLES, RESPONSE SHAPES, RESOLVER CONTRACT, etc.). It front-loads the core purpose and use cases, then dives into specifics. While every sentence earns its place, some detail could be streamlined for even greater conciseness without losing 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?

Given the tool's complexity (3 params, no output schema), the description is extremely comprehensive. It explains the response structure (result.market, result.analysis, result.evidence), edge cases (low confidence, closed markets, wide spreads), and workflow (resolver, parent extractor, news fields). Without an output schema, the description fully compensates by detailing all important fields and behaviors.

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

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

Schema coverage is 100% with all three parameters described. The description augments the schema by providing multiple examples for the market input, explaining the depth enum (quick vs thorough with defaults), detailing the effect of include_raw, and adding context on how each parameter affects the response. This adds significant meaning beyond the schema.

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

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

The description clearly states the tool's purpose: 'Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call.' It specifies the verb (research/pull), the resource (Polymarket bet), and distinguishes it from siblings by highlighting its focus on bets and data fan-out. Examples of use cases are provided ('should I bet on X').

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

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

The description provides explicit usage guidance: 'Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z".' It also includes examples of classifiers and fan-out scenarios. However, it does not explicitly mention when not to use this tool or compare it to alternative tools. Still, the guidance is clear and context-rich.

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, and open-world behavior. Description adds specifics: returns paired data with pipeworx:// citation URIs, includes a fix for off-calendar fiscal years, and notes data sources (SEC EDGAR/XBRL, FAERS).

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?

Information-dense but well-organized; front-loaded with purpose and use cases. Slightly long but each sentence adds value, with no filler.

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

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

No output schema, but description explains return format (paired data + citations) and data sources. Covers both entity types, mentions efficiency gains (replaces 8-15 lookups), and addresses data accuracy fix. Comprehensive for this tool.

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

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

Schema covers 100% of parameters, and description elaborates on each type: company pulls latest 10-K metrics, drug pulls adverse-event counts, FDA approvals, trials. Adds meaning beyond enum 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 compares 2-5 companies or drugs side by side, with specific use cases like 'compare X and Y' and 'which is bigger'. It effectively distinguishes from sibling tools, none of which perform multi-entity comparison.

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 on when to use: 'compare X and Y', 'X vs Y', 'which is bigger', or rank-by-metric questions. No explicit exclusions, 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 already indicate read-only, idempotent, non-destructive behavior. Description adds that it returns column details like data type, which is beyond annotations. No contradictions; adequately transparent.

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

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

Two sentences: first states purpose and output, second gives usage advice. No redundant information; front-loaded with essential action and resource.

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 low-complexity tool with one parameter and no output schema, the description provides complete information: what it does, what it returns, how to use it, and why it matters. No gaps.

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

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

Schema covers 100% of the parameter (datasetId) with description. The tool description adds context: datasetId is a Socrata 4x4 code from search_datasets, which enhances understanding beyond the schema.

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

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

Description clearly states it lists columns of a data.bts.gov dataset, specifying field name, human label, and data type. It distinguishes itself from siblings like query_dataset and search_datasets by focusing on schema discovery.

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

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

Explicitly advises calling this before query_dataset to know existing fields. Lacks explicit when-not-to-use or alternatives, but the single usage hint is sufficient for this simple tool.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, none of which contradict the description. The description adds valuable behavioral details: returns top-N relevant tools with full schemas and curated examples, ready to call directly without second lookup.

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

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

Five focused sentences with no wasted words. Purpose is front-loaded, followed by example use cases, then details on output format. Every sentence serves a purpose.

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

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

Despite lacking an output schema, the description fully explains what the tool returns (names, descriptions, full input schemas with examples). It also covers the intended usage pattern ('call FIRST'), addressing the contextual needs of an agent selecting from many sibling tools.

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

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

Schema coverage is 100%, so the input schema already fully describes the parameters. The description adds no additional parameter-level details beyond 'accepts task, q, description, search as aliases' which is redundant with schema's 'Alias for query' notes. 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: 'Find tools by describing the data or task.' It lists extensive example domains and distinguishes itself from sibling tools as the only discovery tool, making intention unmistakable.

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

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

Explicitly advises 'Call this FIRST when you have many tools available and want to see the option set.' Provides concrete example phrases. Lacks explicit 'when not to use,' but the instruction is clear enough for an AI agent.

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 (readOnlyHint, idempotentHint), it discloses specific behaviors: known sunset of USPTO PatentsView API, fallback logic for news (GDELT→GNews), and version fix note about FY2025 numbers. 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?

Packs extensive detail in a logical order: purpose, usage triggers, return fields with caveats. Slight verbosity with 'Run 6 fix...' which may be transient, but overall efficient for 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?

No output schema, so description carries full burden. Completely describes all returned fields (cik, company_name, filings with URIs, fundamentals with specific fields, patents status, news, LEI). Covers edge cases (API sunset, stub numbers) adequately.

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?

Adds meaning beyond schema: explains that 'value' can be ticker or CIK, and that names are not supported—requiring resolve_entity first. Schema coverage is 100%, but description enriches usage context.

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

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

The description clearly states 'Get everything about a US public company in one call', with a specific verb and resource. It lists all covered data sources (SEC EDGAR, XBRL, USPTO, news, GLEIF) and distinguishes from sibling tools like resolve_entity.

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

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

Explicitly states when to use: 'when a user asks tell me about X, research Acme, brief me on Tesla, or you'd otherwise call 10+ pack tools'. Also gives when-not: 'names not supported (use resolve_entity first)'.

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 the destructive nature ('Delete') consistently with the annotations (destructiveHint: true). It adds context about clearing 'sensitive data the agent saved earlier', which goes beyond the annotations. No contradiction is present.

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 consists of two concise sentences, front-loaded with the core action. Every sentence adds value with no redundancy, achieving high efficiency in communication.

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

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

For a simple tool with one parameter and no output schema, the description adequately covers the purpose, use cases, and sibling relationships. It is complete given the tool's complexity.

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

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

Schema coverage is 100% with only one parameter ('key'), and the description refers to it ('by key'). The description does not elaborate on key format or constraints beyond what the schema provides, so it meets but does not exceed the baseline for full schema coverage.

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

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

The description clearly states the action 'Delete a previously stored memory by key', specifying the verb and resource. It distinguishes from sibling tools like 'remember' and 'recall' by explicitly mentioning them, fulfilling the requirement for specificity and 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 advises when to use the tool: 'when context is stale, the task is done, or you want to clear sensitive data'. It also mentions pairing with 'remember' and 'recall', providing context. It does not explicitly state when not to use it, but the guidance is sufficient for appropriate selection.

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 internal behavior (fetch page, extract title/description/key links) and output format (single text blob for site-root/llms.txt). Annotations already indicate idempotent and non-destructive nature, and description adds value beyond that.

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

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

Three sentences: purpose, process, use cases. No fluff, well-structured, front-loaded with the main action.

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

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

With 2 well-documented params and no output schema, description covers tool operation, output, and use cases. Missing error handling or edge cases, but sufficient for typical usage.

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

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

Schema covers both parameters with full descriptions (url and max_links). Description adds little beyond schema; mentions 'fetches the page' and 'key links' but does not detail parameter constraints or default values. Baseline 3 due to high schema coverage.

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

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

Clear verb 'Generate' and resource 'llms.txt file', with specific context for AI crawlers. Distinguishes from siblings like scan_competitor_ai_presence by listing explicit use cases (client indexing, own project, competitor audit).

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

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

Lists three concrete use cases, providing good context for when to use. Does not mention when-not-to-use or alternatives, but still clearly guides the agent.

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

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

The description adds significant behavioral information beyond annotations: rate limits (5 per identifier per day), impact (signals affect roadmap), and cost (free, no quota usage). Annotations only indicate readOnlyHint=false, so this extra context is valuable.

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 (5 sentences) and well-structured, starting with the core purpose, then usage guidelines, and finally practical constraints. 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?

Given the tool's purpose (feedback submission) and no output schema, the description covers all necessary aspects: when to use, what to include, rate limits, impact, and constraints. It is fully adequate for an agent to select and invoke the tool correctly.

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

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

Schema coverage is 100% with descriptions for all three parameters. The description adds further guidance by instructing users to describe issues in terms of Pipeworx tools/packs and to avoid pasting the end-user prompt, which clarifies the expected input format.

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 for telling the Pipeworx team about bugs, missing features, or praise. It uses a specific verb ('Tell') and resource ('team'), and distinguishes from sibling tools like 'ask_pipeworx' by focusing on feedback rather than queries.

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 lists when to use the tool: for wrong/stale data (bug), missing tools (feature/data_gap), or praise. It also provides a negative guideline ('don't paste the end-user's prompt') and mentions rate limits and cost, offering clear contextual guidance.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive hints. The description adds valuable context: data is derived from CF analytics-engine, no PII, and cached for 5min-1h. This goes beyond annotations without contradiction.

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

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

The description is two sentences plus a bullet list, front-loaded with purpose. 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?

Given the single parameter, no output schema, and low complexity, the description covers purpose, usage, parameter, and behavioral traits completely. It implies return structure (top tools, top packs, total call volume) adequately.

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 adds semantic meaning to the 'window' parameter: shorter windows for hot topics, longer for steady-state. This enriches the schema's enum description.

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

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

The description clearly states the tool returns top tools, top packs, and total call volume over a recent window. It uses specific verbs ('What other AI agents are calling') and distinguishes from siblings by focusing on trending usage, 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?

The description provides three explicit use cases (discovering hot data sources, confirming canonical choices, seeing alignment with agents). It also mentions caching behavior. While it does not explicitly state when not to use or compare to alternatives, the use cases are clear and useful.

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

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

Annotations already indicate readOnlyHint, openWorldHint, idempotentHint. The description adds substantial behavioral details: monotonicity checks, partition filter with placeholder handling, Jaccard similarity threshold, output structure with fields like gap_pp and suggested_trade. It discloses limitations and edge cases 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 fairly long but well-structured with clear sections (TWO MODES, SEMANTIC ANCHOR, PARTITION FILTER, Response). It is front-loaded with the core purpose. While somewhat verbose, it effectively explains complex functionality.

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

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

The description fully covers inputs, modes, filters, edge cases (placeholder skipping, Jaccard filter, partition fraction), and output format. No output schema exists, so the description adequately describes return values. Complete for the tool's complexity.

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

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

Schema coverage is 100% and both parameters are described. The description adds meaning beyond schema: explains modes, parameter formats (slug or URL), and associated behavior. Given high coverage, baseline is 3, but description adds value, justifying 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 finds arbitrage opportunities on Polymarket via monotonicity violations and partition-sum checks. It distinguishes two modes (event and topic) and specifies the resource and operation. It differentiates from sibling tools like polymarket_edges by focusing on arbitrage detection.

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 (event for a single slug, topic for a seed question) and explains cross-event mode semantics and Jaccard similarity filter. However, it does not explicitly state when not to use the tool or mention alternatives among siblings.

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

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

The description supplements annotations (readOnlyHint, idempotentHint, etc.) with rich behavioral details: edge calculation net of slippage, cached for 1h, diagnostic fields for empty segments, and warnings when recent price moves exceed the edge. 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 front-loaded with purpose and structure, but is relatively long. Every sentence contributes unique information (e.g., model families, edge components, diagnostics). Could benefit from paragraph breaks for improved readability, but the logical flow from purpose to response structure is clear.

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 (9 parameters, three segments, no output schema), the description is remarkably complete. It outlines top-level response fields, caching, and diagnostic fields to explain empty segments. The detailed algorithm descriptions compensate for the lack of an output schema, ensuring agents can interpret results.

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

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

With 100% schema description coverage, the schema already documents parameters thoroughly. The description adds value by explaining rationale for defaults (e.g., slippage_pp accounts for bid/ask spread) and interactions (e.g., min_partition_leg_kelly vs min_kelly). Some parameter details are already in schema, so slightly above baseline 3.

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

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

The description clearly states that the tool scans Polymarket markets to find opportunities where Pipeworx data disagrees with market price, specifically built for daily betting decisions. It details three response segments and distinguishes its functionality from plausible sibling tools like polymarket_arbitrage by focusing on edge discovery with custom models.

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

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

The description explicitly frames the tool for 'what should I bet on today' and provides parameter guidance (e.g., min_liquidity, max_spread_pp) to filter unrealizable edges. While it doesn't name sibling tools for exclusion, the detailed algorithm and caching behavior give sufficient usage context. Lack of explicit 'when not to use' prevents a 5.

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

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

The description thoroughly explains behavioral traits: it details safety fields (compatibility_warning, temporal_alignment, skipped_cross_type/subtype) and their significance. It aligns with annotations (readOnlyHint=true, idempotentHint=true) and adds critical context about edge cases and limitations.

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

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

The description is long but efficient, front-loading the core purpose and then systematically covering modes, response fields, and safety information. While dense, every sentence contributes value, though some repetition could be trimmed.

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?

Without an output schema, the description fully covers the return structure: leg-by-leg prices, matched spreads, and safety fields. It explains complex concepts like compatibility_warning and temporal_alignment, making the tool highly comprehensible 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 is 100% with descriptions for all three parameters. The description adds meaning by explaining the interaction between parameters (topic overridden by explicit tickers) and the purpose of each field (e.g., 'Pre-mapped: fed | btc | ...' for topic).

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: 'Cross-venue spread between Kalshi and Polymarket for the same resolving question.' It specifies the verb (calculates spread), resources (two prediction markets), and condition (same question), effectively distinguishing it from siblings like polymarket_arbitrage.

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

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

The description explains two modes (topic shortcuts vs explicit tickers) and warns that pre-mapped topics often return compatibility warnings (pre-mapped ≠ tradeable). It provides context on when to use each mode but does not explicitly compare to other tools or state when not to use.

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

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

Annotations already declare read-only, idempotent, open-world, non-destructive. Description adds value by clarifying return format (array of row objects keyed by field name) and limits (default $limit=50, max 50000). 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?

Concise, front-loaded with purpose, uses colons for clauses, every sentence adds value. No wasted words, 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 8 parameters and no output schema, description fully covers purpose, each parameter with examples, return format, defaults, and limits. Complete for effective tool selection and invocation.

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

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

Schema description coverage is 100%. Description adds significant context beyond schema: explains SoQL clauses with examples, specifies that datasetId is from search_datasets, and clarifies result format. Greatly enhances usability.

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 queries rows from a data.bts.gov dataset using SoQL, specifying the verb, resource, and method. Distinguishes from sibling tools like search_datasets and dataset_columns by focusing on querying rather than discovery.

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

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

Explicitly advises to use dataset_columns first to learn field names, providing usage context. Does not explicitly state when not to use, but the description implies its purpose for querying datasets, and siblings cover search/discovery.

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

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

Annotations already mark it as read-only and idempotent. Description adds that it's scoped to an identifier and describes listing behavior when key is omitted, adding useful context beyond annotations.

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

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

Two dense sentences front-load the action and key behaviors, with no wasted words. Every sentence is 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?

Describes what is returned (value or list of keys) and scope, but does not specify return format (e.g., JSON). Given simplicity, minor gap.

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

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

Schema coverage is 100% and describes the key parameter, but the description provides concrete examples of key values (ticker, address, notes) and clarifies that omitting the key lists all, adding semantic 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 retrieves a value saved via 'remember' or lists all keys if omitted, with concrete examples like ticker or address. It distinguishes itself from siblings '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?

Explicitly describes when to use (look up stored context) and implies not to use for saving or deleting by pairing with 'remember' and 'forget'. Could add explicit exclusionary language, 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?

The description provides detailed behavioral information beyond the annotations: explains parallel fan-out to multiple sources (SEC, GDELT/GNews, USPTO), fallback behavior, and a future sunset. This adds significant context that annotations alone do not cover.

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

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

The description is a single well-structured paragraph: purpose, use cases, behavioral details, parameter hints, and alternative tool. No redundant or unnecessary sentences; every sentence adds value.

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

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

Despite no output schema, the description explains the return structure (structured changes[] grouped by source, total_changes count, citation URIs). It also covers edge cases like fallbacks and API sunset, making it complete for a complex multi-source tool.

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

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

Schema coverage is 100%, providing baseline. Description adds value by explaining accepted formats for 'since' (ISO date or relative shorthand with examples) and clarifying 'value' can be ticker or CIK. The enum for 'type' is already in 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 provides news/updates on a company within a time window, using specific verbs ('what's new') and resource ('company'). It includes example queries and explicitly distinguishes from the sibling tool '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 provides explicit guidance on when to use this tool versus 'entity_profile', and gives example queries. It does not explicitly state situations where the tool should not be used, 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?

Adds valuable details beyond annotations: key-value storage scoped by identifier, persistent memory for authenticated users, and 24-hour retention for anonymous sessions. Annotation idempotentHint=true aligns with idempotent nature noted implicitly.

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

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

Single efficient paragraph with no wasted words. Front-loaded purpose and usage, followed by technical details. Every sentence earns its place.

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

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

For a simple 2-param tool with no output schema and annotations providing safety profile, the description adequately covers purpose, usage, behavior, and pairing with sibling tools. No gaps.

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

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

Schema covers both parameters with 100% coverage, but description adds meaning with examples for key ('subject_property') and clarifies value as 'any text'. Effectively enhances 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 'Save data the agent will need to reuse later' and distinguishes the tool from siblings like 'recall' and 'forget' by mentioning them explicitly.

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

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

Provides explicit guidance on when to use: 'when you discover something worth carrying forward' and pairs with 'recall' and 'forget'. Missing explicit when-not to use, but context is sufficient.

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

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

Annotations are consistent (readOnly, idempotent, not destructive). Description adds significant behavioral context: cascading through multiple endpoints, auto-disambiguation, replacement of manual lookups. 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?

Five sentences, no unnecessary words. Front-loaded with purpose, then details on types and outputs. Efficient 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 no output schema, description fully covers return values for both entity types, including citation URIs. Explains internal complexity (cascading lookups). Sufficient for an agent to understand what the tool returns and how to use results.

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

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

Input schema has 100% coverage with descriptions for both parameters. Description enriches by detailing exact outputs per entity type (e.g., ticker+CIK+name+URI for company) and accepted input formats. While schema covers basics, description adds substantial practical detail 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 resolves user-spoken names to canonical IDs, lists supported types (company, drug), and specifies what each returns (ticker, CIK, RxCUI, etc.). It distinguishes from sibling tools by noting it replaces 2-3 manual lookups, making its purpose highly specific and actionable.

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 FIRST when you have a name but need an ID,' providing clear when-to-use guidance. Does not explicitly list alternatives or when not to use, but the context of sibling tools and the phrase 'FIRST' implies prioritization. Lacks explicit exclusion criteria.

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

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

Description details the internal behavior: probes each entity with ai_visibility_check, ranks by score, surfaces most/least recognized. Describes return fields (score, confidence, signal density). Annotations (readOnlyHint, idempotentHint) are consistent, and the description adds significant context beyond annotations.

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

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

Three sentences, each serving a distinct purpose: stating the main function, explaining how it works, and giving a use case. No redundant or extraneous phrasing.

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?

Describes output (ranked list with score, confidence, signal density) and usage constraints (2-8 entities, first as subject). Missing error conditions or rate limits, but openWorldHint suggests external calls. Adequate for a relatively straightforward comparison 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% and each parameter is already described. The description adds only minor context (first entity treated as subject, context disambiguates names). Baseline 3 is appropriate as the description does not significantly enhance understanding beyond the schema.

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

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

Description clearly states the tool compares AI visibility across multiple entities side-by-side, using specific verbs (compare, probe, rank) and resource (AI visibility). It distinguishes from sibling ai_visibility_check which handles single entities.

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 a concrete use case (competitive AI-marketing audits) and examples of when to use ('does Claude know about us'). Implicitly advises against using for single-entity checks, but does not explicitly list alternatives for other scenarios.

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

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

Adds significant value beyond annotations: describes partial failure behavior (sources_failed lists timeouts), bundlephobia first measurement taking 5-30s, and return format (summary block, per-advisory detail, links, alternatives). Annotations already indicate readOnly, openWorld, idempotent, non-destructive; the description enhances with operational details.

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

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

Single paragraph but extremely dense and well-structured: purpose first, then full details in logical order (sources, usage, return, limitations, error handling). 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?

Completely explains the tool's behavior for its complexity: multiple external sources, partial failures, specific timing, return fields. No output schema, so detailed return description is essential and provided. Covers limitations (NPM-only) and alternatives (other ecosystems).

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

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

Schema coverage is 100%, so baseline is 3. Description adds clarifying context: scoped packages (e.g., '@types/node') are accepted for package, and version defaults to latest when omitted, which goes beyond 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 uses specific verbs and resources: 'Composite should I add this npm package check', clearly stating it checks license, advisories, bundle size, and dependency count across multiple sources. It distinguishes from sibling tools like scan_competitor_ai_presence by focusing solely on npm package analysis.

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: 'Use whenever an agent asks "is X safe / popular / small" or "what does adding lodash cost me"'. Also notes NPM-only and that other ecosystems use deps.dev:version directly, providing clear usage boundaries.

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 a safe read operation (readOnly, idempotent). The description adds valuable context: it specifies the source portal, the exact return fields (Socrata 4x4 id, name, description), and example queries. This fully discloses behavior beyond annotations.

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

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

The description is a single, well-structured paragraph that front-loads the action and source. Every sentence adds value, including example queries and integration with other tools. 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?

Given no output schema, the description adequately explains the return format and how to use the results. It covers the domain, return fields, example queries, and links to related tools, making it complete for a search tool.

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

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

Schema coverage is 100%, so baseline is 3. The description adds context (e.g., q is full-text search, example queries) but does not significantly enhance parameter understanding beyond the schema.

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

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

The description explicitly states the tool searches datasets on a specific portal (data.bts.gov) and returns id, name, and description. It distinguishes its role from sibling tools like dataset_columns and query_dataset by indicating how to use the returned id.

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

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

It clearly advises using the resulting id with dataset_columns and query_dataset, establishing its role as an entry point. Although it does not explicitly state when not to use it, the context of content domains and example queries provides sufficient 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=true, destructiveHint=false, and idempotentHint=true. The description adds context about the return format (verdict, structured form, actual value with citation, percent delta) and states that it replaces multiple sequential calls. 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 five sentences, each adding value: purpose, usage triggers, scope, output details, and efficiency comparison. No redundancy or unnecessary words. Well-structured and 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?

Despite lacking an output schema, the description thoroughly explains the return values (verdict, structured form, actual value, citation, percent delta). It covers purpose, inputs, outputs, and domain scope. Minor omission: no mention of failure modes or error handling, but that's acceptable given the annotations' safety profile.

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

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

Schema coverage is 100% and the schema description for the 'claim' parameter already provides examples similar to those in the tool description. The description adds no new semantic information beyond the schema, 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's purpose: fact-check, verify, validate, or confirm/refute natural-language factual claims. It provides synonyms, example user queries, and specifies the domain (company-financial claims). This distinguishes it from sibling tools like ask_pipeworx or bet_research, which are more general.

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 an agent needs to check whether something a user said is true' and gives trigger examples. It also states the current scope (v1 supports only company-financial claims), implicitly advising against use for other types. However, it does not explicitly list when not to use or name alternative tools.

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