Fdic

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

Discloses output structure (per-model {score, confidence, signals, raw_response} + combined view) and cost for Anthropic. Annotations already indicate read-only and idempotent; description adds value 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 with no redundancy. Action, default behavior, return structure, and use cases clearly presented. Front-loaded with primary purpose.

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

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

No output schema, but description details return format. All parameters explained. Use cases and cost considerations provided. Adequate for the tool's complexity.

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

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

Schema descriptions cover 100% of parameters; description adds context (default model behavior, API key usage, disambiguation for context field) that enhances understanding.

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

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

Description specifies verb 'probe' and resource 'LLMs', states scoring visibility (0-100) per model, and distinguishes from siblings like 'entity_profile' or 'scan_competitor_ai_presence' by focusing on AI awareness.

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

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

Explicitly lists use cases: 'AI-marketing audits, pre-launch brand checks, competitive monitoring'. Mentions default model and optional Anthropic key with cost implication, but does not contrast 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?

No annotations are provided, so the description must disclose behavioral traits. It explains that the tool 'picks the right tool, fills the arguments, and returns the result,' indicating autonomous decision-making. However, it does not disclose limitations like potential latency, error handling, or that it may rely on other tools with their own restrictions. The description is clear but lacks depth on failure modes or authorization needs.

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 very concise (three sentences) and front-loaded with the core purpose. Every sentence adds value: first sentence states what it does, second explains how it works, third gives examples. 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 (one parameter, no output schema, no nested objects), the description is reasonably complete. It explains the high-level behavior and usage. However, it could mention that results may come from various underlying tools and that response format may vary, but this is a minor gap. The examples help contextualize usage.

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 parameter 'question' described as 'Your question or request in natural language.' The description adds context by stating it accepts 'plain English' and provides examples, but the schema already captures the parameter's purpose adequately. The description does not add much beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: it takes a natural language question and returns an answer by selecting the appropriate underlying tool and filling arguments. It distinguishes itself from siblings by acting as a universal interface, contrasting with specific tools like fdic_failures or discover_tools.

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

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

The description explicitly tells when to use this tool: when you want to 'just describe what you need' without browsing tools or learning schemas. It provides examples, but does not explicitly state when not to use it or mention alternatives, though the context of sibling tools implies those are for specific structured 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?

Annotations already declare read-only and open-world. Description adds behavioral details: resolves market, classifies bet, fans out to packs, returns evidence packet and comparison. No contradictions.

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

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

Single paragraph with clear flow: what it does, inputs, processing, output, use cases, value proposition. Slightly long but 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 2 params and no output schema, description adequately covers input formats, processing steps, and output (evidence packet + comparison). Mentions core demo product context. Could discuss limitations.

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 with descriptions. Description adds value by clarifying market parameter formats (slug, URL, question text) and depth options ('quick = 2-3 sources, thorough = full fan-out').

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

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

Clearly states it researches a Polymarket bet by pulling Pipeworx data, specifying inputs (slug, URL, question text). Differentiates from siblings like ask_pipeworx by being specialized for bets.

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

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

Provides explicit use cases ('should I bet on X?', etc.) and explains fan-out logic. Does not explicitly state when not to use, but 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?

Discloses data sources (SEC EDGAR, FDA) and return format (paired data + URIs), but lacks details on authentication, rate limits, or side effects. No annotations provided.

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

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

Three concise sentences, front-loaded with purpose, no fluff, 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?

Adequately covers tool's purpose and parameters; could benefit from more details on return data structure or error handling, but solid overall.

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%; description adds examples and constraints (tickers/CIKs, drug names, item count), enhancing 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?

Clearly states verb 'Compare' and resource 'entities' (companies or drugs), with specific data fields per type. Distinct from sibling tools like fdic_financials 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?

Implies usage for efficient side-by-side comparison, replacing multiple calls, but does not explicitly state when not to use 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 provided, but description adds value by stating it returns the most relevant tools with names and descriptions, implying a semantic search. Could mention that it does not execute tools, but context is clear.

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

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

Three concise sentences, each adding value: purpose, usage guidance, and explicit first-call instruction. No fluff.

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

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

Given simplicity of tool (search with query, optional limit), description covers all necessary context. No output schema needed as returns tools list.

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 need not add much. However, description could hint at the nature of 'query' parameter (e.g., semantic search). Already implied by 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?

