Gunbroker

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint true and destructiveHint false. Description adds behavioral context: it's a probing operation returning per-model scores, mentions cost implications for Anthropic (BYO key). 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 with clear front-loading: action verb 'probe', object, and output. Every clause adds essential information (default model, key requirement, return format, use cases). No wasted words.

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

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

Despite no output schema, the description sufficiently describes return structure (per-model score, confidence, signals, raw_response + combined view). Use cases and parameter interactions are clear. Could benefit from explaining how to interpret confidence or signals.

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 each parameter described. Description adds value by explaining the scoring scale (0-100), default model, and clarifying that _apiKey is only required for Anthropic. This goes beyond the schema definitions.

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 about a business/brand/product/topic and returns a visibility score (0-100) per model. It specifies default model and optional Anthropic probing, distinguishing it from similar sibling tools like 'scan_competitor_ai_presence' by being more generic and scoring-focused.

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 lists use cases (AI-marketing audits, pre-launch brand checks, competitive monitoring) but does not explicitly state when not to use or compare to sibling tools. However, it provides clear context for when the tool is appropriate.

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

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

Annotations already indicate readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds that the tool returns structured answers with pipeworx:// citation URIs, and mentions it fills arguments and routes to the correct tool. This provides 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?

The description is a single paragraph that is front-loaded with a clear preference statement. It packs a lot of information efficiently, but could benefit from slight restructuring (e.g., bullet points) for easier scanning. Overall, it earns its 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 scale (3,300 tools, 737 sources), the description covers its purpose, usage cues, return format with citations, and examples. There is no output schema, but the description adequately explains what the agent can expect. It feels complete for the complexity.

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

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

Schema coverage is 100% with all parameters documented as aliases for 'question'. The description adds that the input is a natural language question, and the schema examples give concrete use cases. While the description doesn't add much beyond the schema, the examples and context elevate it slightly 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 clearly states that the tool routes questions to one of 3,300 tools across 737 sources and returns structured answers with citations. It explicitly distinguishes itself from web search by saying 'PREFER OVER WEB SEARCH' and lists many specific data domains, making the purpose unambiguous.

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

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

The description provides explicit guidance on when to use the tool: for factual questions about structured data like SEC filings, FDA data, stocks, etc. It gives examples and even cues like 'what is', 'look up', 'find'. It also implies when not to use it by contrasting with web search.

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

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

The description goes far beyond the annotations (readOnlyHint, idempotentHint). It details the resolution process, classifier categories, fan-out behavior, response shapes, resolver contract with match confidence, parent event extraction, news fallback handling, and safety conditions for low-confidence and closed markets. This provides comprehensive behavioral insight.

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 excessively long and dense, packed with many details that could be structured more concisely. It lacks summaries or bullet points for key sections, making it hard to parse quickly. While detailed, it sacrifices readability for completeness.

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

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

Given the tool's complexity (3 parameters, no output schema, but many behavioral subtleties), the description is exceptionally complete. It covers edge cases like low-confidence resolution, closed markets, illiquid spreads, news fallback, and detailed response fields. The resolver contract and parent event extractor are fully explained.

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 parameters are already documented. The description adds value by explaining the effect of the 'depth' parameter (quick vs thorough) and providing examples for 'market_input'. It does not repeat schema descriptions but gives contextual usage details.

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

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

The description clearly states the tool's purpose: 'Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call.' It specifies the input types (slug, URL, question text) and output (evidence packet + comparison). This distinguishes it from sibling tools like polymarket_edges and ask_pipeworx, which focus on different aspects.

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

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

The description explicitly states when to use the tool: 'Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z".' It provides clear context and examples of classifiers and fan-outs. However, it does not explicitly exclude alternative tools or state when not to use it.

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

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

Adds rich behavioral context beyond annotations: explains data sources (SEC EDGAR/XBRL, FAERS, FDA), the fix for off-calendar fiscal years, sorting by primary metric, and pipeworx:// citation URIs. Annotations only indicate read-only, idempotent, open world; description fills details.

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

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

Well-structured with front-loaded purpose, then specific details. Every sentence adds information; no wasted words. Could be slightly more concise, but clarity is prioritized.

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

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

