Asub Ax

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the bar for behavioral disclosure is lower. The description adds details about default model, optional Anthropic probing with BYO key, and return structure. However, it omits potential side effects like external API calls, rate limits, or error handling, providing only moderate 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 a single paragraph with four sentences: purpose, model configuration, return structure, and use cases. It is front-loaded, no fluff, and every sentence adds essential information. Ideal conciseness.

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

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

Given the tool has no output schema, the description adequately outlines return values (per-model score, confidence, signals, raw_response + combined view). It covers parameters and use cases. Minor gaps like error handling or output format details prevent a perfect score.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the default model and the purpose of '_apiKey' (BYO key), which is not in the schema. This enhances understanding beyond the schema descriptions, earning 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 probes LLMs for knowledge about a business/brand/product/topic and scores visibility (0-100). It specifies the verb 'probe' and resource 'LLMs', with clear use cases. However, it does not explicitly differentiate from similar sibling tools like 'scan_competitor_ai_presence', which slightly reduces clarity.

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 use cases (AI-marketing audits, brand checks, monitoring) but lacks explicit guidance on when to use this tool versus alternatives. It does not mention exclusions or when not to use it, resulting in only moderate usage guidance.

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

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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds that the tool routes questions to internal tools and returns structured answers with citations, beyond what annotations provide. 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 verbose and includes a long list of domains and example questions. While front-loaded with the key preference, it could be more concise without losing clarity.

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

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

Given the tool's vast scope (3,300 tools, many domains), the description covers the key aspects: what it does, when to use, and sample questions. It mentions structured answers and citations but does not address out-of-scope queries or error handling.

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 all parameters as aliases for 'question'. The description only repeats 'Your question or request in natural language' and provides examples, adding minimal 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 that the tool answers factual questions about current/historical data from authoritative sources, preferring it over web search. It provides specific domains and examples, distinguishing it from siblings by contrasting with web search.

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 (for structured data questions) and contrasts with web search, but it does not mention alternative sibling tools or when not to use beyond that. The examples provide clear usage context.

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

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

Annotations include readOnlyHint, idempotentHint, destructiveHint=false. The description adds extensive behavioral details: fan-out examples per classifier, response shapes, safety mechanisms (low-confidence short-circuit, closed market handling, wide spread warning), resolver contract, and parent event extraction. 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 lengthy but well-organized with sections (CLASSIFIERS, FAN-OUT EXAMPLES, RESPONSE SHAPES, etc.). It front-loads the core purpose. Some redundancy could be trimmed, but overall it's structured for easy reading.

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 high complexity (multiple classifiers, fan-out patterns, response shapes, safety modes), the description covers all necessary aspects. No output schema exists, but response fields are detailed. Parameters are fully covered. The description leaves no significant 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?

All three parameters (market, depth, include_raw) are explained in the schema descriptions, and the tool description adds further context: market can be slug, URL, or question; depth default thorough; include_raw default false with explanation of trade-off. Schema coverage is 100%, but description enriches understanding.

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

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

The description clearly states the tool resolves a Polymarket bet, classifies it, fans out to data packs, and returns evidence. It distinguishes itself from sibling tools like polymarket_edges and polymarket_arbitrage by focusing on comprehensive research via Pipeworx data.

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 usage guidance is provided: 'should I bet on X', 'what does the data say', 'is there edge in Z'. It also explains when not to trust results (low-confidence matches, closed markets) and how to inspect resolver contract and parent event fields.

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 safety hints (readOnly, idempotent, openWorld). The description adds valuable behavioral context: data sources (SEC EDGAR/XBRL, FAERS), specific metrics, a fix for off-calendar fiscal years, and sorted results. 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 a single paragraph but front-loads the purpose and adds necessary detail. Every sentence adds value, though it could be slightly more structured. It is appropriately sized 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?

Given no output schema, the description covers input constraints, data sources, return characteristics (sorted, paired data, citation URIs). It is fairly complete, though the exact output format is not detailed. Overall adequate for an agent to invoke correctly.

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

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