Description clearly states the tool searches a catalog by describing needs, returns relevant tools with names and descriptions. Distinguishes from siblings as a meta-search tool for tool discovery, with no overlap with 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?

Explicitly advises to call this FIRST when 500+ tools are available and need to find the right ones. Provides clear usage 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?

No annotations provided, so description carries full burden. It mentions it returns pipeworx:// URIs, replaces 10-15 calls, and lists data sources. Lacks details on auth needs, rate limits, or error conditions, but covers main behavioral traits.

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

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

Four sentences, front-loaded with purpose, then details, then exclusion. No fluff, every sentence adds value.

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

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

Covers the tool's complexity well: lists data sources, mentions replacement of multiple calls, and provides exclusion. Missing output structure details beyond URIs, but no output schema exists.

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%, baseline 3. Description adds meaning by explaining type enum limitations (only company), value can be ticker or CIK, and explicitly states names not supported, directing to resolve_entity.

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

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

The description clearly states the tool provides a full profile of an entity across all relevant Pipeworx packs, with specific details for company type. It distinguishes itself from siblings 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 says when to use (for company full profile) and when not (for federal contracts, use usa_recipient_profile). Also recommends using resolve_entity for names.

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

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

Annotations are empty, so the description carries full burden. It discloses that it returns specific fields and allows date range filtering. However, it does not mention if it supports pagination, rate limits, or any ordering beyond 'sorted by most recent.' Since annotations provide no safety hints, a score of 3 is appropriate as the description is adequate but lacks depth.

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

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

The description is two sentences, concise and front-loaded with the main purpose. Every word earns its place; no fluff.

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

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

Given the tool is a simple list with three optional parameters and no output schema, the description covers the core functionality and return fields. It could mention default limit or sorting direction (descending by date), but it is largely complete. A 4 reflects minor 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?

Schema coverage is 100%, so the schema already describes all three parameters. The description adds context that the parameters are for date filtering but does not add new meaning beyond what the schema provides. Baseline 3 is correct.

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 lists FDIC bank failures sorted by most recent, and it distinguishes itself from sibling tools like fdic_search_institutions (which likely searches) and fdic_summary (which likely summarizes). It also explicitly mentions optional date filtering and the fields returned.

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

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

The description specifies when to use this tool (list failures, filter by date) and implies when not to (e.g., for general institution search or financials). It does not explicitly name alternatives but the sibling context provides that. It could be improved by explicitly saying 'Use this for recent failure records; for broader institution data use fdic_search_institutions.'

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 the full burden. It discloses that data is quarterly, returns specific metrics, and hints at default pagination (limit=8). However, it does not mention read-only nature, rate limits, or whether historical data is complete.

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, no fluff. Purpose and key output details are front-loaded. Every sentence adds value.

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

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

Given no output schema, the description lists return fields well. For a simple query tool, this is nearly complete. Minor gap: no mention of error handling if cert invalid.

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

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

Schema coverage is 100%, so the schema already documents both parameters. The description adds context by explaining the default limit (8 = 2 years) and listing metrics, but this is not essential 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 verb ('Get'), resource ('financial call report data for a bank'), and identifier ('by CERT number'). It also lists the specific financial metrics returned, distinguishing it from siblings like fdic_failures or fdic_search_institutions.

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

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

The description implies usage context (querying bank financials by cert number) but does not explicitly state when to use this tool versus alternatives. No guidance on when not to use or what prerequisites exist (e.g., requiring a valid cert from fdic_search_institutions).

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

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

Annotations are empty, so the description carries the full burden. It discloses that the tool returns a full institution profile with fields like name, location, assets, and regulatory details. However, it does not mention whether the tool is read-only (presumably safe), any rate limits, or what happens if the cert number is invalid. A 3 is adequate given no contradictions.

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

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

The description is two sentences, clearly structured: first sentence states the primary action (get detailed info by cert), second sentence lists what the return includes. Every word earns its place; 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 low complexity (1 required param, no nested objects, no output schema), the description is complete enough: it covers the purpose, identifier, and return fields. It could optionally mention error handling or data recency, but that is not critical. The sibling tool list helps provide context.

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

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

