fuiwanted

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

Annotations already declare safety (readOnlyHint, openWorldHint), and the description adds context about key requirements (BYO Anthropic key) and default free model. No contradictions; useful extra detail on auth and cost implications.

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 redundancy. Each sentence provides essential information: function, default/free usage, key requirement, return format, and use cases. Efficient 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 no output schema, the description explicitly mentions return structure (per-model {score, confidence, signals, raw_response}) and combined view. All parameters and key behaviors (default model, key passing) are covered, making the tool's usage clear.

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

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

Schema coverage is 100%, satisfying baseline for score 3. The description adds meaning beyond schema by clarifying default model, key necessity, and context disambiguation role.

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 begins with a clear verb ('Probe one or more LLMs') and specific resource ('visibility, 0-100 per model'), and the tool's purpose (AI-marketing audits, brand checks) distinguishes it from siblings like 'ask_pipeworx' 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?

The description explicitly states when the tool is useful (AI-marketing audits, pre-launch brand checks, competitive monitoring) and explains default vs. BYO key models. However, it does not contrast with or exclude sibling tools.

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

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

No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: the tool selects data sources and fills arguments automatically, and it handles natural language questions. However, it lacks details on limitations (e.g., data scope, accuracy), error handling, or response format, which are important for a tool with no output schema.

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

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

The description is front-loaded with the core purpose, followed by operational details and examples. Every sentence adds value: the first explains the tool's function, the second describes how it works, and the third provides concrete examples. It is efficiently structured without wasted words.

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

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

Given the tool's complexity (natural language processing with automatic tool selection) and lack of annotations/output schema, the description does well by explaining the mechanism and providing examples. However, it could be more complete by mentioning potential limitations or the types of data sources available, which would help set expectations for the 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?

The schema description coverage is 100%, with the parameter 'question' well-documented. The description adds value by emphasizing 'plain English' and 'natural language,' clarifying the expected input style beyond the schema's 'question' definition. With only one parameter, this extra context is sufficient for a high score.

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

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

The description clearly states the tool's purpose: 'Ask a question in plain English and get an answer from the best available data source.' It specifies the verb ('ask'), resource ('answer'), and mechanism ('Pipeworx picks the right tool, fills the arguments'). It distinguishes itself from siblings by emphasizing natural language input versus browsing specific tools.

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

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

The description explicitly states when to use this tool: 'No need to browse tools or learn schemas — just describe what you need.' It provides clear alternatives by implication (use other tools for browsing or schema-based queries) and includes specific examples like 'What is the US trade deficit with China?' to illustrate appropriate use cases.

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

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

The description extensively discloses behavioral traits beyond annotations: fan-out logic, classifier categories, response shapes, resolver contract with match confidence, parent event extraction, news fallback handling, and safety mechanisms (low-confidence stops, closed market handling). Annotations already signal readOnly and idempotent, and the description aligns perfectly without contradiction.

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

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

The description is front-loaded with the main purpose and use cases, but it is quite verbose. It includes extensive examples and details that, while valuable, could be more succinctly organized. Some redundancy exists (e.g., explaining closed markets twice). Still, the structure is logical and informative.

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

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

Given the tool's complexity and lack of output schema, the description is remarkably complete. It covers input handling, classification, data sources, response fields, edge cases (low confidence, closed markets, illiquid spreads), and even fallback mechanisms. An agent can understand exactly what to expect and how to interpret results.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaningful context: it explains the effects of the 'depth' parameter (quick vs thorough), clarifies 'market' input types, and details the 'include_raw' parameter's impact on response size. This goes beyond the schema descriptions, 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 researches Polymarket bets by pulling Pipeworx data. It gives specific input examples (slug, URL, question text) and explicitly mentions use cases like 'should I bet on X'. It distinguishes from sibling tools by focusing on single-bet research, while siblings like polymarket_edges or polymarket_arbitrage target different tasks.

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 (e.g., evaluating a bet) and warns about fuzzy matches by instructing to inspect market_match_confidence. It also explains closed market behavior. However, it does not explicitly state when to use alternative tools, though the differentiation is implicit.

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

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

With no annotations provided, the description carries full burden. It discloses the operation (comparison), data sources (SEC EDGAR, FDA), and return format (paired data + resource URIs). It does not mention permissions or side effects, which is acceptable for a read-heavy tool. A 5 would require explicit mention of limitations or error handling.

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 (3 sentences) and front-loaded with the main purpose. Every sentence adds value: comparison scope, type-specific details, and efficiency note. 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?