Schema description coverage is 100%. The description adds meaning beyond the schema by explaining what each type does (company pulls financials, drug pulls adverse events) and provides examples for values. This helps agents form correct inputs.

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 verbs and resources. It distinguishes from siblings by noting it replaces 8-15 sequential lookups, implying efficiency over single-entity tools 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 lists use cases ('compare X and Y', 'X vs Y', 'which is bigger', rank-by-metric questions), providing clear context. However, it does not mention when not to use it or alternative tools explicitly.

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 adds beyond annotations: specifies return content (top-N relevant tools with names, descriptions, full schemas, examples) and states readiness for direct calling. Annotations already signal read-only/idempotent/non-destructive, so 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?

Two sentences, front-loaded with purpose and followed by usage guidance and return details. No extraneous 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?

No output schema, but description fully explains what is returned. Covers purpose, usage context, return structure, and practical examples. Complete for a discovery tool with low complexity.

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

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

Schema coverage is 100%. Description provides natural language examples and aliases for query, adding practical context beyond schema descriptions. Does not detail 'limit' beyond schema, but overall adds value.

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 states 'Find tools by describing the data or task' – a specific verb and resource. It enumerates supported domains (SEC filings, FDA drugs, etc.) and distinguishes this meta-tool from sibling tools that are application-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?

Explicitly says 'Use when you need to browse, search, look up, or discover what tools exist' and 'Call this FIRST...'. Provides clear context for when to use, but does not list explicit alternatives or when-not-to-use 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. Description adds significant context: data sources (SEC, XBRL, USPTO, news, GLEIF), known issues (USPTO sunset, stale data fix), and return structure. 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 well-structured and front-loaded with the purpose. It is slightly long but every sentence adds value, explaining sources, limitations, and return details. No fluff.

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

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

Given no output schema, description thoroughly explains all return fields (cik, company_name, recent_filings with URIs, fundamentals details, patents status, news fallback, LEI). Covers limitations and data freshness. 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 covers 100% of parameters, so baseline is 3. Description adds extra value: clarifies ticker vs zero-padded CIK, warns names not supported, and suggests resolve_entity. This surpasses 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?

Description clearly states 'Get everything about a US public company in one call' with a specific verb and resource. It distinguishes from sibling tools by mentioning it replaces 10+ pack tools across various sources, making the purpose unambiguous.

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

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

Explicitly tells when to use ('tell me about X', 'research Acme', etc.) and when not to (names not supported, use resolve_entity first). Provides clear context and alternatives, meeting the highest standard.

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

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

Annotations already indicate destructiveHint=true and idempotentHint=true. The description reinforces the destructive operation by using 'Delete', but adds little beyond the annotations. 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?

Two sentences, no wasted words. The first sentence states the core action, the second provides usage context. Both are directly relevant.

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

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

Given the tool's simplicity (one param, no output schema), the description covers purpose, usage guidelines, and pairing with siblings. It is complete for the tool's complexity.

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

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

Schema coverage is 100%, and the description only mentions 'by key', which is already described in the schema's parameter description. No additional semantics are provided beyond what's in the input 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 action ('Delete') and the resource ('previously stored memory by key'). It distinguishes from siblings 'remember' and 'recall' by mentioning pairing with them, indicating the tool's unique role.

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 the tool: 'when context is stale, the task is done, or you want to clear sensitive data'. It also suggests pairing with related tools, providing clear guidance on usage context.

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

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

Describes fetching page, extracting metadata, and outputting standard markdown. Annotations already indicate read-only, idempotent, non-destructive; description adds operational detail.

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 well-structured sentences with a bullet list of use cases. Front-loaded main action. Every sentence adds value, though could be slightly tighter.

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

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

Covers input, process, output format, and use cases. No output schema, but description explains output sufficiently. Good annotations compensate for missing details.

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; both params (url, max_links) are described. Description repeats defaults but adds no new semantic information beyond schema.

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

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

Clearly states it generates an llms.txt file for AI crawlers, with specific verb and resource. Distinct from sibling tools like ai_visibility_check or scan_competitor_ai_presence.

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

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

Explicitly lists three use cases (client indexing, personal project, auditing competitor). Does not mention when not to use or alternatives, but context is clear.

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

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

Discloses rate limits (5 per identifier per day), that it's free and doesn't count against quota, and that feedback is read daily and affects roadmap. No contradictions with annotations (all false).

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 concise but complete, with first sentence stating purpose followed by usage guidelines and constraints. Every sentence adds value, 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?