The schema has 100% description coverage for the single parameter 'cert', already explaining it's the FDIC certificate number with an example. The description adds the context that this is a unique identifier for a bank, but does not add significant 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's purpose: to get detailed information for a specific FDIC-insured bank by its CERT number. It specifies the resource (bank) and the identifier (CERT number), and distinguishes itself from sibling tools like fdic_search_institutions (search vs. get) and fdic_failures (different focus).

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

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

The description implies when to use: when you have a specific CERT number and want full institution details. It does not explicitly state when not to use it or name alternatives, but the context of sibling tools (e.g., fdic_search_institutions for searching) provides some differentiation. A clear exclusion statement would improve 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?

No annotations provided, so description must stand alone. It discloses it's a read-only search and lists return fields, but doesn't mention pagination, performance, or any side effects. Adequate for a simple search.

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, concise and front-loaded with purpose. Every sentence adds value. Could be slightly more structured 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?

With no output schema, description lists return fields. Lacks details on ordering, result count, or behavior when no results. Sufficient for simple search but leaves 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?

Schema coverage is 100% (both parameters documented in schema). The description adds context that search is by name and lists returned fields, but doesn't add meaning beyond the schema for parameters themselves.

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 states it searches for FDIC-insured banks by name and lists return fields. It distinguishes from siblings like fdic_failures and fdic_financials by focusing on institutions, but could be clearer that it returns summary data, not full details.

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

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

No explicit guidance on when to use vs. alternatives like fdic_get_institution (which likely returns a single institution's full details). The description implies search use but doesn't specify when not to use or mention siblings.

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

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

With no annotations provided, the description carries the full burden of disclosing behavior. It clearly states the tool returns aggregate data for a given date, listing the included metrics (total assets, deposits, net income, etc.). This is sufficient for an agent to understand the tool's output and safety (read-only query). No contradictions with annotations since none exist.

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

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

The description is a single sentence of moderate length, immediately front-loading the key verb and resource. Every phrase adds value: 'aggregate industry summary data', 'all FDIC-insured institutions', 'given reporting date', and the list of returned metrics. 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?

Given the tool's simplicity (single parameter, no output schema, no nested objects) and the presence of sibling tools that cover specific aspects, the description is complete. It defines what data is returned, the required input, and implicitly that no other parameters are needed. An agent can confidently invoke this tool based solely on the description and schema.

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

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

Schema description coverage is 100%, so the schema already documents the single required 'date' parameter. The description reinforces the date's purpose ('for a given reporting date') and the description in the schema adds format and example, but the description's mention of the date scope adds marginal value by connecting it to the aggregate context. The combination is clear.

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

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

The description clearly states the tool retrieves aggregate industry summary data for FDIC-insured institutions. It specifies the action ('get'), the resource ('aggregate industry summary data'), and the scope ('for a given reporting date'). The sibling tools like 'fdic_failures', 'fdic_financials', 'fdic_get_institution', and 'fdic_search_institutions' focus on specific subsets, making 'fdic_summary' distinct as the summary-level aggregator.

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 for obtaining a high-level snapshot of the banking industry, which differentiates it from sibling tools that drill into specific institutions or failures. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide guidance on prerequisites or frequency of data updates.

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 correctly indicates a destructive action ('Delete') but does not mention permanence, reversibility, or authorization requirements. For a single-parameter tool, the minimal description is acceptable but lacks additional context.

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

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

The description is a single sentence, perfectly concise, front-loaded with the verb and resource. Every word is necessary.

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 required parameter, no output schema), the description is complete enough. It explains what the tool does and how to use it. No missing information is critical for correct invocation.

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

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

The input schema has 100% description coverage (key described as 'Memory key to delete'). The description adds no new parameter info beyond the schema, but with full coverage, the schema does the heavy lifting. A score of 4 reflects that the schema is sufficient.

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', the resource 'stored memory', and the method 'by key', distinguishing it 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 does not provide explicit guidance on when to use this tool vs alternatives. However, the sibling names imply a CRUD pattern, and the description 'by key' indicates the required identifier, offering some implicit usage 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 indicate read-only, open-world, idempotent, and non-destructive behavior. The description adds context by explaining the underlying process: fetching the page, extracting title/description/key links, and emitting the standard markdown format. This goes 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 front-loads the core purpose and follows with usage examples. It is concise without unnecessary details, though it could be slightly more structured.

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

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

