Sbir

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

Annotations already declare readOnlyHint, idempotentHint, and nondestructive behavior. The description adds behavioral context: default model is free, Anthropic probes require BYO key and incur direct costs, and it returns per-model data plus combined view. This enriches beyond annotations.

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

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

The description is a single paragraph with four sentences, providing all essential information without fluff. It could be slightly more structured but is appropriately sized and front-loaded with the core purpose.

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

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

For a tool with 4 parameters (100% schema coverage), no output schema, and helpful annotations, the description explains optional parameters, return format, and use cases. It is adequately complete for the agent to select and invoke the tool correctly.

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

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

With 100% schema coverage, baseline is 3. The description adds meaning: default model is Workers AI Llama-3.3-70b (free), _apiKey needed only for Anthropic, context disambiguates, and it describes the return structure (score, confidence, signals, raw_response).

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 entity visibility and scores it per model, specifying the verb 'probe' and resource. It distinguishes from siblings like 'scan_competitor_ai_presence' by being more general and mentioning default model and BYO key for Anthropic.

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 outlines use cases (AI-marketing audits, pre-launch brand checks, competitive monitoring) and explains when to use optional parameters (_apiKey for Anthropic, context for disambiguation). No explicit when-not-to use, but the context is clear.

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

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

No annotations are provided, so the description must cover behavioral traits. It mentions the tool 'picks the right tool, fills the arguments, and returns the result', indicating it automates tool selection and parameter filling. However, it does not disclose any limitations, data freshness, or potential errors. The description is somewhat vague about what happens behind the scenes, earning a moderate score.

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 at three sentences plus examples, front-loading the core action. Each sentence adds value: what it does, how it works, and examples. The examples are helpful but add length; still, it remains well-structured and avoids redundancy.

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

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

Given the tool's simplicity (one parameter, no output schema, no annotations), the description is largely complete. It explains the purpose, behavior, and provides examples. It could mention that results may vary by data source, but overall it covers the essential context for an agent to decide to use this tool.

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

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

Schema coverage is 100% with only one parameter ('question'). The description adds meaning by explaining that the question should be in natural language and gives examples, which goes beyond the schema's 'Your question or request in natural language'. However, since the schema already provides a clear description, the additional value is modest, yielding a baseline score of 3.

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

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

The description clearly states the tool takes a natural language question and returns an answer, using 'Ask a question' and 'get an answer'. It distinguishes itself from siblings by emphasizing it automatically selects the best data source and fills arguments, which no other sibling tool does.

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

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

The description provides explicit usage guidance: 'just describe what you need' and gives three examples. It does not explicitly state when not to use it or mention alternatives, but the context of being a general question-answering tool with specific examples implies it's for broad queries. The lack of negative examples or comparisons to siblings slightly reduces the score.

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 (readOnlyHint, openWorldHint, destructiveHint false) are complemented by detailed behavioral context: the tool resolves the market, classifies bet type, fans out to specific data packs (e.g., crypto+fred+gdelt), and returns evidence with comparison. 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 dense and informative, front-loading the main action. While slightly long (4 sentences), every sentence adds value. Minor trim could improve conciseness but current structure is 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?

Though no output schema is provided, the description fully explains the return: evidence packet plus market-vs-model comparison. It also covers input flexibility, classification logic, and data fan-out. Complete for an agent to understand and 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 coverage is 100% with clear descriptions for both 'market' and 'depth'. The description adds significant meaning: 'market' accepts slug, URL, or question text; 'depth' values 'quick' and 'thorough' are explained with defaults and fan-out 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 the tool researches a Polymarket bet by pulling Pipeworx data, resolving the market, classifying the bet, and returning evidence. It specifies input formats (slug, URL, question text) and distinguishes from sibling tools by being specialized for Polymarket bet analysis.

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

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

The description explicitly lists three use cases ('should I bet on X?', 'what does the data say about this Polymarket market?', 'is there edge in this bet?'), providing clear guidance on when to use. It does not explicitly mention alternatives or when not to use, but the context is sufficient for selection among siblings.

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

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

No annotations are provided, so the description must disclose behavioral traits. It details data sources (SEC EDGAR, FAERS) and return format (paired data + citations), but does not mention rate limits or authentication needs. For a query tool, this is adequate.

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

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