Given the tool's complexity (two entity types, multiple data points), the description provides sufficient context. It explains what data is compared and mentions return format. Lacking an output schema, it still gives a good picture. A 5 would require explicit mention of error handling or data freshness.

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 listing specific data fields for each type and mentioning resource URIs in the output, which aids the agent in understanding the return beyond the schema's parameter descriptions.

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

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

The description clearly states the tool compares 2-5 entities side by side, specifies the data returned for each type (company: revenue, net income, etc.; drug: adverse-event reports, etc.), and distinguishes itself as a batch comparison tool replacing sequential calls. This differentiates it from siblings like resolve_entity or search_wanted.

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 this tool: to compare multiple entities in one call, with specific entity types and data points. It notes efficiency gains ('Replaces 8–15 sequential agent calls'). However, it does not explicitly state when not to use it or mention alternatives, which would make it a 5.

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

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

No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: the tool searches a catalog, returns relevant tools, and should be called first in high-tool contexts. However, it lacks details on rate limits, authentication needs, or error handling, which are important for a search tool with no output schema.

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

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

The description is appropriately sized and front-loaded, with two sentences that efficiently convey purpose and usage guidelines without redundancy. Every sentence adds value, making it concise and well-structured for quick understanding.

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 (search functionality with 2 parameters) and lack of annotations or output schema, the description is mostly complete. It covers purpose, usage context, and behavioral aspects, but could improve by mentioning response format or limitations. It adequately compensates for the missing output schema by specifying what is returned.

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 schema already documents both parameters ('query' and 'limit') thoroughly. The description adds no additional parameter semantics beyond what the schema provides, such as examples or usage tips for the query parameter. Baseline 3 is appropriate as the schema handles the heavy lifting.

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

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

The description clearly states the tool's purpose with specific verbs ('Search the Pipeworx tool catalog') and resources ('tool catalog'), and distinguishes it from siblings by emphasizing its role in finding tools among 500+ options. It explicitly mentions returning 'most relevant tools with names and descriptions,' making the outcome transparent.

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 ('Call this FIRST when you have 500+ tools available and need to find the right ones for your task'), including a specific condition (500+ tools) and priority (FIRST). It implicitly distinguishes from siblings by focusing on tool discovery rather than direct data searches like 'get_wanted_person' or 'search_wanted'.

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?

Descriptions adds behavioral details not covered by annotations: USPTO PatentsView API soft-fail, GDELT→GNews fallback, and response structure. 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?

Front-loaded with example queries and highly informative, though slightly long. Every sentence adds value; minor room for trimming.

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

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

Given no output schema, the description adequately covers return fields, data sources, fallbacks, and limitations. Handles complexity well.

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 already covers parameter descriptions at 100%. Description adds value by specifying exact formats (ticker or zero-padded CIK) and noting that names are unsupported.

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

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

The description clearly states the tool creates a full cross-source profile of a US public company in one call, with specific example queries. It distinguishes from siblings like resolve_entity and compare_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?

Explicitly says to prefer this tool over chaining single-pack lookups for holistic views, and instructs to use resolve_entity first if only a name is given. Provides clear when-to-use and alternatives.

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

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

With no annotations, the description carries full burden. It discloses the destructive nature ('Delete'), but lacks critical behavioral details: whether deletion is permanent or reversible, what happens if the key doesn't exist (error vs. silent failure), permission requirements, or rate limits. This is inadequate for a mutation tool.

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

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

The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action ('Delete'), making it immediately clear. Every word 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 destructive tool with no annotations and no output schema, the description is insufficient. It doesn't explain what constitutes a 'stored memory', the deletion's permanence, error handling, or return values. Given the complexity of a delete operation, more context is needed.

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

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

Schema description coverage is 100%, with the single parameter 'key' documented as 'Memory key to delete'. The description adds no additional meaning beyond this, merely restating 'by key'. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the action ('Delete') and resource ('a stored memory by key'), making the purpose unambiguous. It doesn't explicitly differentiate from sibling tools like 'recall' or 'remember', but the verb 'Delete' strongly implies a destructive operation distinct from retrieval or creation.

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

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

No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing an existing memory key), exclusions, or relationships with siblings like 'recall' (which likely retrieves memories) or 'remember' (which likely creates them).

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

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

Annotations indicate read-only, idempotent, non-destructive. Description adds value by explaining it fetches a page, extracts content, and emits markdown. No contradiction. Could mention error handling or output format beyond 'text blob' but overall strong.

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. Every sentence adds value with no filler. Front-loaded with key verb 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?