Given the tool's complexity (two entity types, multiple data sources, sorting, citations), the description covers all key aspects: what it does, input constraints, data origins, return format, and even a bug fix. No output schema, but return values are described sufficiently.

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 already describes parameters minimally. Description adds value by explaining value formats (tickers/CIKs vs drug names), the limit of 2-5 items, and the meaning of the type enum. Enhances understanding beyond schema.

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

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

The description clearly states the tool compares 2-5 companies or drugs side by side with specific use cases ('compare X and Y', 'X vs Y', 'which is bigger'). It distinguishes between entity types and data sources, and explains it replaces multiple sequential lookups.

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 (comparison questions) and the constraints (2-5 items, entity types). Provides context on data sources and sorting. Lacks explicit mention of alternatives, but the context is clear enough.

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

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

Annotations already indicate read-only and idempotent behavior. The description adds value by explaining the return format (top-N tools with schemas and examples) and that no second lookup is needed, but does not contradict annotations.

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

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

The description is a single paragraph that front-loads purpose and examples. While slightly lengthy, it is well-organized and each sentence adds value.

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

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

Given the tool's role as a discovery mechanism with no output schema, the description sufficiently explains what it returns (tool metadata, schemas, examples) and how to use it, making it complete for an agent.

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

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

Schema coverage is 100%, with examples and alias descriptions already present. The description mentions aliases but does not add significant new meaning 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 'Find tools by describing the data or task' and enumerates specific domains (SEC filings, financials, FDA drugs, etc.), making the purpose explicit and distinguishing it from sibling tools that perform specific actions.

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

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

Explicitly advises to call this tool FIRST when many tools are available and you want to see the option set, providing clear when-to-use guidance. Also includes examples of queries.

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

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

Beyond annotations (readOnly, idempotent, etc.), description details return structure, notes patent API sunset and soft-fail, and clarifies fundamentals fix. Adds significant behavioral context. Minor gap: no mention of error handling for invalid tickers.

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

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

Front-loaded purpose, each sentence adds value. Could slightly trim examples but overall efficient for the complexity.

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

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

Describes most return fields and caveats, but lacks ordering details for filings (only 'up to 5') and doesn't cover error cases or performance expectations. Adequate but incomplete given no output schema.

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

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

Schema covers both parameters (type and value) at 100%. Description adds critical usage details: type currently only 'company', value supports ticker or CIK but not names, and directs to resolve_entity for names. Exceeds baseline 3.

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

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

Description clearly states verb 'Get everything about a US public company in one call.' It identifies the specific resource and distinguishes from sibling tools by listing alternatives like resolve_entity and mentioning it replaces 10+ pack 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?

Explicitly says when to use (user asks 'tell me about X', 'research Acme', etc.) and when not (names not supported — use resolve_entity first). Provides clear context for selection.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, indicating mutation and safe retry. The description rephrases deletion but adds no new behavioral traits beyond the annotations, such as authentication needs or reversibility.

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 action, then usage guidelines. Every sentence is essential with no wasted words.

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

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

Given the tool's simplicity (1 parameter, no output schema) and annotations that cover safety, the description sufficiently covers purpose and usage without gaps.

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

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

The schema already fully describes the single parameter 'key' with 100% coverage. The description adds no additional meaning beyond what the schema provides, achieving 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 verb 'Delete' and the resource 'memory by key', directly indicating the tool's function. It also distinguishes itself from siblings by mentioning pairing with '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?

Explicitly says when to use: when context is stale, task is done, or to clear sensitive data. Also provides alternatives by mentioning sibling tools, giving comprehensive 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?

Beyond the annotations (readOnlyHint, idempotentHint, etc.), the description adds behavioral detail: fetching the page, extracting title/description/links, and emitting standard markdown. It does not mention network considerations or rate limits, but with annotations covering safety, the additional context is valuable.

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

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

The description is three sentences, front-loading the core purpose and output format, followed by process and use cases. Every sentence contributes meaningfully with no redundancy.

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

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

With only two parameters, no output schema, and annotations covering safety, the description adequately explains what the tool does and the format of the output. It does not elaborate on limitations or edge cases, but it is sufficient for an agent to understand the tool's functionality.

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

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

The input schema already has 100% coverage with descriptions for both parameters. The description does not add extra meaning beyond restating that url is required and max_links limits entries. Thus it meets the baseline without adding extra semantic value.

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

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