Fully covers purpose, usage, behavior (rate limits, cost), and parameter context. No output schema needed since it's a feedback submission. Complete for an agent to use 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 descriptions are clear (100% coverage). The description adds extra context on how to structure feedback and explains enum meanings briefly, enhancing understanding beyond schema.

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

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

The description clearly states the tool is for providing feedback, specifically bugs, features, data gaps, or praise. It distinguishes from siblings like 'ask_pipeworx' by focusing on reporting issues or wishes.

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 (bug, feature, data_gap, praise) and gives guidance on how to frame feedback (in terms of tools/packs, not end-user prompt). Includes rate limits and cost info. Does not explicitly contrast with alternatives, but context is clear.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds valuable behavioral details: data source (CF analytics-engine), no PII, cache duration (5min-1h), and self-aggregating nature. 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 well-structured with a clear opening line, bullet-point use cases, and supplementary details. It is concise for the amount of information, though slightly longer than strictly necessary.

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 lacks explicit details on the return format (e.g., structure of data, order, pagination). While it mentions 'top tools, top packs, and total call volume', the agent cannot infer the exact output structure. Given no output schema, a bit more detail would improve completeness.

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 single optional parameter 'window' is fully described in the input schema with enum and explanation. The tool description repeats the window options but does not add new meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool returns 'top tools, top packs, and total call volume over a recent window' with concrete use cases, distinguishing it from siblings like 'discover_tools' which focus on listing all available tools.

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

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

The description explicitly lists three use cases (discovering hot data sources, confirming canonical tool choice, aligning use case), providing strong contextual guidance. It does not specify when not to use, but the positive direction is clear.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds significant behavioral context beyond annotations: it explains the Jaccard similarity threshold (0.30) for cross-event pairs, the partition filter that drops placeholders and returns null arb signal when placeholder fraction exceeds 20%, and the detailed response structure. This greatly aids agent understanding.

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 justified by the tool's complexity (two modes, multiple checks). It is front-loaded with the purpose, then explains modes and details. Every sentence adds value, though some redundancy exists (e.g., repeating the partition filter concept). It could be slightly trimmed without loss, making it efficient but not perfectly concise.

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

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

Given no output schema, the description thoroughly explains the response structure: an opportunities array with fields (gap_pp, suggested_trade, reasoning, monotonicity violation context) and partition_check object. It also covers edge cases (placeholder fraction >20% returns null, skipped_low_similarity surfaces counts). This ensures the agent fully understands inputs, 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 coverage is 100% with both parameters described in the schema. The description greatly expands on schema descriptions: it provides examples ('when-will-bitcoin-hit-150k' for event, 'Strait of Hormuz traffic returns to normal' for topic), explains the mode each parameter triggers, and clarifies that event accepts a slug or full URL. This adds rich semantics 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 'Find arbitrage opportunities on Polymarket via monotonicity violations + partition-sum checks.' It specifies two distinct modes (event and topic), distinguishing it from sibling tools like polymarket_edges which likely focus on simple price queries. The verb 'find' and resource 'arbitrage opportunities' are specific and 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 explains when to use each mode: event mode for a single event slug, topic mode for a seed question. It notes that cross-event mode catches patterns that single-event misses. However, it does not explicitly state when not to use this tool (e.g., for simple price checks) or compare it to alternatives. The guidance is clear but lacks 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?

The description is rich with behavioral context beyond the annotations. It details caching (1h at KV level), response structure (by_segment, diagnostics), the 'Market moved X.Xpp in 24h' warning, and specifics of edge calculation (net of slippage, Kelly caps). Annotations indicate read-only, open-world, idempotent, non-destructive, so there is no contradiction.

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

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

The description is quite long and dense, but it is well-structured with front-loaded purpose and clear sectioning of model families and knobs. Some details (e.g., exact formulas for Kelly caps, per-sport α) could be streamlined or moved to a separate doc for conciseness. It earns its length given complexity but 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?