Output format is described as a single text blob. Input parameters are covered in schema. Lacks details on error behavior (e.g., unreachable URL) but sufficient for a straightforward generation 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 has 100% coverage with descriptions for both parameters. Description only adds an example for URL but does not reference max_links parameter or its default. Baseline at 3 is appropriate since schema carries the load.

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 generates an llms.txt file for any URL, with explicit mention of AI crawlers and specific use cases. It distinguishes itself from siblings like scan_competitor_ai_presence and ai_visibility_check by focusing on file generation.

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

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

Provides explicit use cases (client's site, own project, auditing competitor). However, it does not mention when not to use the tool or suggest alternatives among sibling tools.

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

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

No annotations are provided, so the description carries the full burden. It states the tool retrieves 'full details', which implies a read-only operation, but does not disclose behavioral traits like error handling, rate limits, or authentication needs. The description is minimal but not contradictory.

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, efficient sentence that front-loads the purpose without unnecessary words. Every part of the sentence contributes to understanding the tool's function.

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

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

Given the tool's low complexity (one parameter, no output schema), the description is complete enough for basic use. However, without annotations or output schema, it lacks details on return values or potential errors, which could be helpful 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?

The schema description coverage is 100%, with the parameter 'uid' fully documented in the schema. The description adds no additional meaning beyond the schema, such as format examples or constraints, so it meets the baseline for high schema coverage.

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

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

The description clearly states the verb ('Get') and resource ('full details for a specific FBI Wanted person'), specifying the exact operation. It distinguishes from the sibling tool 'search_wanted' by focusing on retrieval of a single person by UID rather than searching.

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 context by specifying 'by their UID', indicating this tool is for retrieving details when the UID is known. However, it does not explicitly state when not to use it or name alternatives, though the sibling tool name suggests a search function.

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?

With no annotations provided, the description carries the full burden. It discloses the rate limit (5 per identifier per day) and a privacy guideline (omit end-user prompt). The behavioral impact is minimal (sending feedback), and these disclosures are sufficient for safe invocation.

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

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

The description is extremely concise: three sentences cover purpose, usage categories, a privacy instruction, and rate limit. Every sentence serves a distinct purpose with no redundancy.

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

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

For a simple feedback tool, the description covers the essential aspects: what it does, when to use, rate limiting, and content guidelines. No output schema exists, but the return value is likely trivial. The description is complete enough to enable confident invocation.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by instructing the agent to describe what was tried in terms of Pipeworx tools/data, which enhances the message parameter beyond the schema's length constraint. It also reinforces the enum meanings without repeating them verbatim.

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

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

The description clearly states the verb 'Send feedback' and the resource 'Pipeworx team'. It lists specific use cases (bug reports, feature requests, missing data, praise), effectively distinguishing it from sibling tools like ask_pipeworx or discover_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 explicit contexts for use ('bug reports, feature requests, missing data, or praise') and a critical constraint ('do not include the end-user's prompt verbatim'). It also mentions the rate limit (5 per day). While it doesn't directly name alternatives, the scope is clear enough that an agent can infer when to use this tool versus others.

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 and idempotent behavior. The description adds valuable context: 'self-aggregating signal', derived from CF analytics-engine, no PII, and caching of 5min-1h. This goes beyond annotations to fully disclose 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 concise and well-structured. It front-loads the main purpose, then lists three bullet-point use cases, followed by data source and caching details. Every sentence adds value without redundancy.

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

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

For a simple tool with one optional parameter and no output schema, the description is complete. It explains input options, expected output (top tools, top packs, total call volume), data derivation, and caching. No significant 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?

The input schema has one parameter with enum and description. The description adds extra semantics: 'Shorter windows surface what's hot right now; longer windows show steady-state demand.' This provides decision-making guidance beyond the schema's basic 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: returning top tools, top packs, and total call volume over a recent window. It specifies the verb 'returns' and the resource 'what other AI agents are calling on Pipeworx'. This distinguishes it from sibling tools like discover_tools or ask_pipeworx.

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

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

The description explicitly lists three use cases: discovering hot data sources, confirming popular tools, and checking alignment with agent needs. It also mentions the data source and caching behavior. While it doesn't explicitly state when not to use, the context is clear and helpful.

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

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

Description adds extensive context beyond annotations: explains monotonicity checks, partition sum calculation, Jaccard similarity threshold, placeholder filtering, and response structure. 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?

Highly informative but somewhat verbose. Front-loaded with requirement and mode distinction, but contains technical details that are necessary for correct usage. Some redundancy, but still well-organized.

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?

Comprehensively covers both modes, algorithm details, filtering criteria, and response structure. No output schema, so response description is essential and provided in detail.

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

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

Schema coverage is 100%, but description adds value by explaining modes, providing example slugs, and noting that full Polymarket URLs are accepted. 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 clearly states the tool finds arbitrage opportunities on Polymarket via monotonicity violations and partition-sum checks. It distinguishes two modes (event and topic), provides examples, and differentiates from siblings like polymarket_edges and polymarket_kalshi_spread.

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 requirement for one of event or topic, recommends event for specific markets, and explains cross-event mode for scanning across events. Provides parameter examples and clarifies call with no args fails.

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 readOnlyHint and idempotentHint annotations, the description discloses extensive behavioral traits: caching at 1h keyed on knobs, internal logic of five model families, diagnostic sections (fed_note, _diagnostics), and filtering criteria (placeholder-slug filter, partition gate rules). No contradiction with annotations.

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

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

The description is a single dense paragraph but each sentence adds value. It front-loads the core purpose and systematically covers model families, response structure, and knobs. Though not bulleted, the logical grouping (by_segment, knobs, diagnostics) makes it navigable.

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, no output schema), the description is remarkably complete. It explains return structure (by_segment, diagnostics), why Fed bets are excluded, caching behavior, and how knobs interact. An agent can fully understand what to expect and how to 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 baseline is 3. The description adds context for many parameters (e.g., min_liquidity explained as dropping thin-book opportunities, min_partition_leg_kelly explained for partition overround), enriching the schema's basic definitions and clarifying tradeable-edge filters.

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 scans Polymarket markets and returns opportunities where Pipeworx data disagrees with market price. It uses specific verb 'scan' and resource 'opportunities', and the detailed explanation of segments (model_driven, structural_arbitrage, concentrated_longshot) distinguishes it from siblings like polymarket_arbitrage and polymarket_kalshi_spread.

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 explains the three segments and adjustable knobs. While it doesn't directly compare against sibling tools or state when not to use, the context is clear for discovery purposes, and the detailed parameters guide proper usage.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds rich behavioral context: response structure (leg-by-leg prices, spreads), safety fields (compatibility_warning with two cases, temporal_alignment), and explanation of skipped cross types. 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 fairly long but well-structured with bold labels for sections (TWO MODES, RESPONSE, SAFETY FIELDS). Every sentence adds value, but some details could be more concise. Overall, it is front-loaded with key information.

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

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

Given the tool has no output schema and 3 parameters, the description thoroughly explains the response structure, all safety fields, and temporal alignment. It fully compensates for the lack of output schema and leaves no ambiguity about what the tool returns.

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 meaning by explaining the two modes and providing examples for the topic parameter. It also clarifies the override behavior for explicit tickers. This goes beyond the schema's minimal descriptions.

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

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

The description clearly states it computes the cross-venue spread between Kalshi and Polymarket for the same resolving question. It distinguishes itself from siblings like polymarket_arbitrage by focusing on cross-venue spreads, and from polymarket_edges which is single-venue. The verb 'compute spread' and resource 'same resolving question' are specific.

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

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

The description explicitly explains two modes: topic shortcuts for quick access and explicit tickers for custom pairings. It provides guidance on when to use each, and includes a warning that most pre-mapped topics may not be tradeable. This helps the agent decide when to use the tool versus alternatives.

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

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

With no annotations provided, the description carries full burden. It discloses key behavioral traits: the tool can retrieve by key or list all memories, works across sessions, and accesses 'previously stored' data. However, it doesn't mention error handling (e.g., what happens if key doesn't exist), performance characteristics, or whether listing all memories has pagination/limits.

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

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