The description clearly states the tool generates a production-ready llms.txt file from a URL, specifying the output format and use cases. However, it does not explicitly differentiate itself from sibling tools like ai_visibility_check or scan_competitor_ai_presence, which may have overlapping AI indexing purposes.

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 concrete use cases (client indexing, drafting, auditing) that help an agent decide when to use it. It does not explicitly state when not to use it or mention alternatives, but the context is clear enough for typical usage.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description reinforces that this is a public read operation and adds context that only a developer key is needed, with no hidden 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?

Two sentences: the first explains what the tool does and its output, the second clarifies authentication. Every word is necessary, with no redundancy or filler.

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

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

Given the tool's simplicity (2 simple parameters, no output schema), the description thoroughly covers the tool's functionality, return fields, and authentication requirements. No gaps are evident.

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

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

The input schema has 100% coverage with clear descriptions for both parameters ('GunBroker numeric item ID', 'GunBroker developer key (X-DevKey). Required.'). The description adds no additional parameter semantics beyond what the schema already provides, meeting the 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 explicitly states 'Get full details for a single GunBroker listing by item ID' and enumerates the specific fields returned (title, description, prices, etc.), clearly differentiating it from sibling tools like gunbroker_search_items which likely returns a list.

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

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

The description notes that it is 'Public' and 'needs only a GunBroker developer key (_apiKey)', implying no further authentication. While it doesn't explicitly state when to use this tool over siblings, the scope is clear enough for an agent to infer appropriate scenarios.

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

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

Annotations already declare readOnly, openWorld, idempotent, non-destructive. Description adds return field details and public access requirement, complementing annotations without contradiction.

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

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

Two concise sentences, front-loaded with action and resource, no wasted words.

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

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

Despite no output schema, description lists key return fields and covers essential aspects (keywords, public, pagination, sort). Sufficient for a straightforward search tool.

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

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

Schema has 100% coverage with descriptions. Description hints at keyword search and pagination/sort but adds minimal new meaning beyond schema.

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

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

Description clearly states it searches active GunBroker listings by keyword, provides examples, and lists returned fields. Distinguishes from sibling tools like gunbroker_get_item.

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?

Mentions it's public and requires only an API key, and supports pagination and sort. Lacks explicit when-to-use vs alternatives but context implies it's the primary search 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 provide readOnlyHint, idempotentHint, etc. Description adds authentication detail (token exchange each call) and return fields, but does not disclose pagination behavior or error conditions beyond schema.

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

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

Two sentences: first states purpose and contents, second explains authentication. No redundancy, no wasted words.

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

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

With 6 params and no output schema, description covers authentication but omits return format, error cases, and pagination details. Annotations partially compensate (readOnlyHint, etc.).

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 description adds minimal extra meaning beyond listing required credentials (_apiKey, username, password) and describing optional parameters as default/max.

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 verb 'List' and resource 'seller's sold orders', specifies fields returned (order IDs, buyers, item titles, totals, payment and shipping status), and references the API endpoint. It distinguishes from siblings like gunbroker_get_item and gunbroker_search_items.

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?

Implies usage as a seller-only tool due to authentication requirements (username/password), but does not explicitly state when to use versus alternatives or when not to use.

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

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

The description discloses that the tool is free, does not count against the tool-call quota, and is rate-limited to 5 per identifier per day. It also explains that feedback is read daily and influences the roadmap. These details go beyond the annotations, which only indicate non-read-only status.

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, with clear sentences that cover purpose, usage, and constraints. It front-loads the key action and provides all necessary information without redundancy.

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

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

Given the tool's simplicity (3 parameters, one enum, no output schema), the description is fully complete. It explains the tool's purpose, when to use it, how to provide feedback, and important constraints like rate limiting and quota exemption.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the enum options (bug, feature, etc.) and providing guidance on the 'message' field (be specific, 1-2 sentences, 2000 chars). This enhances understanding beyond the schema.

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

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

The description clearly states the tool's purpose: to report bugs, feature requests, data gaps, or praise to the Pipeworx team. It distinguishes itself from sibling tools like 'ask_pipeworx' and 'discover_tools' by focusing on feedback to the team rather than interactions or tool discovery.

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

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

The description provides explicit when-to-use scenarios: for wrong/stale data (bug), missing tools (feature/data_gap), or positive experiences (praise). It also advises on how to frame feedback (in terms of tools/packs, avoid end-user prompts) and mentions rate limits and quota-free usage.

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

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