The description covers the tool's behavior, output format, and use cases. Since there is no output schema, the description adequately explains the return value ('single text blob') and its intended placement. Additional details about edge cases or error handling are not critical for this simple tool.

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

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

Schema coverage is 100% with clear descriptions for both parameters. The description does not add any additional meaning beyond what is already in the schema, so a baseline score of 3 is appropriate.

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

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

The description clearly states it generates a production-ready llms.txt file for any URL, specifying the format and use cases. This distinguishes it from siblings like ai_visibility_check or resolve_entity, which serve different 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 lists three explicit use cases (indexing, drafting, auditing) that help the agent understand when to use the tool. However, it does not provide when-not-to-use guidance or alternative tools for related tasks.

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

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

With no annotations, the description carries the full burden. It discloses a rate limit (5 messages per identifier per day) and indicates the tool is free. While it doesn't detail authorization or persistence, this is sufficient for a feedback tool.

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

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

The description is extremely concise—only three sentences—with the main purpose in the first sentence. Every sentence adds necessary information (usage, guidelines, rate limit) 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 params, optional nested object, no output schema), the description covers purpose, usage, content guidelines, and rate limiting. It could mention what happens after submission, but overall it is complete enough for an agent to invoke correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by reinforcing the type categories ('bug, feature, data_gap, praise') and providing content guidelines for the message parameter, which complements the schema's own 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 explicitly states 'Send feedback to the Pipeworx team' and lists specific use cases (bug reports, feature requests, missing data, praise), making the tool's purpose very clear. It distinguishes itself from sibling tools like ask_pipeworx, which are for queries, not feedback.

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

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

The description provides clear context on when to use this tool (for bug reports, feature requests, etc.) and gives guidelines on content (describe what you tried, do not include end-user prompt verbatim). However, it does not explicitly exclude alternatives or contrast with sibling tools, so it lacks a full when-not-to-use statement.

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 detail beyond annotations: 'Self-aggregating signal', 'derived from CF analytics-engine, no PII, just (pack, tool, count)', and caching durations. Annotations already indicate readOnly, idempotent, non-destructive, so no contradiction.

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

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

Three sentences plus a bulleted list, no redundant words. The most important information (what it does, returned data, use cases, caching) is 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?

Even without output schema, description covers return types (top tools, packs, call volume), data source, PII handling, and caching. Enough for an agent to understand what the tool provides.

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

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

With 100% schema coverage, description still adds value by explaining how to choose window durations: 'shorter windows surface what's hot right now; longer windows show steady-state demand'. This goes beyond schema enum listing.

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 returns trending tools, packs, and call volume with specific verb 'returns' and resource 'top tools, top packs, total call volume'. Distinguishes from siblings like discover_tools (which is about discovery, not trends) and compare_entities (comparison, not trending).

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 three explicit use cases: discovering hot data sources, confirming canonical choice, and checking alignment. Also explains caching behavior and window choice semantics. No explicit exclusions but the use cases are specific enough to guide selection.

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

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

The description reveals behavioral traits beyond annotations: it walks child markets, extracts dates/thresholds, sorts, and reports violations. It aligns with readOnlyHint and 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 informative and well-structured, starting with purpose, then logic, usage, and output. It is slightly verbose but each sentence contributes to understanding, earning a solid 4.

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

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

Given the simplicity (one parameter, no output schema) and clear annotations, the description fully covers what the tool does, how to use it, and what it returns, making it complete for an AI agent.

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

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

With 100% schema coverage, the schema already describes the 'event' parameter well. The description adds 'Pass a Polymarket event slug or URL' which is redundant with the schema's description, so value added is minimal.

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 'find' and the resource 'arbitrage opportunities within a Polymarket event' with the specific method of checking monotonicity violations. It distinguishes itself from siblings by focusing on a distinct use case.

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

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

The description provides context on when to use the tool (to find arbitrage based on price ordering violations) and explains the logic. It does not explicitly state when not to use or list alternatives, but the use case is clear.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds significant behavioral context: it reveals the process (scanning, grouping by asset, fetching price history once, computing model probability via lognormal from FRED and live coinpaprika price) and the ranking methodology. No contradictions with annotations.

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

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