The description is a single coherent paragraph that efficiently states purpose, usage, and data sources. It is front-loaded with the core function. Minor improvement could be more structured bullet points, but it remains clear and 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 the tool's complexity (two entity types, different data endpoints) and lack of output schema, the description covers key aspects: use cases, input format, data sources, and return structure. It does not specify exact output fields but provides enough context for effective 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 explaining how each parameter maps to real-world entities (e.g., tickers for company, drug names for drug) and what data each type retrieves, going beyond the schema's brief 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 that the tool compares 2-5 companies or drugs side by side, with specific use cases and examples. It distinguishes itself from siblings by replacing 8-15 sequential agent calls, though it could explicitly differentiate from entity_profile.

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

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

The description provides explicit when-to-use triggers like 'compare X and Y' and outlines the data pulled for each type. It lacks when-not-to-use or alternative tools, but the guidance is sufficient for correct invocation.

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 provided, so description carries full burden. It discloses that the tool returns 'most relevant tools with names and descriptions', which is clear. However, it does not mention if it's read-only or if there are side effects; given the search nature, this is adequate.

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

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

Three sentences, each with clear purpose: first states what it does, second describes output, third gives usage guidance. No wasted words, front-loaded with key information.

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

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

Given 2 simple parameters, no output schema, and no annotations, the description is complete. It explains input (natural language query, limit), output (tool names and descriptions), and when to use (first step). No missing critical information.

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. Description adds value by explaining the query parameter should be a 'Natural language description' with examples, and notes default/max for limit. This enhances 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?

Description clearly states the verb 'Search' and the resource 'Pipeworx tool catalog', specifying the action is to find tools by describing needs. It distinguishes from siblings by indicating this is the first call when 500+ tools are available, while siblings like sbir_search_awards have a different domain.

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 'Call this FIRST' and provides context for when to use: when 500+ tools are available and need to find the right ones. Implicitly suggests alternatives are other tools that perform specific tasks after discovery.

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

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

No annotations provided, but description fully discloses behavior: returns multiple data types (SEC filings, revenue/net income/cash, patents, news, LEI) with pipeworx:// citation URIs. Also clarifies input limitations (no names, only ticker/CIK). Non-destructive implied.

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 with front-loaded main purpose. Every sentence adds value: example queries, returned content list, citation URIs, input format clarifications. No redundancy or filler.

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

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

Despite no output schema, description lists all return types (SEC filings, fundamentals, patents, news, LEI) and mentions citation URIs. Covers input limitations and alternative tool (resolve_entity). Sufficient for an agent to understand and use 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?

Input schema covers type and value with descriptions. Description adds significant nuance: specifies that type is only 'company', value must be ticker like 'AAPL' or zero-padded CIK like '0000320193', and explicitly warns that names are not supported. Adds value 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?

Description starts with 'Get everything about a company in one call,' clearly stating the verb and resource. It lists specific content returned (SEC filings, fundamentals, patents, news, LEI) and distinguishes from siblings by noting it replaces 10+ pack tool calls.

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

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

Explicitly lists query patterns like 'tell me about X' and 'give me a profile of Acme'. Provides alternative guidance: 'Names not supported — use resolve_entity first' and notes when the tool is appropriate instead of multiple calls.

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 for behavioral disclosure. It states the action is destructive ('Delete') but does not specify if the deletion is irreversible, whether it requires confirmation, or any side effects. It is adequate but not rich.

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 concise sentence that clearly conveys the purpose. No redundant words or unnecessary 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 simplicity of the tool (one required parameter, no output schema, no nested objects), the description is complete enough for an agent to understand its function. However, it could hint at whether the operation is idempotent or if the key must exist.

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

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

The schema already provides a description for the single parameter 'key', achieving 100% coverage. The tool description does not add extra meaning beyond 'Memory key to delete', but the schema alone is sufficient. Score is elevated because schema coverage is high and parameter is simple.

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 ('a stored memory by key'), matching the tool's name 'forget'. It is specific and distinguishes from siblings like 'recall' and 'remember' which are for retrieval and storage respectively.

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 when to use this tool: when you need to delete a specific memory identified by its key. It does not explicitly state when not to use it or name alternatives, but the sibling tool names (recall, remember) provide implicit context for differentiation.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, indicating a safe read operation. The description adds behavioral details beyond annotations: it explains that the tool fetches the page, extracts title/description/key links, and emits the standard llms.txt markdown format. 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 three sentences, each delivering value: purpose and audience, process, and use cases. No extraneous words, front-loaded with the main action. Excellent 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 no output schema, the description explains the output (single text blob) and covers input, process, and use cases. It lacks error handling or prerequisites but is sufficient for a straightforward fetch-and-summarize 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?