Annotations already provide readOnlyHint=true and destructiveHint=false. The description adds significant behavioral context: data source (CF analytics-engine), no PII, aggregation method, and caching duration (5min-1h). This supplements the annotations and fully describes the tool's behavior.

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

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

The description is two paragraphs, front-loaded with the core purpose. It is clear and efficient, though the first sentence could be slightly more concise. Overall, it earns its length without extraneous 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?

Given the tool has only one parameter (with enum) and no output schema, the description covers what is returned, the available windows, use cases, data source, and caching. It is fully complete for an agent to understand and invoke the tool correctly.

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

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

Schema coverage is 100% and the schema already describes the 'window' parameter with enum values and explanation. The description mentions windows but does not add new meaning beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description clearly states the tool returns top tools, top packs, and total call volume over configurable windows (24h, 7d, 30d). It explicitly describes the resource (Pipeworx trending data) and the action (retrieving what other agents are calling). This distinguishes it from siblings like discover_tools or ask_pipeworx.

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

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

The description lists three explicit use cases: discovering hot data sources, confirming canonical choice, and seeing alignment. It provides clear context for when to use the tool, though it does not explicitly mention when not to use it or name alternative tools. Still, siblings like discover_tools exist, but the description's guidance is strong.

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

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

Annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false) already indicate safe read operation. Description adds behavioral details: walks child markets, checks ordering, computes partition sum, filters partitions, catches cross-event patterns. 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?

Description is detailed but well-structured, front-loading the core purpose and modes. Every sentence provides necessary context; could be slightly tighter but not verbose.

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

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

No output schema, so description fully explains return values: opportunities array with fields (gap_pp, suggested_trade, reasoning, monotonicity violation context) and partition_check object for event mode. Thoroughly covers complex behavior for both modes.

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

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

Input schema has 2 parameters with 100% schema coverage. Description goes beyond schema by providing examples ('when-will-bitcoin-hit-150k', 'Strait of Hormuz...') and explaining how each parameter determines mode, adding meaning.

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

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

Description clearly states tool finds arbitrage opportunities on Polymarket via specific algorithms (monotonicity violations, partition-sum checks). It distinguishes two distinct modes ('event' and 'topic'), differentiating it from sibling tools like polymarket_edges and polymarket_kalshi_spread.

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

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

Explicitly explains when to use each mode: pass a single event slug for event mode, a seed question for topic mode. Provides context on semantic anchor (Jaccard similarity) and partition filter conditions. Does not explicitly state when not to use, but covers usage well.

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

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

Annotations already mark the tool as readOnlyHint and idempotentHint, but the description adds extensive behavioral detail: caching at 1h, slippage handling, edge computation across five model families, diagnostic funnel counters, and filter knobs. This far exceeds what annotations provide.

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 long and detailed, with dense technical specifications. While front-loaded with purpose, it could be more concise by separating standard details from optional model explanations. The sentence structure is packed, but every part serves a purpose for advanced users.

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 having 9 parameters and no output schema, the description thoroughly covers all aspects: model families, filter knobs, response structure including diagnostics, caching, and limitations (e.g., Fed bets excluded from ranking). It fully compensates for the missing output schema and provides complete context for an agent to use the tool correctly.

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

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

Schema coverage is 100% with good descriptions, but the tool description adds significant context beyond schema: e.g., explaining that min_kelly skips opportunities too small for sensible betting, that slippage_pp subtracts from raw edge before ranking, and that min_partition_leg_kelly applies to per-leg Kelly inside partitions. This enhances understanding beyond basic 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 scans top Polymarket markets for discrepancies between Pipeworx data and market price, serving as a daily betting advisor. It specifies the verb 'Scan' and distinct resource, and its detailed model families differentiate it from generic market query tools like polymarket_arbitrage.

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

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

The description explicitly frames its use case ('what should I bet on today') and notes that Fed bet signals surface but are unreliable, implying when to avoid relying on that segment. It does not directly name alternatives among sibling tools, but the unique algorithm and model descriptions provide implicit guidance on when this tool is appropriate.

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

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

Description adds extensive behavioral context beyond annotations: two modes, response structure, safety fields (compatibility_warning, temporal_alignment), skipped counters, and warnings when spreads are meaningless. 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?

