Scream Void

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

No annotations provided, so description must carry full burden. It mentions that Pipeworx picks tools and fills arguments, but does not disclose limitations, potential latency, or any destructive actions. Lacks detail on error handling or query complexity constraints.

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 and front-loaded with the core purpose. Examples are helpful. Could omit the last sentence about not needing to browse tools, as it's implied.

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 (one param, no output schema, no nested objects), description adequately covers purpose and usage. Would benefit from mentioning if there are any constraints on question types or rate limits.

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 'question'. Description adds no additional semantics beyond the schema's description; it only gives examples. 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 accepts natural language questions and returns answers from the best data source. It specifies verb ('Ask'), resource ('best available data source'), and distinguishes from siblings by emphasizing it auto-selects 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?

Description implies usage ('just describe what you need') and provides examples, but does not explicitly say when not to use this tool or mention alternatives. With siblings like 'discover_tools' and 'recall', guidance on when to use each would help.

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

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

With no annotations, the description carries full burden. It discloses what data is returned for each type (e.g., revenue, adverse events), mentions paired data and resource URIs, and notes the efficiency benefit. It does not specify if the operation is read-only or any rate limits, but the behavioral context 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 three sentences with no fluff. It front-loads the core purpose, then details types, and ends with a value proposition. 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 no output schema, the description adequately explains the return format (paired data + resource URIs). It covers purpose, parameters with examples, and the efficiency benefit. No obvious gaps for this tool's complexity.

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

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

Schema coverage is 100%, setting baseline at 3. The description adds value by explaining the type enum and providing concrete examples for values (e.g., ['AAPL','MSFT'] for company, ['ozempic','mounjaro'] for drug), which goes beyond the schema descriptions.

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

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

The description clearly states the tool compares 2-5 entities side by side, specifies the two types (company/drug) with distinct metrics, and adds the efficiency gain. It is specific and distinguishes from sibling tools by its unique function.

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

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

The description provides clear context for when to use the tool (comparison of entities, for company or drug types) and highlights efficiency over sequential calls. However, it does not explicitly state when not to use it or mention 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?

No annotations are provided, so the description must cover behavior. It states the tool returns 'the most relevant tools with names and descriptions', which is basic but sufficient. It does not disclose potential limitations like search relevance or performance, but with no annotations, a score of 3 is appropriate.

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 short sentences, each earning its place: purpose, return value, and usage guidance. No filler or redundancy. Highly efficient.

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

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

Given the tool's simplicity (2 params, no output schema, no nested objects), the description fully covers what an agent needs: what it does, what it returns, and when to use it. Complete for the tool's complexity level.

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%, meaning both parameters are documented in the schema. The description adds no extra meaning beyond what the schema provides; it mentions 'natural language description' but that's implied. Baseline 3 is correct since the schema already explains 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 verb 'Search' and the resource 'Pipeworx tool catalog'. It specifies the purpose: to find relevant tools by describing a need. This distinguishes it from sibling tools like 'ask_pipeworx' (question answering) or 'recall' (memory retrieval).

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

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

Explicitly states 'Call this FIRST when you have 500+ tools available and need to find the right ones for your task', giving clear when-to-use guidance. It implies using this before other tools to narrow down options, which is helpful for an AI 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?