The description is perfectly concise with two sentences that each earn their place. The first sentence explains the core functionality, the second provides usage context. No wasted words, front-loaded with the most important information.

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

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

Given no annotations and no output schema, the description provides adequate but incomplete context. It covers the basic functionality and usage scenario, but doesn't describe return values, error conditions, or performance limits. For a memory retrieval tool that might return complex data, more output information would be helpful.

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

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

The schema has 100% description coverage, so the baseline is 3. The description adds meaningful context beyond the schema by explaining the dual functionality (retrieve vs list) and the semantic meaning of omitting the key parameter. It clarifies that 'omit key' triggers listing behavior, which isn't obvious from 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's purpose with specific verbs ('retrieve', 'list') and resources ('previously stored memory', 'all stored memories'). It distinguishes between retrieval by key and listing all memories, but doesn't explicitly differentiate from sibling tools like 'remember' or 'forget' beyond mentioning 'context you saved earlier'.

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 for when to use the tool ('to retrieve context you saved earlier in the session or in previous sessions') and includes operational guidance ('omit key to list all keys'). However, it doesn't explicitly state when NOT to use this tool or mention alternatives among the sibling tools.

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

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

Details fan-out to multiple sources (SEC, GDELT/GNews, USPTO), fallback strategy, and soft-fail conditions. Adds behavioral context beyond annotations, which already indicate read-only, idempotent, non-destructive.

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?