Well-structured with paragraphs and bold for key terms. Front-loaded with core purpose. Somewhat verbose with detailed safety field explanations, but each sentence adds meaningful nuance. Could be slightly trimmed 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, description explains response fields (leg prices, top_spreads_pp, compatibility_warning, temporal_alignment, skipped counters) in detail. Covers edge cases and safety warnings. Could benefit from a concrete example response for full completeness.

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

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

Schema coverage is 100% with descriptions for each param. Description adds value by explaining how parameters interact (topic vs explicit, overriding), listing the 10 topic shortcuts, and providing examples in input schema. Exceeds baseline 3 by adding behavioral nuance.

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 tool computes cross-venue spread between Kalshi and Polymarket for same resolving question. Differentiates from siblings like polymarket_arbitrage (Polymarket only) by focusing on cross-venue comparison. Specific verb 'spread' and resource 'two venues' with two modes.

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

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

Description explains two modes (topic shortcuts and explicit tickers) and warns that most pre-mapped topics return compatibility warnings. Does not explicitly compare to sibling tools, but provides clear context on when the tool is applicable and its limitations.

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 show readOnlyHint, idempotentHint, destructiveHint. Description adds scoping details and pairing with related tools, providing extra context beyond annotations.

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

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

Three sentences, front-loaded with primary action, then usage context and scoping. Efficient but slightly verbose with pairing mention that could be separate.

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 adequately covers behavior, scoping, and tool relationships. Missing explicit return format but compensated by clear 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?

Only one parameter key with 100% schema coverage. Description adds meaning by explaining omission lists all keys, enhancing 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 specifies retrieving a saved value via remember or listing all keys when omitted. Distinguishes from siblings (remember, forget) by naming them explicitly.

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

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

States when to use (look up context stored earlier) and pairs with remember and forget. Mentions scoping to identifier but lacks explicit when-not 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?

Discloses detailed behavior beyond annotations: parallel fan-out to SEC EDGAR, GDELT→GNews fallback, USPTO soft-fail, return format (grouped changes, total_changes, citation URIs). Contradicts no annotations and adds value.

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 and front-loaded with key usage, but slightly lengthy due to detailed source descriptions. Every sentence adds value, though slightly more compression possible.

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

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

Covers all necessary aspects: multiple data sources, fallback logic, parameter formats, return structure, and sibling differentiation. No output schema, but description sufficiently explains what the tool returns.

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

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

Adds meaning beyond schema: explains `since` accepts ISO or relative shorthand with examples ('7d', '30d', '3m', '1y'), suggests '30d' or '1m' for typical monitoring; notes `type` only supports 'company'; clarifies `value` accepts ticker or CIK with examples.

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

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

The description clearly states the tool's purpose: 'What's new with a company in the last N days/months?' with specific use cases like 'news on Apple this month'. It distinguishes the tool from the sibling entity_profile by noting when to use the alternative for static profiles.

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

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

Explicitly guides when to use this tool (for updates, news, change-monitoring) and when not to (use entity_profile for static profiles). Names the alternative tool directly, providing clear usage boundaries.

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

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

Annotations are complete (readOnlyHint=false, idempotentHint=true, destructiveHint=false). Description adds persistence details (24-hour retention for anonymous, persistent for authenticated) and scope (by agent identifier). No contradictions.

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

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

Three sentences, each essential. Purpose first, then usage, then behavioral details. No wasted words.

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

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

With annotations and 100% schema coverage, the description is complete. It covers purpose, usage, persistence, and relationship to sibling tools.

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

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

Schema already describes both parameters with clear text. Description adds examples of keys and values, enhancing understanding of structure and use cases.

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 the tool saves data for reuse across conversations or sessions. Uses specific verbs ('Save') and resources ('data'), and distinguishes from siblings like 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 tells when to use ('discover something worth carrying forward') and mentions pairing with recall/forget. Could be more explicit about when not to use, but naming siblings provides context.

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

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

Annotations indicate readOnlyHint, idempotentHint, and destructiveHint false. The description adds value by revealing that the tool cascades through multiple endpoints internally, saving 2-3 manual lookups. 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 brief, front-loaded with purpose, and each sentence contributes necessary information. 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?

Despite lacking an output schema, the description fully explains the return values for both entity types, including specific fields and citation URIs. It is complete for an agent to understand what to expect.

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

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