The description is front-loaded with purpose and structure, but is slightly verbose with methodological details. Every sentence adds value, covering purpose, method, and use case. Could be tightened slightly but remains well-organized.

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

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

Given no output schema, the description adequately describes the return value (top N ranked by edge magnitude with suggested trade direction). It covers inputs, process, and outcome fully for a tool of moderate complexity, satisfying the 'contextual completeness' requirement.

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 three parameters described. The description reinforces default values (limit 10, window 1wk, min_edge_pp 0.5) and clarifies that limit is capped at 25, which is present in schema. It adds context by explaining how parameters fit into the overall pipeline, enhancing understanding beyond raw 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 verb 'scan' and the resource 'highest-volume Polymarket markets', specifying the unique aspect of returning those where Pipeworz data disagrees with market price. It distinguishes from sibling tools like polymarket_arbitrage by focusing on edge detection from model disagreement.

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 positions the tool for the 'what should I bet on today' question, indicating its usage for discovering opportunities without manual browsing. It provides context but does not explicitly mention when not to use it or compare it to alternatives like polymarket_arbitrage.

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

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

Annotations already indicate readOnlyHint, idempotentHint, and no destructiveness. The description adds behavioral context (price differences, arb signal) and explains the calculation method (spread in percentage points), complementing the 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?

The description is detailed but efficient, front-loading the core purpose and modes. A minor improvement would be slightly tighter wording, but overall it earns its length.

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

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

Given no output schema, the description adequately explains the return value (leg-by-leg prices, spread). With zero required parameters and clear mode explanations, the tool is fully understandable without additional context.

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?

Despite 100% schema coverage, the description adds significant value by explaining how parameters interact (topic vs explicit overrides) and listing the topic values. This goes beyond the schema definitions, providing deeper semantics.

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

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

The description clearly defines the tool as a cross-venue spread calculator between Kalshi and Polymarket, explicitly stating it provides an arb signal. It distinguishes itself from sibling tools (e.g., polymarket_arbitrage) by focusing on this specific pair and explaining price differences.

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 details two modes (topic shortcuts and explicit tickers), giving clear guidance on when to use each. It implies usage for arbitrage detection, but does not explicitly state when not to use or list alternatives, though siblings are available.

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. Discloses that omitting key lists all stored memories, which is key behavioral detail. No mention of persistence or scope (session vs. cross-session), but context signals are otherwise clear.

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

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

Two sentences with no redundancy. Front-loaded with action and resource, immediately followed by usage guidance.

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 simple schema (1 optional param) and no output schema, description covers the essential behavior and usage context. Does not detail return format (e.g., list of keys vs. full memory), but is adequate for a straightforward retrieval tool.

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

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

Schema coverage is 100% for the single parameter, so baseline is 3. Description adds value by explaining the effect of omitting the key ('list all'), which goes beyond the schema's 'omit to list all keys' phrasing.

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

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

Description clearly states the verb 'Retrieve' and resource 'memory by key' with explicit alternative behavior (list all when key omitted). Distinguishes from sibling 'remember' and 'forget' which handle storage and deletion respectively.

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

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

Explicitly states when to use: 'to retrieve context you saved earlier in the session or in previous sessions.' Does not explicitly state when not to use or mention alternatives, but the sibling tools 'remember' and 'forget' provide natural 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?

With no annotations, the description carries the full burden. It explains the fan-out behavior for company type, the return structure (structured changes + count + URIs), and input formats. However, it lacks details on potential failure modes, authentication needs, or rate limits, leaving some behavioral gaps.

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, consisting of three sentences. It front-loads the purpose, then details behavior, return format, and use cases efficiently without redundant information.

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

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

Given the tool's complexity (fan-out to multiple data sources) and the absence of an output schema, the description provides adequate context. It explains input, output structure, and use cases. However, it could mention error handling or limitations for 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?

Input schema coverage is 100%, but the description adds significant value beyond the schema. It explains the since parameter format with examples (ISO and relative), clarifies that only 'company' is supported for type, and describes the value parameter options (ticker or CIK). This extra context enhances parameter understanding.

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

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