Compact yet comprehensive; each sentence serves a purpose. Begins with typical use-case phrases, then explains operation, parameter details, and alternative tool. 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?

Covers all parameters, return structure (grouped changes, count, URIs), and fallback behavior. No output schema, but description sufficiently explains output. Complete for a list tool with good annotations.

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?

Explains 'since' format (ISO or relative shorthand) with examples, 'value' as ticker or CIK, and 'type' as enum with supported value. Schema coverage is 100%, but description adds practical usage guidance.

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

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

Description clearly states the tool provides a change feed for a company over a time window, using phrases like 'what's new' and 'latest updates'. It distinguishes from sibling tool entity_profile by specifying that entity_profile is for static profiles regardless of window.

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 (for time-windowed updates) and when not to (for static profiles, use entity_profile). Provides query patterns and parameter examples.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: the tool performs a write operation (storing data), specifies persistence characteristics (authenticated users get persistent memory, anonymous sessions last 24 hours), and mentions the cross-tool context capability. However, it doesn't cover potential limitations like storage size or rate limits.

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

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

The description is perfectly concise with two sentences that each earn their place. The first sentence states the core functionality, and the second sentence adds crucial behavioral context about persistence differences. There's zero waste or redundancy in the 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?

For a write operation tool with no annotations and no output schema, the description provides good contextual completeness. It covers the tool's purpose, usage scenarios, and key behavioral traits (persistence characteristics). However, it doesn't specify what happens on success/failure or return values, which would be helpful given the lack of output schema.

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

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

Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description doesn't add any additional parameter semantics beyond what's in the schema - it mentions 'key-value pair' but doesn't provide further context about parameter usage, format requirements, or constraints. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the tool's purpose with specific verb ('Store') and resource ('key-value pair in your session memory'), and distinguishes it from siblings by mentioning persistence across tool calls. It goes beyond the name 'remember' by explaining what kind of data can be stored and the memory scope.

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

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

The description provides explicit guidance on when to use this tool ('save intermediate findings, user preferences, or context across tool calls') and distinguishes it from alternatives by specifying persistence differences for authenticated vs. anonymous users. It gives clear context for application without misleading information.

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?

With no annotations provided, the description carries the full burden. It discloses that the tool is a single call, lists exact return fields (ticker, CIK, company name, resource URIs), and implies a read-only operation through the verb 'resolve'. No side effects, destructive actions, or rate limits are mentioned, but the simplicity of the operation makes this acceptable.

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

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

The description is extremely concise, consisting of two short sentences. The first sentence defines the core purpose, and the second provides version-specific details and examples. Every word contributes value with zero 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 covers return values. It lists all returned fields and mentions the resource URIs for stable citation. For a simple entity resolution tool with two parameters, this is nearly complete. Minor gaps like error handling or no-match behavior are not critical for a straightforward lookup.

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

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

Schema coverage is 100%, but the description adds value beyond the schema by providing concrete examples (e.g., 'AAPL', '0000320193', 'Apple') and clarifying that the type enum currently only supports 'company'. This helps agents understand valid inputs better than 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's purpose: resolving an entity to canonical IDs in a single call. It specifies the supported type (company), acceptable input formats (ticker, CIK, name), and return values (ticker, CIK, company name, resource URIs). This makes it distinct from sibling tools which are unrelated.

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 for usage by noting it replaces 2–3 lookup calls, implying efficiency gains. It explicitly states v1 only supports 'company' type, but does not give explicit when-not-to-use scenarios or alternatives. However, sibling tools are sufficiently different that confusion is unlikely.

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

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

Discloses that it probes each entity via ai_visibility_check, ranks by score, and surfaces most/least recognized. Annotations already indicate read-only and idempotent behavior; the description adds depth by explaining the internal process and output structure (score, confidence, signal density).

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 clear, front-loaded sentences followed by an efficient expansion. Every sentence adds value without redundancy or filler, keeping the description tight.

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

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