Schema coverage is 100%, and the description significantly enhances parameter understanding by providing concrete examples and formats for both 'type' and 'value' parameters (e.g., ticker, CIK, brand name).

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 specifies the verb 'resolve' and the resource 'user-spoken name to canonical identifiers'. It clearly states the tool's purpose and distinguishes it from siblings by emphasizing that it returns IDs needed by 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 provides explicit guidance: 'Use FIRST when you have a name but need an ID.' It details supported types and acceptable inputs, but does not explicitly state when not to use this tool or mention alternative tools, which would make it a 5.

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

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

Annotations already declare safe read-only, idempotent, non-destructive behavior. The description adds behavioral context: 'Probes each entity with ai_visibility_check, ranks by score, surfaces which is most/least recognized.' It explains the internal process and output fields (score, confidence, signal density). However, it does not mention any potential limitations or performance considerations.

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 with 4 sentences. It is front-loaded with the main purpose, followed by process, use case, and output. Every sentence adds value without redundancy. No wasted words.

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

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

Given the tool's complexity (4 parameters, no output schema, good annotations), the description is complete. It explains the process, the use case, and the output format (ranked list with score, confidence, signal density). It sufficiently 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?

Schema coverage is 100% with parameter descriptions. The description adds value beyond the schema by clarifying that the first entity in the array is treated as the 'subject' for narrative and that the context parameter disambiguates common names. This provides useful guidance for using the parameters effectively.

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: 'Compare AI visibility across multiple entities side-by-side.' It uses specific verbs ('compare', 'probes', 'ranks') and resource ('AI visibility'). It distinguishes from sibling tools like 'ai_visibility_check' by emphasizing multi-entity comparison and ranking.

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

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

The description provides a concrete use case: 'Useful for competitive AI-marketing audits: does Claude know about us as well as our competitors?' It implies when to use (comparing brand recognition) but does not explicitly exclude alternatives or mention when not to use. Sibling tools like 'ai_visibility_check' and 'compare_entities' are not directly contrasted, but the description gives sufficient context.

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds crucial behavioral details: graceful partial failures, bundlephobia's first measurement taking 5-30s, and sources_failed list on timeout.

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 purpose but contains somewhat lengthy details. However, every sentence adds value; no redundancy. Could be slightly more concise but effective.

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

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

Given tool complexity (composite check), no output schema, but description explains return structure: summary block, per-advisory detail, links, alternatives. Combined with annotations, this is fully sufficient.

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

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

Schema covers 100% of parameters. Description adds nuance: 'package' accepts scoped packages (e.g., @types/node) and 'version' defaults to latest. This provides useful context beyond the schema.

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

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

Description clearly states it's a composite check for npm packages covering license, advisories, version history, and bundle size. It distinguishes itself from siblings by specifying NPM-only scope and mentioning alternatives (deps.dev for other ecosystems).

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

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

Explicit usage guidance: 'whenever an agent asks "is X safe / popular / small" or "what does adding lodash cost me"'. Also notes NPM-only limitation and suggests direct deps.dev for other ecosystems.

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. Description adds value by detailing the return structure (verdict categories, extracted form, actual value with citation, percent delta) and the replacement of multiple sequential calls. No contradictions with annotations; description complements them.

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

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

Description is concise at about 4 sentences, with action verbs at the start ('Fact-check, verify, validate...'), then use cases, scope, and return values. No unnecessary information. Well-structured for quick understanding.

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

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

Given low complexity (1 param, no output schema) and rich annotations, the description is complete. It explains the tool's function, usage, scope, and output. The return types are described textually, compensating for lack of output schema.

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

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

Only one parameter (claim) with schema coverage 100%. The schema already describes the parameter adequately with examples. The tool description adds extra context by explaining the format of the claim and what types of claims are supported, reinforcing the schema but not introducing new parameters.

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

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

Description clearly states the tool's purpose: fact-check, verify, validate, or confirm/refute a natural-language factual claim against authoritative sources. It specifies the scope (company-financial claims via SEC EDGAR + XBRL) and gives clear examples of use cases. It distinguishes itself from siblings by noting it replaces 4-6 sequential calls, showing awareness of alternative approaches.

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

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

Explicitly states when to use: 'when an agent needs to check whether something a user said is true' and provides example query phrasings. It also implies limitations by stating the domain (company-financial claims for public US companies), guiding against misuse for other claim types. While not explicitly saying 'when not to use', the scope is clear enough.

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