Given the high complexity (9 parameters, no output schema), the description is remarkably complete. It explains the response structure (by_segment, diagnostics, fed_candidates/fed_note), the fields carried by each opportunity, the tradeable-edge filters, and even the caching behavior. Missing only output schema details, but these are implied by the description.

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 substantial value by explaining each parameter's context: limit default/max, window options, min_kelly as half-Kelly fraction, min_edge_pp net of slippage, slippage_pp with market context, max_spread_pp and min_liquidity as tradeable-edge filters, category_filter options, and min_partition_leg_kelly with detailed partition arb behavior.

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 top Polymarket markets and returns opportunities where Pipeworx data disagrees with market price. It explains the three model families (MODEL_DRIVEN, STRUCTURAL_ARBITRAGE, CONCENTRATED_LONGSHOT) and that it's built for 'what should I bet on today' to help agents discover opportunities without paging hundreds of markets. However, it does not explicitly differentiate from sibling tools like polymarket_arbitrage or polymarket_kalshi_spread, though the level of detail in describing the methodology provides implicit distinction.

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 context on when to use the tool: for daily betting decisions by scanning top markets. It explains the tradeable-edge knobs (min_liquidity, max_spread_pp, etc.) and the response structure including diagnostics. However, it does not explicitly state when NOT to use this tool or recommend alternatives among siblings, which would improve clarity further.

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 details the read-only nature, response format, and edge cases like compatibility warnings and temporal alignment mismatches. This adds substantial value beyond the readOnlyHint and other 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-structured with clear sections (TWO MODES, RESPONSE, SAFETY FIELDS). It is front-loaded but could be trimmed for brevity without losing clarity.

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

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

Given the tool's complexity (two modes, multiple safety fields, no output schema), the description is extremely thorough, covering all response elements and edge cases.

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 enhances understanding by explaining the topic shortcuts, override behavior, and how parameters interact. It provides meaning beyond the schema itself.

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

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

The description clearly identifies the tool as a cross-venue spread calculator between Kalshi and Polymarket. It states the input modes, output structure, and differentiates from sibling tools like polymarket_arbitrage by focusing on inter-venue comparisons.

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 and provides guidance on when to use each, including safety warnings for incompatible events. It lacks explicit comparison to alternatives but gives enough context for an agent to choose appropriately.

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 the tool is read-only, idempotent, and non-destructive. The description adds behavioral context by warning about PxWeb cell limits, which is valuable beyond the annotations. No contradictions.

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

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

The description is two sentences with no unnecessary words. It front-loads the purpose and immediately provides a critical usage note. Highly 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?

The description covers the basic purpose and a key limitation, but it does not mention the return format or any pagination behavior. Without an output schema, this is a gap. However, the response format is implied in the 'body' parameter 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 description coverage is 100%, so the baseline is 3. The description adds slight value by clarifying that 'body' is a PxWeb query object, but the schema already provides a detailed format specification.

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 pulls data from a table, specifying a verb and resource. However, it does not explicitly differentiate from the sibling tool 'table_meta', though the distinction is implied by 'pull data' versus metadata.

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 offers a usage tip about PxWeb cell limits, guiding the agent to narrow dimensions. It does not provide explicit when-to-use or when-not-to-use guidance relative to other sibling tools, but the context is clear enough.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds scoping and pairing context, 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?

Three sentences, front-loaded with main purpose, no unnecessary verbosity.

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 retrieval tool with complete annotations and schema; description covers scoping, usage, and sibling interactions.

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%, describing the 'key' parameter. Description adds value by explaining omission lists all keys, but this is minimal addition.

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 retrieves a value saved via 'remember' or lists all keys if omitted, distinguishing it from its sibling tools '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?

Provides clear when-to-use context for looking up stored and how to list all keys. Does not explicitly say when not to use, but the sibling tools cover those 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?

Description discloses parallel fan-out to three sources, fallback logic, USPTO API sunset soft-fail, and return format (structured changes[], total_changes count, citation URIs). Annotations already indicate readOnly, openWorld, idempotent, non-destructive; description adds valuable behavioral context 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?

Single paragraph is dense but well-organized: starts with user intent, then technical details, then parameter description, return format, and alternative. Slightly long but every sentence adds value; could benefit from bullet points but is acceptable.

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 explains return format and citation URIs. Covers all inputs, behavior (parallel fan-out, fallback, API dependencies), and alternative tool. Complete for a complex tool with three sources and fallback logic.

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 parameters fully, but description adds useful details: 'since' accepts ISO date or relative shorthand with examples ('7d','30d','3m','1y'), 'value' can be ticker or CIK, 'type' is limited to 'company'. This aids correct invocation.

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

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