The description clearly states the tool's purpose: 'What's new about an entity since a given point in time.' It specifies the verb 'get recent changes' and the resource 'entity'. It differentiates from siblings by detailing the fan-out to multiple sources for companies, which is not present in sibling tools 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 provides use cases: 'Use for "brief me on what happened with X" or change-monitoring workflows.' This gives clear guidance on when to use the tool, though it does not mention when not to use it or alternative tools for specific 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?

Discloses behavioral traits: authenticated users get persistent memory, anonymous sessions last 24 hours. No annotations provided, so description carries full burden and does well. Does not mention if values are overwritten or if there are size limits.

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

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

Three sentences: first states core purpose, second gives usage guidance with examples, third adds behavioral context. Every sentence adds value, no fluff.

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

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

Given simplicity (2 params, no output schema), description is nearly complete. Only missing detail is behavior on overwrite or size limits, but these are minor. Good for a straightforward key-value store.

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 schema already documents both parameters. Description adds example values for key and notes that value is any text, but does not add significant meaning beyond schema. 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 stores a key-value pair in session memory, specifies the verb 'store' and resource 'key-value pair', and distinguishes from siblings like 'recall' and 'forget' which handle retrieval and deletion.

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

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

Describes when to use ('save intermediate findings, user preferences, or context across tool calls') and implies when not to (for retrieval use 'recall', for deletion use 'forget'). However, no explicit exclusion or alternative naming.

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 burden of behavioral disclosure. It explains the tool returns ticker, CIK, company name, and pipeworx:// URIs, and that it operates in a single call. However, it omits details on error conditions, authentication needs, or rate limits.

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

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

The description is concise, with two sentences that front-load the primary purpose and benefit. Every sentence adds information: first sentence states what it does and its efficiency, second sentence details v1, inputs, and outputs.

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 parameters, no output schema), the description is complete. It explains the input types, output fields, and the efficiency gain over alternative lookup calls.

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 beyond the schema by providing concrete examples (e.g., 'AAPL', '0000320193', 'Apple') and clarifying the input format for each entity type.

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 entities to canonical IDs across Pipeworx data sources in a single call. It specifies the verb ('resolve') and resource ('entity to canonical IDs'), and distinguishes itself by noting it replaces 2-3 lookup calls.

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

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

The description implies usage when needing to resolve an entity to canonical IDs and explicitly states it replaces multiple lookup calls. It also notes v1 only supports type='company', providing clear context, though it does not explicitly mention when not to use or list alternatives.

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

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

Annotations already indicate read-only, idempotent, non-destructive. Description adds that it probes with ai_visibility_check, ranks, and returns a ranked list with score/confidence/signal density, exceeding the structured info.

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 action, second elaborates with use case and output. No wasted words, front-loaded with purpose.

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

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

No output schema but description summarizes return format well. Siblings like 'ai_visibility_check' are referenced. Could mention edge cases but overall complete for a comparison tool.

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

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

Schema coverage 100%, so baseline 3. Description adds that first entity is treated as 'subject' and context disambiguates names, providing value beyond schema.

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

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

Description uses specific verbs (compare, probes, ranks, surfaces) and clearly states the resource (AI visibility across entities). It distinguishes itself from sibling 'ai_visibility_check' by emphasizing side-by-side comparison.

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

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

Explicitly states use case ('competitive AI-marketing audits') with an example question. Does not explicitly exclude single-entity checks but context implies the tool is for multiple entities.

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?

In the absence of annotations, the description discloses the scope, sources, verdict types, and that it returns structured data with citations. It does not mention potential limitations like rate limits or authentication, but overall it provides good 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 concise (two sentences) and front-loaded with the core purpose. It efficiently conveys all necessary information without extraneous detail.

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 and lack of output schema, the description sufficiently explains functionality and return values. It could mention the exact structure of the output but is still complete enough 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?

With 100% schema description coverage and only one parameter, the description adds value by providing examples of acceptable claims. This goes beyond the simple schema description.

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

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

The description clearly states the tool's purpose: fact-checking natural-language claims against authoritative sources, specifically for company-financial claims. It distinguishes itself from siblings by its niche in financial claim verification and emphasizes it replaces multiple agent calls.

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

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

The description specifies support for company-financial claims (revenue, net income, cash) and public US companies via SEC EDGAR+XBRL, giving clear usage context. It does not explicitly state when not to use it, but the scope is well defined.

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