Input schema coverage is 100% with both url and max_links described clearly. The description does not add new parameter information beyond what the schema provides (e.g., it mentions the default and max for max_links but schema also states those). 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 verb ('generate'), the resource ('llms.txt file'), and the context ('for any URL so AI crawlers can index the site cleanly'). It also mentions the standard format and output location, making the purpose unambiguous.

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

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

The description lists concrete use cases (getting a client's site indexed, drafting for own project, auditing competitors) that guide when to use the tool. However, it does not explicitly state when not to use it or mention alternatives, which would strengthen the guideline.

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, description carries full burden. It discloses rate limiting (5 per identifier per day), free usage, and that team reads digests daily. This provides clear behavioral context beyond 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?

Front-loaded with purpose and usage; well-structured but slightly wordy with multiple sentences. Could be tightened 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?

Covers all necessary aspects: when to use, how to describe issues, behavioral notes, and impact. No output schema needed; description is fully sufficient for this simple 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, but the tool description adds extra context about the enum values and message specificity (1-2 sentences, 2000 chars). Enhances understanding beyond 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 is for reporting bugs, features, data gaps, or praise. It distinguishes itself from sibling tools by being a feedback mechanism, not a data query tool.

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

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

The description explicitly tells when to use (bug, missing tool, praise), gives examples, and includes what not to do (don't paste end-user prompt). Also covers rate limits and quota-free nature.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context: data source (CF analytics-engine), no PII, cached 5min-1h, and the data structure (pack, tool, count). 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 concise (~100 words) and well-structured with a clear introductory sentence, bullet-point use cases, and additional context on data source and caching. Every sentence is meaningful and efficiently conveys information.

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

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

Despite the lack of an output schema, the description fully explains what the tool returns (top tools, top packs, total call volume) and provides context on caching and data provenance. For a simple 1-parameter tool, this is comprehensive.

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

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

The input schema has 100% coverage for the single parameter (window), listing its enum values and description. The description adds nuance: shorter windows for hot trends, longer windows for steady-state demand, which goes beyond the schema. A score of 4 reflects this added 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?

The description clearly states the tool's purpose: returning top tools, top packs, and total call volume over a recent window. It uses a specific verb ('returns') and resource ('trending data') that distinguishes it from siblings 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 explicitly lists three use cases (discovering hot data sources, confirming canonical tool choice, seeing alignment with most agents) and provides guidance on window selection (shorter vs longer windows). This helps the agent decide when and how to use the 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 readOnly=true, non-destructive, open world. Description adds behavioral context: it walks child markets, searches across events, groups related markets, and returns ranked opportunities with reasoning. 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 a single well-structured paragraph: purpose, two modes clearly demarcated with examples, and output description. It is appropriately sized, though minor tightening (e.g., 'Two modes:' instead of 'TWO MODES:') could improve.

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 moderate complexity (two modes, cross-event search) and no output schema, the description covers key aspects: modes, what it returns (ranked opportunities with reasoning), and the logic. Sufficient 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 coverage is 100%, so baseline is 3. Description adds value by explaining each parameter's mode with realistic examples (slugs, topics) and clarifying that exactly one should be used. This goes 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 finds arbitrage opportunities via monotonicity checks, explains two modes (event/topic) with examples, and distinguishes from likely sibling 'polymarket_edges' by contrasting single-event vs cross-event functionality.

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 outlines when to use each mode, including a concrete example of cross-event necessity (Polymarket separating cutoffs into separate events). It lacks explicit 'when not to use' guidance but provides clear context for selection.

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

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

The description adds significant behavioral context beyond the annotations: it discloses the algorithm (lognormal model from FRED and coinpaprika), scope (crypto-price bets), and process (scans top markets, groups by asset, computes model probability, ranks by edge). This enriches the readOnlyHint annotation by clarifying that the tool performs non-destructive analysis. 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 that front-loads the primary purpose. It is appropriately concise given the complexity and provides all necessary information without unnecessary words. However, it could be slightly more structured (e.g., bullet points) for easier scanning.

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 explains the return format (top N ranked by edge magnitude with suggested trade direction) and the underlying algorithm. It covers the essential context for an agent to select and invoke the tool correctly, though it could briefly mention that it uses external data sources.

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

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

The input schema has 100% description coverage, so the baseline is 3. The description does not add additional meaning beyond what the schema already provides for the three parameters (limit, window, min_edge_pp). It restates defaults but does not augment semantics.

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 what the tool does: scan high-volume Polymarket markets and return those where Pipeworx data disagrees most with market price. It specifies the verb 'scan' and the resource 'Polymarket markets', and distinguishes itself from siblings like 'polymarket_arbitrage' and 'bet_research' by focusing on opportunity discovery for the 'what should I bet on today' question.

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 (discovering betting opportunities based on model disagreements) and explicitly states its purpose for the 'what should I bet on today' question. However, it does not explicitly mention when not to use it or compare it to sibling tools like 'bet_research' or 'polymarket_arbitrage', though the distinction is implied.

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 readOnlyHint and idempotentHint, and the description reinforces that it is a read-only query returning prices and spreads. It adds behavioral context beyond annotations by explaining the two modes and the output format. 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 relatively long but well-structured: first sentence gives core purpose, then explains the arb signal, then lists two modes, then describes output. It is front-loaded but could be slightly more 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 the complexity of cross-venue spread calculation with two modes, the description provides sufficient detail on how to use it and what output to expect. It covers return values despite no output schema. Missing error handling or prerequisites but acceptable.

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 parameter descriptions. The description adds additional context: for topic, it lists the pre-mapped shortcuts; for explicit tickers, it provides examples and explains that they override the topic-mapped sides.

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 computes cross-venue spread between Kalshi and Polymarket for the same resolving question. It distinguishes from sibling tools like polymarket_arbitrage by specifying the cross-venue focus and returning leg-by-leg prices and spreads.

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?

Description explains when to use the tool: for arbing price differences between Kalshi and Polymarket. It details two modes (topic shortcuts and explicit tickers). However, it does not explicitly state when not to use it or mention 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?

No annotations are provided, so description carries full burden. It clearly states the tool is for retrieving previously stored memory, implying a read-only operation. It also clarifies that omitting key lists all keys, which is a behavioral detail not in the schema. 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 concise (two sentences), front-loaded with the primary action, and adds a usage hint in the second sentence. Every sentence adds value.

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

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

Given a simple tool with one optional parameter and no output schema, the description is sufficient. It explains the two modes of operation and the context for use. No additional details about return format are needed as there is no 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 baseline is 3. Description adds value by explaining that omitting the key lists all memories, which is not explicit in the schema. This extra semantic helps the agent understand the optional nature of the parameter.

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

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

Description clearly states the verb 'Retrieve' and resource 'stored memory by key', and also explains the alternate behavior of listing all memories when key is omitted. This distinguishes it from sibling tools like 'remember' (store) and 'forget' (delete).

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

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

Description explicitly says when to use ('retrieve context you saved earlier') and implies when to omit key (to list all). However, it does not mention when not to use this tool or suggest alternatives among siblings.

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

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

With no annotations, the description carries the full burden. It discloses the fan-out to multiple sources (SEC EDGAR, GDELT, USPTO) and the return format including structured changes, count, and citation URIs. However, it does not disclose potential rate limits, authentication requirements, or behavior on missing data.

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 concise at two paragraphs. It is front-loaded with the purpose and includes useful examples, though some repetitions could be trimmed. Overall, it balances completeness with readability.

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

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

For a tool with 3 simple parameters and no output schema, the description covers the core behaviors: the fan-out sources, accepted date formats, and return structure. It does not mention error handling or pagination, but the complexity is low enough that these gaps are minor.

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

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

Input schema coverage is 100% with descriptions for all parameters. The description adds significant value beyond schema by explaining that 'since' accepts ISO dates or relative shorthand (e.g., '7d', '30d'), and that 'value' can be a ticker or CIK. It also provides a recommendation for typical monitoring ('30d' or '1m').

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: 'What's new with a company in the last N days/months?' and provides multiple concrete example queries. It specifies the verb (get recent changes) and resource (company activity), and distinguishes itself from sibling tools by addressing a specific monitoring use case.

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 with example queries like 'what's happening with X?' and 'brief me on what happened with Microsoft this quarter', but does not provide explicit when-not-to-use guidance or alternatives.

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

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

With no annotations provided, the description discloses important behavioral traits: memory persistence based on authentication and 24-hour expiration for anonymous sessions.

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

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

Three sentences, each serving a distinct purpose: what it does, when to use, and behavioral nuances. No wasted words.

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

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

Given the simplicity of the tool (two required params, no output schema, no nested objects), the description is complete. It covers purpose, usage, and key behavioral traits.

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 description adds little beyond examples. It mentions storing text but does not elaborate on format constraints beyond what schema already provides.

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 stores a key-value pair in session memory, and distinguishes itself from siblings like recall and forget by mentioning persistence behavior.

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

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

Provides guidance on when to use (save intermediate findings, user preferences, context) and distinguishes persistence between authenticated and anonymous sessions.

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 provided, so description carries full burden. It discloses return values (IDs and citation URIs) and gives examples; lacks details on auth or rate limits but sufficient for a lookup 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?

Efficient single paragraph, front-loaded with purpose, then examples and usage guidance; 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?

Complete for a simple lookup: explains parameters, return types, and usage context despite missing 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?

Description adds significant meaning beyond the schema with examples (Apple → AAPL, Ozempic → RxCUI) and clarifies acceptable input formats for both parameters.

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

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

Description clearly states the tool resolves entity names to official identifiers (CIK, ticker, RxCUI, LEI) and distinguishes it from siblings by noting it replaces multiple lookup calls.

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

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

Explicitly tells when to use (when user mentions a name needing an ID) and the order (before tools needing identifiers), with no 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?

The description discloses the tool's behavior: it returns counts for the specified agency or all major agencies. It lists the major agencies (DOD, HHS, NASA, NSF, DOE, USDA). There are no annotations provided, so the description carries the full burden. It does not mention response format, data freshness, or any rate limits, but given the simplicity of the tool, this is adequate.

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

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

The description is two sentences, front-loading the purpose and then providing conditional behavior. Every sentence adds value with no fluff or redundancy.

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

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

For a simple counting tool with a single optional parameter and no output schema, the description is largely complete. It specifies what data is returned (counts) and the agencies covered. A minor gap: it does not explain if the count includes both SBIR and STTR or if they are separate, but this is likely self-evident given the tool name.

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 only parameter 'agency' has a description). The description adds context by explaining the effect of omitting the parameter (returns all major agencies) and providing examples. This adds value beyond the schema alone, but does not go into detailed formatting or validation rules. Baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: retrieving SBIR/STTR award counts by agency. It specifies the verb ('Get'), the resource ('SBIR/STTR award counts by agency'), and distinguishes two modes: specific agency or all major agencies. This differentiates it from sibling tools that deal with company awards, specific awards, or solicitation searches.

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 this tool: for award counts by agency. It explains that if an agency is specified, returns that agency's count; otherwise returns counts for all major agencies. However, it does not explicitly state when not to use it or mention alternatives among sibling tools, such as sbir_search_awards for detailed award data.

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 provided, so description carries full burden. It states returns a full list, which is helpful. However, it does not mention authentication requirements, rate limits, or whether results are paginated. The 'limit' parameter hints at pagination but is not described.

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 provides key return fields. It is concise but could be more efficient by merging the two sentences.

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

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

For a tool with 2 params and no output schema, the description is adequate. It explains the main return type but lacks details on pagination behavior (e.g., does 'limit' affect the full list?) and any filtering capabilities. Given the context of siblings, a bit more guidance 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?

Schema coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema: 'company' is self-explanatory, and 'limit' is described in the schema as 'Number of results to return (default 50)'. No additional semantics provided.

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 'SBIR/STTR awards for a specific company', and lists the fields returned (amounts, agencies, topics, phases). It distinguishes from siblings like 'sbir_get_award' (single award) and 'sbir_search_awards' (search), though not 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?

The description implies usage when you need all awards for a known company. No explicit when-not or alternatives are given, but the context of sibling names suggests other tools for specific award retrieval or search.

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

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

Annotations are empty, so the description carries full burden. It correctly indicates a read operation (returns info) but does not mention any side effects, permissions, or constraints. Since there are no annotations to contradict, it is adequate but not detailed.

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

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

The description is a single sentence that efficiently conveys the purpose, input, and output content without any redundant 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 has a single parameter, no output schema, and no nested objects, the description provides enough context: what it does, what input is needed, and what output includes. It could mention if the award ID is a specific format or how errors are handled, but overall it is sufficient.

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 a single parameter 'award_id' described as 'The unique award ID'. The description adds that the ID is for an SBIR/STTR award, which provides context beyond the schema. However, it does not add format or examples, so 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 retrieves details for a single award by ID, lists the data fields returned (company, amount, agency, abstract, phase), and distinguishes it from sibling tools like sbir_search_awards which would return multiple awards.

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 specifies the tool is for a single award and requires an award ID, implying it should be used when the specific ID is known. It implicitly distinguishes from sbir_search_awards but does not explicitly state 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 are empty, so the description carries full burden. It discloses return fields but does not mention pagination, rate limits, or data freshness. The description is accurate but lacks behavioral details beyond input-output.

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

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

The description is a single sentence listing key filters and return fields. It is concise and front-loaded, but could be slightly more 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 6 parameters, no output schema, and empty annotations, the description provides a solid overview but lacks depth on pagination, sorting, or error behavior. It is adequate for simple use but not fully complete.

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

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

Schema coverage is 100%, so each parameter has a description. The tool description adds context by listing return fields and summarizing filters, but does not add meaning beyond the schema.

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

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

The description clearly states the tool searches SBIR/STTR awards and lists all filter dimensions (keyword, agency, year, company, state). It also specifies return fields, distinguishing it from siblings like sbir_get_award (single award) and sbir_company_awards (company-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 implies use for searching awards, but does not explicitly contrast with sibling tools like sbir_company_awards or sbir_search_solicitations. No guidance on when to use this vs. alternatives is 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 explains the tool returns topics with description, agency, and dates, and that it searches against topics and descriptions. Since there are no annotations, the description carries the full burden. It does not mention pagination, sorting, or behavior when no results are found, which are relevant for a search 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 two sentences, concise and front-loaded with the tool's purpose. However, the first sentence could be more active (e.g., 'Search for SBIR/STTR solicitations') to be clearer.

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

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

Given 4 parameters, no output schema, and no annotations, the description is somewhat sparse. It explains what the tool does but lacks detail on return format, pagination, or behavior. It is adequate but not comprehensive.

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

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

Schema coverage is 100%, so the baseline is 3. The description does not add any parameter-level detail beyond what the schema provides. It lists fields returned but does not elaborate on parameters like open_only or agency values.

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

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

The description clearly states the tool searches SBIR/STTR solicitations and lists the key fields returned (description, agency, dates). It distinguishes the tool from siblings like sbir_search_awards by specifying the resource type (solicitations vs awards). However, it could be more specific about the verb (e.g., 'search' vs '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 provides no guidance on when to use this tool versus alternatives (e.g., sbir_search_awards for awards, sbir_agency_stats for statistics). It does not explain the relationship between solicitations and awards, which would help an agent choose correctly.

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 specific behavioral details: probing each entity with ai_visibility_check, ranking by score, returning a ranked list with score/confidence/signal density. 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?

Three sentences, front-loaded with main purpose. Every sentence adds unique value 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?

Given the tool's complexity (multiple entities, side-by-side comparison) and no output schema, the description clearly explains the return format (ranked list with score/confidence/signal density) and references the underlying probe tool. Fully sufficient.

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 context beyond schema: first entity is the 'subject' for narrative, models selection determines API keys, context disambiguates names. This 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?

The description clearly states it compares AI visibility across multiple entities side-by-side, probes each entity with ai_visibility_check, ranks by score, and surfaces most/least recognized. This distinguishes it from siblings like ai_visibility_check (single entity) and compare_entities (generic).

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

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

It says 'Useful for competitive AI-marketing audits' and gives an example question. This implies context of use but does not explicitly state when not to use or name alternatives, which is minor.

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 fully bears the burden of behavioral disclosure. It describes the return format (verdict with types), the data source (SEC EDGAR + XBRL), and a limitation (v1 supports company-financial claims for US public companies). It does not contradict annotations (none exist).

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

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

The description is three sentences long, each earning its place: first sentence states the core function, second provides usage guidance with examples, third details supported domain and return values. It is concise and 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's simplicity (one parameter, no output schema), the description is complete. It explains purpose, when to use, supported domain, return structure (verdict types, citation, delta), and efficiency benefit (replaces sequential calls). No gaps remain.

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

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

The input schema has 100% description coverage for the single parameter 'claim'. The description adds value beyond the schema by providing natural-language examples and explaining that the claim is a 'natural-language factual claim', which aids the AI in constructing appropriate input.

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 factual claims against authoritative sources. It specifically mentions support for company-financial claims via SEC EDGAR, uniquely distinguishing it from sibling tools like 'ask_pipeworx' or '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?

It explicitly provides usage guidance with examples ('Is it true that…?', 'Verify the claim that…') and states the condition 'when an agent needs to check whether something a user said is true'. It does not explicitly list exclusions or alternatives, but the context is clear.

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