No annotations provided, so description carries full burden. Describes what the tool does (returns aggregated data) and mentions output format (pipeworx:// URIs), but does not disclose any behavioral traits like side effects, error handling, or performance implications. Adequate but not exhaustive.

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 with no redundancy. First sentence states purpose, second details contents, third provides alternative. Front-loaded and efficient, 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 the moderate complexity (2 params, no output schema), the description adequately covers the tool's function and usage. It explains the input format and output nature (citation URIs). However, it lacks details on the response structure beyond URIs, which could be improved but is not critical for selection.

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 documented. Description adds value by explaining the current limitation of type to 'company' only, and clarifying that value accepts tickers or CIKs, with a note that names are not supported (use resolve_entity). This practical guidance 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?

The description clearly states it returns a full entity profile aggregating data from multiple Pipeworx packs in one call. For company type, it explicitly lists the specific data sources (SEC filings, revenue/income/cash from XBRL, patents, news, LEI). This differentiates it from sibling tools like resolve_entity and usa_recipient_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?

Explicitly advises against using for federal contracts (calls usa_recipient_profile directly) and instructs to use resolve_entity for name inputs. This provides clear when-to-use and when-not-to-use guidance, along with 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 are missing, so description carries full burden. It states deletion, but lacks details on irreversibility, authorization needs, or side effects. Acceptable for a simple key-based delete with no 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 sentence, front-loaded with action and object. 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 the simple input schema (1 required string parameter) and no output schema, the description adequately covers the tool's purpose. Could mention that deletion is permanent, but not critical for a straightforward delete.

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 single parameter 'key' is well-described in the schema. The description reinforces its purpose ('by key'). No additional meaning needed beyond what 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 uses a specific verb ('Delete') and resource ('stored memory by key'), clearly stating the action. It distinguishes from siblings like 'remember' (store) and 'recall' (retrieve).

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

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

The description implies usage when a stored memory needs to be removed, but provides no guidance on when not to use it or alternatives. Context from siblings suggests recall/remember for other operations, but no explicit 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?

With no annotations provided, the description carries the full burden of disclosing behavior. It mentions rate limits, the requirement not to include end-user prompts, and that the tool is free. It lacks details on what happens after submission (e.g., confirmation), but for a feedback tool this is acceptable.

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

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

The description is three sentences with no unnecessary words. The first sentence immediately states the purpose, the second adds usage guidelines, and the third covers constraints. Every sentence earns its place, making it highly concise and well-structured.

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

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

For a simple feedback tool with 3 parameters (all described in schema), the description covers purpose, usage guidelines, and rate limits. It does not explain the absence of an output schema, but that is not needed. Minor missing detail: the optionality of context is implied but not stated. Overall, it is sufficiently 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 description coverage is 100%, so the baseline is 3. The description adds general context (e.g., use cases) but does not significantly augment the parameter meanings beyond what the schema already provides. It reinforces the message content rules but adds no new semantic information.

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: 'Send feedback to the Pipeworx team.' It lists specific use cases (bug reports, feature requests, etc.) and distinguishes itself from siblings like ask_pipeworx or discover_tools by focusing on giving feedback rather than retrieving information.

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 and how to format messages (describe what you tried, not verbatim prompts). It also notes the rate limit (5 per day). While it does not explicitly list when not to use it, the context is clear enough for correct 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?

Description adds value beyond annotations (none provided) by clarifying the dual behavior (retrieve vs list). However, no details on memory persistence, limits, or error behavior are given.

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 the primary action, 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 simple tool (one optional param, no output schema), description is adequate but could mention that retrieval returns a single memory value vs list of keys.

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 single 'key' parameter described. The description adds context by stating omitting key lists all keys, which matches the schema's optionality.

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 'Retrieve a previously stored memory by key, or list all stored memories (omit key)', specifying both retrieval and listing modes, and differentiates from sibling 'remember' and 'forget'.

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

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

Explicitly states when to use the tool ('to retrieve context you saved earlier in the session or in previous sessions') and implies the alternative of omitting key for listing.

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

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

With no annotations, the description fully discloses behavior: parallel fan-out to multiple sources, accepted since formats (ISO or relative), and return structure (structured changes, count, URIs). It adds significant value beyond the schema.

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

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

The description is a single paragraph packed with information; every sentence is useful. It could be slightly more structured (e.g., bullets) but remains efficient and relevant.

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

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

The description covers purpose, parameters, usage, and return format. It omits error handling or limits but is fairly complete given no output schema. Additional context about authentication or rate limits would be beneficial.

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 crucial semantic details: examples of since formats ('7d', '1y'), explanation of value as ticker or CIK, and that type is limited to 'company'. This enriches the schema's bare 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: finding what's new about an entity since a given time. It specifies the entity type (company) and the sources used (SEC EDGAR, GDELT, USPTO), effectively distinguishing it from siblings like entity_profile or compare_entities.

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

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

The description explicitly suggests use cases: 'brief me on what happened with X' or change-monitoring workflows. It does not explicitly state when not to use or provide alternatives, but the context and sibling list make the usage clear.

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

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

No annotations are provided, so the description must disclose behavioral traits. It explains memory persistence: authenticated users get persistent memory, anonymous sessions last 24 hours. This goes beyond basic storage description, though it doesn't mention data size limits or overwrite behavior (e.g., if key exists).

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

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

Two sentences with no wasted words. First sentence states the core action, second provides usage guidance and behavioral detail. Well front-loaded and efficient.

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

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

Given no output schema, the description could mention return values (e.g., success confirmation). However, for a simple key-value store with clear schema and annotations-free context, it is mostly complete. The sibling tools suggest a memory system, and this description fits well.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by clarifying the purpose of parameters beyond the schema: key examples like 'subject_property' and value examples like 'findings, addresses, preferences, notes' help the agent understand expected formats 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 stores a key-value pair in session memory, with specific examples of use cases like saving findings, preferences, or context. The verb 'store' and resource 'key-value pair in session memory' are precise and distinguish it from sibling tools like 'recall' (retrieve) and 'forget' (delete).

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

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

Provides explicit context for when to use: to save intermediate findings, user preferences, or context across tool calls. It also mentions persistence differences for authenticated vs anonymous users, but does not explicitly state when not to use it or compare to alternatives like 'recall' or 'forget'.

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

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

No annotations are provided, so the description carries the full burden. It mentions that it is a single call replacing multiple lookups and lists output fields, but does not disclose error handling, authorization requirements, rate limits, or potential side effects. Major behavioral traits are missing.

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 with no redundancy. First sentence states purpose, second specifies input formats and version, third describes output and benefit. Highly 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?

For a tool with 2 simple parameters and no output schema, the description covers the key aspects: input types, output fields, and efficiency gain. It lacks details on error scenarios or edge cases, but is adequate for typical 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% with descriptions for both parameters. The description adds context about v1 support and examples, but largely mirrors the schema. As baseline is 3 when schema is complete, the description adds minimal extra 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 resolves an entity to canonical IDs, specifying the verb 'resolve' and the resource 'entity'. It differentiates from previous multi-call approaches by mentioning it replaces 2–3 lookup calls, making the purpose distinct.

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

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

The description explains when to use it (to get canonical IDs like ticker, CIK, name, URIs) and what inputs it accepts (ticker, CIK, name). It does not explicitly state when not to use or compare to siblings, but the context is sufficient for basic 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?

The description discloses the core behavior (receiving a random number) but lacks details on side effects, authentication, or error handling. With no annotations, the description carries full transparency burden, and while adequate for a simple tool, it could be more thorough.

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 states the action and outcome, the second provides usage guidance. Each sentence is purposeful with no redundancy.

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

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

Given the tool's simplicity and the presence of an output schema (implied), the description is nearly complete. It covers the essential purpose and usage, though it could mention whether the random number generation is deterministic or has any constraints.

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

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

Input schema covers 100% of parameters. The description adds colorful context ('Your scream. Type anything. It will not help.') but does not provide additional semantic meaning beyond what the schema already provides for the 'scream' and 'intensity' 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's action ('Scream into the void') and result ('receive a random number'), with a specific verb-resource combination that uniquely distinguishes it from siblings like 'ask_pipeworx' or 'compare_entities'.

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

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

It provides explicit use cases ('when you need an unpredictable value or want to add chaos to your logic'), offering clear context for appropriate invocation, though it does not mention exclusions or alternatives.

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

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

Despite no annotations, the description details return values (verdict types, structured form, actual value with citation, percent delta) and notes v1 limitations. It conveys read-only, non-destructive 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?

Two sentences: first defines purpose and supported claims, second details outputs and benefits. No wasted words, key information 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?

Single-parameter tool with no output schema; description sufficiently covers purpose, inputs, outputs, and limitations. Could slightly expand on handling out-of-domain claims.

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; description adds examples and clarifies domain-specific format expectations, adding value beyond the schema.

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

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

Clearly states the tool fact-checks natural-language claims against authoritative sources, specifies domain (company-financial, US public) and data sources (SEC EDGAR, XBRL), and lists return values. No sibling overlap.

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 the tool's efficiency benefit (replaces 4-6 agent calls) and domain limitation, but does not discuss when not to use it or alternatives for other claim types.

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