The description clearly states it retrieves what's new with a company (SEC filings, news, patents) in a time window, with example queries like 'what's happening with X'. It distinguishes from sibling tool 'entity_profile' by noting the latter is for static profiles.

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

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

Explicitly says when to use ('what's happening with X', 'news on Apple this month') and when to use alternative ('Use entity_profile instead when you want the static profile...'). Also explains fallback behavior (GDELT to GNews).

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 idempotent and non-destructive. Description adds critical context: key-value scoping by identifier, persistent vs. 24-hour retention, and 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?

Four sentences, front-loaded with purpose, each sentence essential. No redundancy or fluff.

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

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

Description covers purpose, usage, behavior, and parameters. No output schema exists, but for a write tool, return values are implied; could mention success indication, but not critical.

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

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

Schema provides descriptions for both key and value. Description adds examples for key (e.g., 'subject_property') and clarifies value as 'any text', adding modest 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?

The description starts with 'Save data the agent will need to reuse later', clearly stating the verb (save) and resource (data). It distinguishes from sibling tools like recall and forget by naming 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?

Explicitly says 'Use when you discover something worth carrying forward' and pairs with recall/forget. Also notes scope and persistence differences, providing clear guidance on when to use.

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

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

Annotations already provide readOnlyHint, idempotentHint, etc. The description adds that it cascades through several lookup endpoints and replaces manual lookups, which is useful context beyond annotations. No contradictions.

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

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

The description is informative and front-loaded with purpose and usage. It is somewhat long but every sentence adds value; could be slightly more concise 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?

No output schema, but the description thoroughly explains return values for both types (ticker, CIK, company name, URI for company; RxCUI, ingredient, brand, URI for drug). Covers inputs and transformations, making the tool fully self-contained.

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

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

Schema coverage is 100% with descriptions for both parameters. The description adds examples for accepted inputs (e.g., ticker, CIK, name) and explains return values per type, enhancing the schema's meaning.

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

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

The verb 'resolve' is specific, and the description clearly maps user-spoken names to canonical identifiers. It distinguishes from siblings by stating 'other tools require as input' and 'use first when you have a name but need an ID.' Supported types are detailed with return values.

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 context. It does not list explicit alternatives, but the sibling tools suggest no direct replacement, so the guidance 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 already declare readOnlyHint, idempotentHint, and nondestructive behavior. The description adds that it probes each entity via 'ai_visibility_check', ranks results, and returns score/confidence/signal density per entity—information beyond annotations. No contradictions; it enriches behavioral understanding.

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; the first clearly states the main action, the second provides context and output. It is front-loaded and concise, though the second sentence is somewhat long. Every phrase serves a purpose, making it efficient.

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

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

Given the tool's complexity (multi-entity comparison, calling another tool), the description explains the workflow, behavior, output structure, and use case. No output schema exists, but the description outlines return fields (score, confidence, signal density). It adequately equips an agent to decide 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?

With 100% schema description coverage, baseline is 3. The description adds meaning: for 'entities', it notes the first is the subject; for 'models', it clarifies omission defaults to workers-ai; for '_apiKey', it explains its purpose and transmission; for 'context', it specifies disambiguation. This elevates parameter understanding beyond 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 states the tool compares AI visibility across multiple entities side-by-side, probes each entity, ranks by score, and identifies most/least recognized. It differentiates from siblings like 'ai_visibility_check' (single entity) and 'compare_entities' (likely broader comparison), making its specific function 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?

The description explicitly labels the tool as useful for competitive AI-marketing audits and provides a concrete example question. While it implies when to use (multi-entity comparison), it does not state when to avoid it or mention alternatives explicitly. The context is clear, but lacks explicit 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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds significant behavioral context beyond these: it details the sources (deps.dev, bundlephobia), explains partial failure handling with a timeout (5-30s) and a 'sources_failed' field, describes the return format (summary block, per-advisory detail, links, alternative versions), and notes the ecosystem limitation. This provides a comprehensive understanding of the tool's behavior.

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

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

The description is information-dense but well-structured, with sentences covering purpose, use cases, return fields, ecosystem scope, and failure behavior. Every sentence adds value, though it is slightly long for a tool with only two parameters. It could be marginally shorter, but the content is necessary given the tool's composite nature.

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

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

Given no output schema, the description fully explains the return value, including specific summary fields, advisory details, links, and alternative versions. It also addresses timing issues and partial failures. The ecosystem limitation is noted. This provides a complete picture for an agent to invoke and interpret 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 descriptions for both parameters (package name, version), achieving 100% coverage. The description reinforces that version defaults to latest when omitted and explicitly mentions acceptance of scoped packages (e.g., '@types/node'), which is not in the schema description. This adds useful context beyond the schema, justifying a score 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 identifies the tool as a composite check for npm packages, aggregating data from deps.dev and bundlephobia. It specifies the ecosystem (npm only in v1) and distinguishes it from other tools by being a composite, single-call solution. The use of specific verbs and resource names makes the purpose unambiguous.

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

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

The description explicitly states when to use the tool: 'whenever an agent asks 'is X safe / popular / small' or 'what does adding lodash cost me'.' It also provides exclusion criteria, noting that non-npm ecosystems fall under deps.dev:version directly. This gives clear guidance on when to use and when not to use this 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, openWorldHint, etc. The description adds that items have types 'l' (folder) and 't' (table with id ending in '.px'), providing useful behavioral detail 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 with no wasted words, efficiently covering purpose and key structural details.

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

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

Given the simple tool with one optional parameter and no output schema, the description adequately explains the behavior, return structure (folder vs table), and example usage. It feels complete for a navigation tool.

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

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

Schema coverage is 100%, so the parameter is described. The description adds context about the path meaning (empty returns database list, example 'Statistik'), enhancing understanding beyond 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 states the tool navigates the subject tree, using a specific verb and resource. It distinguishes from siblings like 'query_table' and 'table_meta' which focus on data retrieval rather than structural navigation.

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 usage context (empty path returns database list, drill into 'Statistik'), but does not explicitly state when to use this tool vs alternatives or when not to use it.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the tool is clearly non-destructive. The description adds a specific path format constraint (must end in '.px'), which is behavioral context beyond what annotations offer.

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 succinct sentences that efficiently convey purpose and a key constraint with zero wasted words.

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

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

For a simple one-parameter tool with full annotation coverage and no output schema, the description adequately covers usage scope, parameter semantics, and constraints. No additional context is necessary.

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 provides an example for 'path' (100% coverage), but description adds the critical constraint that the path must end in '.px'. This adds value beyond the schema by clarifying a required format detail.

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

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

Description states 'Table definition (dimensions, valid values)' which clearly indicates it returns metadata about a table, not data. The constraint on path suffix adds specificity. It distinguishes effectively from siblings like 'query_table' which likely retrieves data.

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

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

The description implies usage for retrieving table structure before querying, but does not explicitly state when to use this tool versus alternatives like 'query_table'. No direct contrast or use case exclusions are provided.

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 that the tool is read-only, idempotent, and non-destructive, which aligns with the annotations. It adds context by stating it replaces 4-6 sequential calls and lists the possible verdicts. It also notes scope limitations (v1 supports company-financial claims). 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 well-structured: it starts with action verbs, explains use cases, specifies domain, and lists return values. While slightly verbose, each sentence adds value. It is front-loaded with the core purpose.

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

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

Given the tool has only one parameter and annotations present, the description covers the essential aspects: what it does, when to use it, its domain, and what it returns. It lacks explicit output structure details, but the verdict types are enumerated. Without an output schema, this is 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?

The single parameter 'claim' has a clear description in the schema. The tool description adds meaning by providing examples of what the claim should look like (e.g., 'Apple's FY2024 revenue was $400 billion'), which goes beyond the schema's generic 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's purpose: fact-checking/validating natural-language claims against authoritative sources. It gives specific examples of when to use it, like 'Is it true that…?', and delineates the supported domain (company-financial claims). This distinguishes it from sibling tools like ask_pipeworx or query_table, which serve different functions.

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

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

The description explicitly states when to use the tool: for checking factual claims. It provides example phrasings. However, it does not explicitly mention when not to use it or point to alternatives among the siblings, though the domain restriction (company-financial) implies when it's not applicable.

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