No output schema exists, but the description compensates by detailing the return format (ranked list with score, confidence, signal density). It explains the tool's internal mechanism and intended use case, though it omits error scenarios or rate limits, which are minor gaps for a read-only 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 minor value by clarifying the 'entities' first entry is treated as the subject and that context disambiguates common names, but does not significantly expand 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 'Compare AI visibility across multiple entities side-by-side', specifying a concrete verb (compare) and resource (AI visibility). It distinguishes itself from sibling ai_visibility_check by focusing on multi-entity comparison and ranking.

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 notes the tool is 'Useful for competitive AI-marketing audits' and provides an example question. While it does not explicitly state when not to use it, the context implies its purpose vs single-entity checks, and it gives specific guidance on entity ordering.

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 behavior. The description adds transparency about partial failures, slow first measurement, and graceful degradation, which is beyond annotation requirements.

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

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

The description is moderately long but each sentence adds value. It is front-loaded with the core purpose and well-structured with usage, returns, and limitations. Slightly verbose but still efficient.

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

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

Given no output schema, the description comprehensively lists all return fields and explains edge cases like partial failures and timing. It fully equips the agent to understand the tool's behavior.

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

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

Schema coverage is 100% with descriptions for both parameters. The tool description does not add new meaning beyond what the schema provides, so baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: a composite check for adding an npm package, combining multiple sources. It uses specific verbs ('scan', 'fans out') and distinguishes from siblings by explicitly limiting to NPM ecosystem and listing specific returned fields.

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 ('is X safe / popular / small' questions) and what not to use on (other ecosystems like PyPI, Maven), providing clear context for agent 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?

No annotations are provided, so the description carries the full burden. It mentions pagination and optional filtering, which adds some behavioral context, but it doesn't disclose critical traits like rate limits, authentication needs, error handling, or the format of results (e.g., list structure, fields returned). For a search tool with no annotation coverage, this is a significant gap.

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

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

The description is two sentences, front-loaded with the core purpose and efficiently covering optional features without waste. Every sentence adds value, making it appropriately sized and well-structured.

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

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

Given the tool's moderate complexity (search with filtering/pagination), no annotations, and no output schema, the description is minimally adequate. It covers the purpose and parameters but lacks details on behavioral traits and result format, leaving gaps that could hinder an agent's ability to use it effectively.

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

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

Schema description coverage is 100%, so the schema already documents both parameters ('page' and 'query') with clear descriptions. The description adds marginal value by reinforcing that 'query' can filter by 'name, crime type, etc.' and that omitting it lists all, but this doesn't go beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the verb ('Search') and resource ('FBI Most Wanted list'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from the sibling tool 'get_wanted_person', which might be for retrieving a specific person versus searching/filtering a list.

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

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

The description implies usage by mentioning optional filtering and pagination, suggesting when to use it for broader searches. However, it lacks explicit guidance on when to use this tool versus the sibling 'get_wanted_person' (e.g., for list vs. detail views) or any exclusions, leaving some ambiguity.

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, idempotentHint, and openWorldHint. The description adds valuable behavioral context: how claims are processed (via SEC EDGAR + XBRL), detailed return format (verdict, structured form, citation, percent delta), and efficiency improvements (replaces 4-6 calls). This goes beyond annotations without contradicting them.

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

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

The description is relatively long but well-structured: it begins with trigger phrases, states purpose and usage, outlines scope, details return values, and highlights efficiency. Each sentence conveys essential information, and the structure is logical, though minor trimming could be possible 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 (single param, no output schema), the description thoroughly explains what it does, what it supports (company-financial claims), and its output (verdict, structured form, citation, delta). It compensates for the lack of an output schema by describing return values in detail, making it complete for the 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 coverage is 100%, with the 'claim' parameter described as 'Natural-language factual claim.' The description enhances this by explaining how the parameter is used (parsed, verified) and provides examples, adding meaning beyond the schema's basic type/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 defines the tool's function: natural-language claim verification against authoritative sources. It includes trigger phrases (e.g., 'fact check', 'verify the claim that...') and distinguishes this tool from siblings by noting it replaces multiple sequential calls, making its purpose distinct 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 explicitly states when to use: 'Use whenever the agent needs to check whether something a user said is factually correct.' It provides specific use cases and notes scope limitations (company-financial claims for public US companies), effectively guiding the agent on appropriate contexts.

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