Openaq

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

Annotations declare read-only, idempotent, non-destructive. Description adds that the tool returns the nearest station with most recent pollutant values and other nearby stations, which is consistent and provides useful behavioral context beyond annotations.

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

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

Two sentences, front-loaded with core functionality in the first sentence. Efficient and to the point, no unnecessary 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 no output schema, the description sufficiently explains what is returned (nearest station with values and other nearby stations). Covers essential aspects for a simple tool, though error cases are not mentioned.

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 explains that latitude/longitude are used to find the nearest station and mentions default and max for radius_km, adding slight value. No additional format details needed.

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 gets air-quality readings at the nearest station to coordinates, listing pollutants and use cases. Does not explicitly differentiate from siblings like 'find_stations' or 'get_measurements', but the specific focus on nearest station and coordinates is distinct enough.

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 example queries ('air quality near me', 'what is the air quality at <coordinates>') and suggests when to prefer this tool. Lacks explicit exclusions or alternatives, but context is clear for typical use.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false. Description adds that the tool probes one or more LLMs, returns per-model details and combined view, and discloses cost implications (free default, BYO key for Anthropic). 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?

Two sentences, front-loaded with main purpose. Every word adds value. No fluff or repetition.

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, explains return structure (per-model and combined view), and mentions use cases. No output schema needed; description sufficiently explains output. Complete for the tool's complexity.

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

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

Schema has 100% description coverage, but description adds extra context: default model is Workers AI Llama-3.3-70b, and `_apiKey` is only needed for Anthropic. This clarifies usage 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 clearly states the tool probes LLMs for knowledge about a business/brand/product/topic and scores visibility. Differentiates from siblings like 'entity_profile' or 'ask_pipeworx' by focusing on multi-model visibility scoring.

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

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

Explicitly mentions use cases (AI-marketing audits, pre-launch brand checks, competitive monitoring) and model selection (default free, Anthropic requires API key). Lacks explicit 'when not to use' or comparison to all siblings, but context is clear.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds context about returning structured answers with stable pipeworx:// citation URIs and routing to thousands of sources, which goes beyond what annotations provide. No contradictions.

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

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

The description is quite long and wordy, covering many use cases and alternatives. While every sentence adds value, it could be more concise without losing clarity. The information is well-structured and front-loaded with the key priority statement.

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 (4774 tools, 1242 sources) and no output schema, the description thoroughly explains return format (structured answer with citations), routing behavior, and fallback options. It leaves no major gaps in understanding for an AI agent.

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

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

Schema coverage is 100% with all 6 parameters (aliases for 'question') described. The description does not add significant new detail beyond the schema's description of the 'question' parameter as a natural language query. Baseline 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 function: answering factual questions using authoritative structured data. It provides specific examples (SEC filings, FDA data, etc.) and explicitly distinguishes itself from sibling tools like ask_pipeworx_grounded and deep_research.

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

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

The description gives explicit guidance on when to use this tool (factual questions, 'what is', 'look up', etc.) and when to step up to alternatives (ask_pipeworx_grounded for hallucination-resistant answers, deep_research for broad questions). It even lists example queries, leaving 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?

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds significant behavioral context: it routes from 4,774 tools across 1,242 sources, fills arguments, fetches data, and extracts answers only from the tool result. It explains the return format (including success and refusal cases) and notes the extra cost. This goes well 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 relatively long but every sentence adds value. It is front-loaded with the core purpose and structured to flow from overview to details. A slight reduction in verbosity could be possible, but the content justifies the length.

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 the tool—a grounded answer mode with refusal handling—the description is complete. It explains the behavior, return values (including answer, evidence, confidence, source, refusal reasons), use cases, and cost trade-off. No output schema exists, but the description covers return format exhaustively.

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

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

Schema coverage is 100% with all parameters having descriptions and aliases. The description does not add significant meaning beyond what the schema already provides; it only mentions the question parameter in a general sense. Since schema description coverage is high, 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?

Description clearly states the tool's purpose: 'Hallucination-resistant answer mode for high-stakes reads.' It specifies the verb 'EXTRACTS the answer using ONLY what the tool result contains,' distinguishing it from the sibling ask_pipeworx. The description also lists specific use cases, 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?

Description provides explicit guidance on when to use this tool: 'whenever an answer will be quoted, cited, or acted on, and the agent must not invent facts,' with specific examples like financial verdicts, legal claims. It also tells when to prefer the sibling: 'prefer ask_pipeworx for casual lookups,' highlighting a trade-off of cost vs. reliability.

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 documents behavioral traits beyond annotations, including fan-out logic, safety mechanisms (low-confidence resolution, closed market handling), response fields (resolver contract, parent event extractor, news fields), and resolution-rule risk. No contradiction with annotations (readOnlyHint, idempotentHint, etc.).

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

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

The description is quite lengthy (multiple paragraphs) but well-structured with clear sections (CLASSIFIERS, FAN-OUT EXAMPLES, etc.). It is front-loaded with a summary sentence but could be more concise for an AI agent. Every section adds value, but the verbosity reduces efficiency.

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 (bet research with many categories, safety checks, response shapes), the description covers all necessary aspects: resolver contract, parent event extraction, news fields, cancellation risk, and tradeability. No output schema exists, so the description adequately explains return values.

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

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

The schema covers 100% of parameters with descriptions. The description adds extra context for the 'market' parameter (slug, URL, question text) and explains 'depth' and 'include_raw' with examples, enriching the 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 researches a Polymarket bet by pulling Pipeworx data. It specifies the verb 'research' and resource 'Polymarket bet', and distinguishes from sibling tools like polymarket_arbitrage and polymarket_edges by focusing on a single bet's data.

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

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

The description provides explicit use cases: 'should I bet on X', 'what does the data say about Y', 'is there edge in Z'. It gives clear context for when to use the tool but does not explicitly exclude alternatives or mention when not to use it.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and no destructive behavior. The description adds critical behavioral context: how fiscal years are handled (AAPL Sep, NVDA Jan), result sorting by primary metric, return of citation URIs, and specific data pulled per type. 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 somewhat lengthy but well-structured with example queries upfront. Each sentence adds value: usage guidance, data specifics, ordering, return format, and efficiency claim. A slight reduction in redundancy could improve it, but it is sufficiently concise given the complexity.

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

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

Despite no output schema, the description fully explains what is returned (paired data, citation URIs). It covers all needed context for both entity types, including edge cases (off-calendar fiscal years). Given the tool's complexity (2-5 entities, two types, multiple metrics), the description is remarkably 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% with both parameters described. The description complements the schema by explaining what each type returns (e.g., 'LATEST 10-K revenue + net income + cash + long-term debt' for companies) and that values are tickers or drug names, adding meaning beyond the basic descriptions.

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

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

The description starts with explicit example queries and clearly states it performs side-by-side comparison of 2-5 companies or drugs. It specifies data sources (SEC EDGAR for companies, FAERS for drugs) and distinguishes itself from sequential single-pack lookups, making the purpose unmistakable.

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

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

The description explicitly says 'ALWAYS PREFER over sequential single-pack lookups when comparing entities,' providing clear context for when to use this tool. It also covers alternative approaches by stating it replaces '8–15 sequential lookups.'

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, etc. The description adds critical context: account needed, free vs paid, decomposition into facets, parallel tool routing, expected return format (findings with evidence, confidence, citation, gaps), and timing (15-60s). 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 fairly long but each sentence serves a purpose: signup info, alternative for unsigned users, core functionality, return format, when to use alternatives, and timing. Front-loaded with essential requirement. Could be slightly more concise, but structure is logical.

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 (multi-source, parallel, 1242 sources, 4774 tools) and no output schema, the description thoroughly explains what to expect: verbatim evidence, confidence, source, fetched_at, stable citation, and explicit gaps. It also covers edge cases like empty gaps for uncatalogued topics and expected timing. Complete for a research tool.

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

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

Schema coverage is 100% and the schema already describes both parameters. The description adds meaningful nuance: explains depth values (quick=3, standard=5, thorough=8 paid) and emphasizes that question can be broad/multi-part. This adds value beyond the schema, but baseline is 3 due to full coverage, so a 4 is warranted.

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

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

The description starts with a specific verb 'Grounded multi-source research' and clearly identifies the resource (Pipeworx's 1242 structured data sources). It distinguishes itself from sibling tools like ask_pipeworx and ask_pipeworx_grounded by explicitly stating what it does (decomposes questions, parallel tools, returns findings packet with gaps) and what it does not do (open-web search, breaking news).

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 when-to-use (broad/multi-part questions over structured data) and when-not-to-use (breaking news, colloquial current news, prefer ask_pipeworx). Also mentions account requirement and alternative if not signed in (ask_pipeworx), plus depth limitations by plan.

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. Description adds valuable behavioral details: returns top-N tools with names, descriptions, and full schemas with curated examples, ready to call directly.

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?

Efficiently packs essential information in a well-structured paragraph. Front-loaded with core purpose, then examples, then output details. No superfluous 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?

Given the tool's role as a discovery tool among many siblings, the description fully explains when to call it, what it returns (including that results are ready to call), and covers all necessary aspects without an output schema.

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

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

Schema covers all 6 parameters with descriptions. Description adds value by consolidating aliases and providing example query strings ('look up FDA drug approvals', 'analyze housing market trends'), improving interpretation beyond raw schema.

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

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

Description clearly states 'Find tools by describing the data or task', uses specific verb+resource, and distinguishes from siblings by advising 'Call this FIRST' when exploring the option set.

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

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

Explicitly says when to use (browse, search, discover) and provides 'Call this FIRST' instruction. Lacks explicit when-not-to-use guidance, but context of siblings implies alternatives.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context: parallel execution, specific return fields, the patent data soft-fail due to sunset, and the use of GDELT→GNews fallback. It does not contradict annotations. A slightly higher score would require disclosure of potential delays or rate limits, but the existing transparency is 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?

The description is relatively long but packs significant detail. It front-loads with example queries but then lists many return fields in a dense paragraph. While effective, it could benefit from bullet points for the output components to improve scanability. The length is justified by the tool's complexity, but conciseness could be improved without losing 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 multi-source complexity and lack of an output schema, the description thoroughly covers all return components: CIK, company_name, recent_filings with URIs, fundamentals with specific fields, patents (including sunset notice), news (with fallback), and LEI. It also mentions execution strategy (parallel). No gaps are apparent for the intended use case.

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

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

Schema coverage is 100% and includes descriptions for both parameters. The description adds important usage guidance: it clarifies the 'value' parameter format (ticker or zero-padded CIK) and explicitly states that company names are not supported. This helps the agent avoid common mistakes and reduces ambiguity beyond the schema alone.

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

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

The description opens with multiple example queries ('Tell me about X', 'research Acme') and clearly states it provides a 'full cross-source profile of a US public company in ONE parallel call'. It lists the exact data sources and returned fields, and explicitly distinguishes from chaining individual lookups. This makes the purpose unmistakable and well-differentiated from sibling tools.

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

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

The description explicitly states when to use this tool: 'when the user asks for a holistic view' and instructs to 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups'. It also warns against using a company name directly, directing to 'resolve_entity' first. However, it does not explicitly mention when not to use it in favor of other sibling tools like 'compare_entities' or 'deep_research', which would make it stronger.

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

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

Annotations declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true, which covers safety. Description adds behavioral details: return fields, ordering, and three search modes. Does not mention pagination, but overall transparent.

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

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

Two sentences, front-loaded with core purpose, then immediate guidance to sibling tools. No redundant or vague language.

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

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

No output schema, but description lists returned fields and ordering. Covers all three search modes and references sibling tools. Sufficient for a read-only, idempotent tool with open world hint.

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 full parameter descriptions. Description summarizes the three search families but does not add new parameter semantics beyond schema.

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

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

Clearly states verb 'Find' and resource 'OpenAQ air-quality monitoring stations', specifies three search methods (coordinates+radius, country, bounding box), and distinguishes from siblings by directing to get_latest and get_measurements.

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 provides usage context: when to use this tool (to locate stations) and when to use alternatives (get_latest with station id, get_measurements with sensor id). Includes ordering behavior (nearest first for coordinates).

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 destructiveHint=true and idempotentHint=true. Description adds usage context but no additional behavioral traits beyond schema and annotations.

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

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

Three concise sentences with front-loaded action, usage scenarios, and sibling links. No redundant content.

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

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

For a simple deletion tool with one param and no output schema, the description covers purpose, usage, and related tools. A mention of return value or confirmation would be nice but not essential.

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 a clear description for the only parameter. Description adds no further parameter details beyond 'by key', meeting baseline for high 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 'Delete a previously stored memory by key' is a specific verb+resource combination. It clearly distinguishes from sibling tools like remember and recall.

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

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

Provides explicit scenarios (stale context, task done, clear sensitive data) and mentions pairing with remember and recall. Lacks when-not-to-use but is reasonably clear.

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

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

Annotations already provide readOnlyHint, idempotentHint, etc. The description adds transparency by detailing the process (fetch, extract, emit markdown) and the output format (single text blob). No side effects are disclosed beyond what annotations imply.

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 adding value: main purpose, process, and use cases. No redundant 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?

With 2 parameters fully described in schema, rich annotations, and no output schema needed (output described as text blob), the description covers all necessary context: what, how, and when to use.

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

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

Schema coverage is 100%, so baseline is 3. The description adds context by mentioning the url is for fetching a page and the max_links parameter controls link entries, slightly enriching the schema info.

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 a production-ready llms.txt file for any URL, explaining its purpose for AI crawlers. It distinguishes itself from general visibility tools by specifying the standard format and direct output usage.

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

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

The description lists three explicit use cases (client site indexing, own project drafting, competitor auditing), providing clear when-to-use guidance. However, it does not explicitly mention when not to use or compare with siblings.

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

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

Annotations already provide safety/hints; description adds useful output detail (pollutant values, units, measurement time). 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?

Two succinct sentences, front-loaded with core purpose. No fluff.

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

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

Given output schema exists, description covers the key return structure. No pagination mentioned but not needed as tool returns all pollutants at once.

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; description reinforces the location_id usage but adds no new semantic meaning beyond the schema.

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

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

Description clearly states the verb 'Get' and resource 'latest reading for every pollutant at a specific OpenAQ station'. It differentiates from siblings like find_stations by specifying a station ID, and from get_measurements by focusing on latest readings only.

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 context on when to use (requires location_id from find_stations) but does not explicitly exclude alternatives like get_measurements. Still clear for an informed agent.

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

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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds that results are newest-first and aggregates are hourly/daily. This supplements annotations without contradiction, though it omits details like pagination 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?

Two succinct sentences with no wasted words. The first sentence packs the core purpose, aggregation options, and ordering. The second provides use-case context. Ideal for quick comprehension.

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 presence of an output schema, return values need not be explained. The description covers what the tool does, when to use it, key parameters, and relationships to sibling tools. It is fully adequate for this simple query 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 all parameters described. The description adds minimal value by reinforcing the sensor_id source (find_stations) and explaining period aggregates. It does not introduce new parameter details but contextualizes usage.

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

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

The description clearly states the tool retrieves historical time series for a single OpenAQ sensor, with specified aggregation (hourly/daily) and ordering (newest first). It also references a sibling tool (find_stations) for obtaining the sensor id, distinguishing itself from other tools.

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

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

The description advises use 'for pollutant trends over time at one station/parameter,' providing clear context. While it doesn't explicitly list when not to use or name alternatives, the sibling tool list includes get_latest, implying differentiation. The guidance is sufficient for most agents.

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

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

Annotations already declare readOnlyHint, idempotentHint, etc. The description adds value by detailing the exact fields returned, providing behavioral context beyond structured annotations.

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

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

Two sentences: first clearly states purpose and return fields, second gives usage guidance. No extraneous words, perfectly front-loaded.

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

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

Given the simple tool (one optional parameter, no output schema), the description covers purpose, return structure, and usage context completely.

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% (one parameter with description). The description reiterates the default behavior (active only) but does not add new semantic 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 explicitly states the tool lists the caller's active subscriptions and specifies the returned fields (id, type, params, etc.). This clearly distinguishes it from sibling tools like subscribe and unsubscribe.

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

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

The description gives specific guidance: use it to review current monitoring before adding more or to find an id to cancel. It does not explicitly mention alternatives or 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?

The description adds significant behavioral context beyond the annotations, including rate limits (5 per identifier/day), that feedback is free and doesn't count against quota, and that the team reads digests daily affecting the roadmap. The annotations are all false and do not contradict.

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 purpose, then provides usage guidelines, and ends with behavioral constraints. Every sentence contributes value without redundancy or fluff.

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

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

Given the tool's simplicity, the description is complete. It covers purpose, usage, parameters (via schema), and behavioral context. There is no output schema, but the feedback nature of the tool does not require one. The description adequately prepares the agent to invoke the tool correctly.

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

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

The input schema has 100% description coverage, providing clear meanings for each parameter. The description adds complementary guidance on how to write the message (be specific, avoid pasting prompts), which enhances understanding beyond the schema. However, it does not add new semantic details for each parameter.

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

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

The description clearly states the tool's purpose: to tell the Pipeworx team about issues (broken, missing, or praise). It uses specific verbs and resources, and distinguishes itself from sibling tools as the only feedback mechanism.

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 the tool: for bugs, missing features/data gaps, or praise. It also specifies what not to do (avoid pasting end-user prompts) and gives rate-limit and quota information, making it highly informative.

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 goes beyond by explaining the data source (CF analytics-engine), privacy (no PII), aggregation format (pack, tool, count), and caching behavior (5min-1h). This provides rich behavioral context without any 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 core purpose in the first sentence. Bullet points are clear and scannable. While effective, the bullet list could be slightly more concise (e.g., merging some points), but it remains highly readable and informative without excess.

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 structure (top tools, top packs, total call volume) and the data format (pack, tool, count). It also covers usage scope, caching, and privacy. For a simple tool with one optional parameter, this is complete and leaves no major questions.

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

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

Schema coverage is 100% for the single 'window' parameter, with both schema and description providing meaning. The description adds nuance about shorter windows surfacing 'what's hot right now' versus longer windows showing 'steady-state demand', which enriches the agent's understanding beyond the enum values 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 returns 'top tools, top packs, and total call volume' based on 'what other AI agents are calling on Pipeworx'. It specifies the resource (top tools/packs) and the action (returns), distinguishing it from siblings like 'discover_tools' which likely returns a list of available tools rather than trending usage.

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?

Three explicit use cases are listed, covering discovery, confirmation, and alignment. While it doesn't mention when NOT to use it or provide alternatives, the context is clear enough for an agent to decide. The bullet points are actionable and differentiated from sibling tools like 'discover_tools' or 'ask_pipeworx'.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds extensive behavioral context, including Jaccard similarity filtering, partition placeholder filtering, fill check against CLOB depth, and the threshold (3pp) for partition check signals. This is additive and 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 dense and well-structured, with a clear flow from summary to mode details to internal checks and response format. However, it is somewhat lengthy and could be slightly trimmed without losing essential information. Still, every sentence serves a purpose.

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

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

Given the tool's complexity, no output schema, and rich behavior, the description is remarkably complete. It explains response fields, fill check logic, thresholds, and references sibling tools. It also covers edge cases like low similarity and placeholder filtering, ensuring an agent has full context to invoke the tool correctly.

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

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

Schema coverage is 100%, but the description adds significant meaning beyond the schema. It explains that `event` takes a slug or URL and performs per-event checks (date-axis ordering, partition sum), while `topic` takes a seed question for cross-event scanning with similarity filtering. This clarifies usage far beyond the basic parameter descriptions.

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

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

The description clearly states the tool's purpose: find arbitrage opportunities using monotonicity violations and partition-sum checks. It distinguishes three modes (no args, event, topic) with specific behaviors for each, making it easy to understand what the tool does and how it differs from others.

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

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

The description provides explicit guidance on when to use each mode. It recommends `event` for specific markets, `topic` for cross-event scanning, and mentions no args for trending scan. It also advises against trading when realizable_edge_pp ≤ 0 and suggests `polymarket_fill_risk` for custom sizing, offering clear when-to and when-not-to use instructions.

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

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

Annotations already provide readOnlyHint, openWorldHint, etc. The description adds extensive behavioral context: caching (1h KV-level), response structure (by_segment, diagnostics), model details, and edge calculations. 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 quite long (over 400 words) and highly detailed, which may overwhelm some agents. However, it is well-structured with clear sections (segments, knobs, diagnostics) and front-loaded with the main purpose. It could be shortened without losing essential 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 complexity (9 parameters, no output schema), the description is remarkably complete. It covers response structure (by_segment), diagnostics (funnel counters, filter_skips), caching behavior, and detailed explanations of model families. It leaves minimal gaps for an agent to understand what the tool does and how to invoke it.

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

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

Schema coverage is 100% with all 9 parameters fully documented. The description adds value beyond the schema by explaining the purpose of each knob (e.g., 'Tradeable-edge filter', 'Skips opportunities that are too small') and providing usage context, elevating it above the baseline 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 uses specific verbs and resources: 'Scan top Polymarket markets and return opportunities where Pipeworx data disagrees with market price.' It clearly distinguishes from sibling tools like polymarket_arbitrage and polymarket_edge_tracker by focusing on Pipeworx disagreement and providing detailed model families.

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 its purpose ('Built for "what should I bet on today" — agents discover opportunities without paging hundreds of markets') and provides guidance on parameter knobs like min_liquidity and max_spread_pp. However, it lacks explicit 'when not to use' or direct comparison to siblings, so it falls short of a 5.

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

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

The description adds significant behavioral context beyond the annotations: history depth bounded by 60-day TTL and snapshot startup, decay from daily closes not intraday, and detailed response structure. Annotations already declare safe read-only behavior, and description reinforces and expands.

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

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

The description is information-dense but structured well with clear sections (args, response, limits). It is front-loaded with the key question. Slightly verbose but appropriate for the complexity.

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

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

No output schema is provided, so the description must fully explain return values. It does so thoroughly, covering tracked, expired, and snapshot_dates arrays with field meanings. Also mentions limits. Complete for a tool of this nature.

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

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

Parameter schema coverage is 100%, so baseline is 3. The description reiterates defaults and adds minor context like 'snapshot family', but does not significantly enhance understanding beyond what the schema 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?

The description clearly states it provides edge persistence and decay telemetry from daily snapshots, answering a specific question about edge duration and trend. It distinguishes itself from the sibling polymarket_edges by focusing on time-series analysis rather than raw edge data.

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

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

The description implicitly explains when to use this tool (to assess edge age and decay) and contrasts fresh vs. old edges. It does not explicitly state when not to use, but the context and sibling list provide enough guidance.

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

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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds rich behavioral context: it walks the order book ladder, returns a verdict (clean|degraded|cannot_fill), and warns about forced directional risk. This goes well beyond the annotations, providing deep transparency into the tool's operation.

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 somewhat lengthy but well-structured, with clear sections for single-market and basket modes. It front-loads the core purpose and requirements. While every sentence adds value, it could be slightly more concise without losing critical 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 complexity (two modes, no output schema), the description is remarkably complete. It explains return fields in detail (top_of_book, vwap_fill_price, slippage_pp, etc., for single-market; theoretical_sum, realizable_sum, thin_legs, etc., for basket). It also covers usage context, prerequisites, and warnings, leaving no major gaps for an agent to misunderstand.

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 significant value by clarifying how size_usd is interpreted differently in single-market versus basket mode, explaining side defaults (auto for basket), and detailing the meaning of parameters in context. It enhances the schema's 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 defines the tool as a 'Realizable-vs-theoretical edge check against live CLOB order-book depth'. It specifies two distinct modes (single-market and basket) and the exact verb-resource combination. This clearly distinguishes it from sibling tools like polymarket_arbitrage and polymarket_edges.

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: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500'. It also explains the rationale, mentioning that theoretical overround is not capturable on thin books and that partial basket fills convert an arb into an unhedged directional position.

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

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

The description goes well beyond the annotations by detailing internal logic (leg-by-leg prices, matched spreads, safety fields like compatibility_warning and temporal_alignment), explaining when spreads are invalid, and exposing counters for dropped comparisons.

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 front-loaded with the purpose, but it is thorough. Every sentence contributes useful information, yet it could be slightly more concise without losing clarity.

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

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

Despite no output schema, the description fully explains the response format, safety fields, and edge cases (incompatible bet shapes, temporal misalignment), making it complete for the tool's complexity.

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

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

Although schema coverage is 100%, the description adds significant value by explaining the two modes, listing the 10 topic shortcuts, and describing how explicit tickers override topic mapping, giving deeper semantic meaning to the 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?

The description clearly states the tool computes cross-venue spreads between Kalshi and Polymarket for the same resolving question, and distinguishes it from siblings by focusing on this specific cross-venue comparison.

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

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

The description explains two modes (topic shortcuts and explicit event tickers) and warns that most pre-mapped topics return compatibility_warning, providing clear guidance on when the tool is useful and when results may be meaningless.

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

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

Adds valuable context beyond annotations: describes behavior when key is omitted, scoping to anonymous IP/BYO key hash/account ID, and the non-destructive nature. 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?

Concise three-sentence description with no wasted words. Each sentence adds essential information: behavior, use case, scoping and related tools.

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 one optional parameter and no output schema, the description is complete. It covers behavior, use case, scoping, and relationship to other tools.

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

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

Schema coverage is 100%, and the description adds clear explanation of the key parameter: retrieve a value if provided, list all keys if omitted. This adds 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 retrieves saved values or lists all keys, and explicitly distinguishes it from sibling tools like remember and forget by describing their paired usage.

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

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

Provides explicit guidance on when to use: for recalling stored context like tickers or notes, and implicitly when not to (use remember/forget for other operations). Also notes scoping.

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

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

Annotations already declare readOnlyHint and idempotentHint, indicating a safe, non-destructive operation. The description adds significant behavioral context: the return payload structure (source, citation_uri, raw payload), the effect of mark_read on subsequent calls, and an alternative access method (GET endpoint for scripts). 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 concise at four sentences, with each sentence providing distinct, valuable information. It front-loads the core action and return data, then covers filtering, mark_read behavior, and an alternative access method. No unnecessary words 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?

Given the tool is read-only with no output schema, the description adequately covers what the tool returns (source, citation_uri, payload), how to filter (type, since, unread_only), how to manage read state (mark_read), and even provides an alternative access point for scripts. This is complete for an agent to use correctly.

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

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

Schema coverage is 100%, providing baseline parameter descriptions. The description adds value beyond the schema by giving a concrete type example ('sec_8k'), clarifying that mark_read affects future calls, and implicitly explaining the 'since' parameter's purpose. This extra context merits a score above baseline.

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

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

The description clearly states the action ('pull fired events') and the resource ('subscription feed'), making the tool's purpose immediately understandable. It distinguishes itself from sibling tools like 'list_subscriptions' and 'recent_changes' by focusing on alerts from the feed.

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 guidance on filtering by type and since timestamp, using mark_read to manage read state, and suitability for polling. However, it does not explicitly mention when to use this tool over alternatives or provide exclusion criteria.

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

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

Discloses fan-out to multiple sources, fallback behavior (GDELT→GNews), PatentsView sunset soft-fail, and return structure. Adds context beyond annotations (readOnlyHint, idempotentHint).

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?

Well-structured with examples first, then details. Slightly verbose but each sentence adds value given tool complexity.

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

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

Complete for a multi-source aggregation tool: covers sources, fallback, date formats, return structure, and caveats. No output schema, so description adequately describes return fields.

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 good descriptions. The tool description adds extra context (relative date examples, ticker vs CIK note) but schema already handles core 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 the tool provides a change feed for a company over a time window, aggregating from SEC EDGAR, GDELT/GNews, and USPTO. It distinguishes from entity_profile, which provides static profiles.

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

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

The description gives explicit query examples and directly advises using entity_profile for static profiles, providing clear when-to-use and when-not-to-use guidance.

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

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

Adds context beyond annotations: scoped by identifier, authenticated users get persistent memory, anonymous sessions retain for 24 hours. 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?

Four sentences, front-loaded with purpose, no superfluous content. 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?

No output schema, but description explains storage behavior, scope, and pairing with recall/forget. Complete for a simple key-value store 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 parameter descriptions. Description adds examples ('subject_property', 'target_ticker') and usage context, providing 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?

The description clearly states the tool saves data for reuse across conversations/sessions, with specific examples like 'resolved ticker' and 'target address'. It distinguishes from siblings 'recall' and 'forget'.

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

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

Explicitly describes when to use ('when you discover something worth carrying forward') and pairs with 'recall' and 'forget' as alternatives. 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. Description adds that each call cascades through several lookup endpoints internally and auto-disambiguates for company, providing richer behavioral context beyond annotations.

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

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

Description is front-loaded with examples and clear purpose. Uses bullet-like structure for types, every sentence adds value. Slightly long but efficient for the information density.

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

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

Despite no output schema, description explains return values in detail (ticker+CIK+company_name+citation URI for company, RxCUI+ingredient+brand+citation for drug) and mentions cascading lookups. Covers all necessary context for a lookup tool with two parameters.

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 significantly adds meaning: specifies enum values for type with return details, and for value gives concrete examples (ticker, CIK, name for company; brand/generic for drug) and notes auto-disambiguation, exceeding 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?

Description clearly states it resolves user-spoken names to canonical/official identifiers, with examples like "What's the ticker for…" and explicit mention of returning ticker, CIK, RxCUI. The directive "Use FIRST whenever you have a name but need an ID" distinguishes it from sibling tools like entity_profile.

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

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

Description explicitly says to use this tool first when you have a name but need an ID, and details supported types and input formats. It lacks explicit when-not-to-use guidance but implies alternatives through context of sibling tools and the statement that it replaces multiple lookups.

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

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

Annotations already declare read-only, idempotent, non-destructive, open-world behavior. The description adds value by explaining the internal mechanism (probes with ai_visibility_check), ranking by score, and the output fields (score, confidence, signal density). 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?

Three sentences: first states the action, second explains how it works, third gives use case and output. No redundant words, includes an example query. 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?

Given no output schema, the description adequately describes the return format (ranked list with fields). It explains the internal dependency on ai_visibility_check and the purpose of each parameter. Could mention that results are ordered by score, but it's implied by 'ranks by score'.

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

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

Schema has 100% coverage with descriptions for all parameters. The description adds meaning beyond schema by specifying that the first entity is treated as 'subject' and the rest as competitors, providing narrative context.

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

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

The description clearly states the tool compares AI visibility across entities, ranks them, and surfaces which is most/least recognized. It uses specific verbs ('Compare', 'probes', 'ranks', 'surfaces') and distinguishes from sibling tool 'ai_visibility_check' by implying batch comparison.

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

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

The description provides clear context for use ('competitive AI-marketing audits') and implies it's for multiple entities. While it doesn't explicitly state when not to use or list alternatives, the sibling list includes ai_visibility_check for single-entity checks, and the description mentions probing each entity with that 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 indicate readOnly, idempotent, openWorld. Description adds behavioral traits: partial failures degrade gracefully, bundlephobia first measurement can take 5-30s, and sources_failed lists timeouts. 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?

Single paragraph, well-structured: high-level purpose, what it checks, usage context, alternatives, failure behavior. Front-loaded with key info. Slightly dense but 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?

Covers key aspects: composite nature, return fields, partial failures, ecosystem limitations. No output schema, so description carries burden. Lists summary fields but not full output structure; adequate for most use cases.

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

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

Schema has 100% description coverage. The description reinforces parameter meanings with examples ('@types/node', '18.3.1') and clarifies defaults (version defaults to latest). Adds context beyond schema.

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

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

The description clearly states the tool's purpose: a composite check for npm packages covering license, advisories, bundle size, etc. It uses specific verbs ('scan') and resources ('dependency'), and distinguishes from sibling tools by focusing on npm package evaluation.

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

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

Explicitly says 'Use whenever an agent asks "is X safe / popular / small" or "what does adding lodash cost me"' and notes alternatives: 'PyPI / Maven / Cargo / Go fall under deps.dev:version directly.' Provides clear when-to-use and exclusions.

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

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

Adds details beyond annotations: uses BGE-base-en embeddings + cosine over 500-char windows, 200K char cap with truncation flag, passage offsets. Annotations already indicate readOnlyHint, idempotentHint, openWorldHint, destructiveHint; description enriches them 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?

Description is concise (roughly 4-5 sentences) with no fluff. Starts with purpose, moves to usage, then technical details. Every sentence earns its place.

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

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

Given 3 params, no output schema, and rich annotations, the description covers purpose, usage, technical specifics, limitations, and output format (offsets). Complete for an agent to effectively invoke the tool.

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

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

Schema coverage is 100% and description adds examples for text (SEC 10-K, article), query (supply-chain risk), and specifies limit default and range. Provides real-world usage context 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 clearly states 'Semantic search INSIDE a fetched record' with specific verb and resource. Distinguishes from siblings by contrasting with ask_pipeworx_grounded and noting it searches inside a record, not fetching whole documents.

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

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

Explicitly says 'Use when the record is too big to cram into the prompt' and suggests pairing with ask_pipeworx_grounded. Provides clear when-to-use and alternative 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?

Discloses authentication requirements, rate limit for SMS (10/day), one-time webhook secret retrieval, and auto-disable after 10 consecutive webhook failures. Annotations already indicate readOnlyHint=false and non-destructive, so description adds meaningful behavioral context beyond annotations.

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

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

Description is well-structured and front-loaded with purpose and auth requirement. At ~200 words, every sentence adds value. Contains examples and clear sections for types and delivery. Could be slightly more concise, but no waste.

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 key aspects: return value (subscription id), types, params, delivery details, constraints. No output schema, but return is mentioned. Missing information on idempotency (though annotation says idempotent) and duplicate subscription behavior, but overall comprehensive for a subscription creation 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?

Adds significant meaning beyond the input schema. For params, provides detailed type-specific structures with examples (e.g., sec_8k: {ticker, items?}). For delivery, explains constraints (SMS must match verified phone, webhook signing and auto-disable). The schema has 100% coverage, but the description enriches understanding.

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

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

Clearly states 'Create a proactive monitoring subscription' with specific verb+resource. Distinguishes from siblings like list_subscriptions and unsubscribe by focusing on creation. Lists supported types and delivery channels, providing strong differentiation.

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

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

Includes explicit condition: 'Requires a Pipeworx OAuth account'. Explains when to use each subscription type (e.g., sec_8k for filings, polymarket_edge for mispricings) and delivery channels. Does not explicitly state when not to use, but the context of creation vs listing/unsubscribing is clear.

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

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

Annotations already indicate readOnly, openWorld, idempotent, non-destructive. The description adds that the tool returns category-bucketed example questions drawn from a live catalog, and that calling with no arguments gives a full spread. 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 relatively long but well-structured: it starts with synonyms for the query, describes the output, and gives usage instructions. Every sentence adds value, though it 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 tool's purpose and available schema/annotations, the description is complete. It explains what the tool does, how to use it, and what the response looks like, even without an output schema.

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

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

Schema coverage is 100% for the single parameter, and the description enriches meaning by listing specific topic values (finance, pharma, etc.) and explaining that omitting it yields a cross-category spread.

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 specifies the tool as the onboarding entry point, returning category-bucketed example questions with exact tool+argument shapes. It distinguishes from sibling tools like ask_pipeworx by emphasizing its role in helping the agent learn what Pipeworx can do.

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 to use this tool first when the agent doesn't know what Pipeworx can do, and explains when to use with or without the 'topic' argument. However, it does not explicitly mention when not to use it or provide comparisons to alternative 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?

Annotations indicate destructiveHint=false and readOnlyHint=false. The description adds behavioral context by clarifying that the row is deactivated (not deleted) and historical events remain accessible via recent_alerts. This goes beyond annotations to explain the side effects.

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: two sentences covering the main action, ownership constraint, and behavioral outcome. No extraneous information, and key points are front-loaded.

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

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

Given the simple parameter set and absence of output schema, the description covers essential aspects: purpose, ownership, and effect on data. It references 'recent_alerts' for additional context. It could mention idempotency (from annotations) but is sufficiently complete for effective use.

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 covers the 'id' parameter with description 'Subscription id (uuid) returned by subscribe.' The description adds context about ownership enforcement, which clarifies the parameter's role. With 100% schema coverage, the description still adds marginal 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 action 'Cancel a subscription by id', providing a specific verb and resource. It distinguishes from sibling tools like 'subscribe' and 'list_subscriptions' by specifying ownership enforcement and the effect (deactivation vs deletion).

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 that ownership is enforced, guiding when to use the tool (only for own subscriptions). It implies when not to use it (for others' subscriptions) and mentions the behavioral outcome (deactivation). However, it does not provide explicit alternatives or scenarios for alternatives like permanent deletion.

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, open-world, idempotent, non-destructive behavior. The description adds valuable context: supported claim types, return verdicts, structured form with citations and percent delta, and domain limitations. No contradictions.

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

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

The description is front-loaded with example intents and is relatively concise given the complexity. It could be slightly trimmed but 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?

For a tool with one parameter and no output schema, the description covers purpose, usage, return values, and domain limitations comprehensively. It explains the verdict types and provides context 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?

Schema coverage is 100% with a well-described 'claim' parameter. The description enhances it with example claims and natural-language context, going beyond just the schema description.

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

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

The description clearly states the tool does natural-language claim verification against authoritative sources, with specific examples and a list of verdict types. It distinguishes itself from siblings by noting it replaces multiple sequential 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?

The description explicitly says to use it for checking factual correctness and limits to company-financial claims. However, it lacks explicit statements on when not to use it or direct comparisons with alternative sibling tools like deep_research.

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