radio

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

The description discloses key behavioral traits beyond annotations: it explains the default model (free Workers AI Llama-3.3-70b), that using Anthropic requires a personal API key and direct payment, and the return format (per-model {score, confidence, signals, raw_response} + combined view). Annotations already indicate read-only, open-world, idempotent, non-destructive, and the description adds value 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 three sentences, each serving a purpose: first sentence states purpose and default, second explains optional API key, third describes output and use cases. It is front-loaded with the core function, avoids fluff, and all information is 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?

Given no output schema, the description adequately explains the return structure (per-model fields and combined view). It covers all parameters (entity, models, apiKey, context) with their roles and defaults. For a probing tool with moderate complexity, the description provides sufficient context 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?

Schema coverage is 100%, so baseline is 3. The description adds meaningful context: it clarifies the default model for the 'models' parameter, the purpose of '_apiKey' (BYO key for Anthropic, paid directly), and gives example values for 'entity' and 'context'. This extra information helps the agent understand parameter semantics beyond 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 uses specific verbs ('probe', 'score') and resources ('LLMs', 'visibility'), clearly stating the tool's function: probing one or more LLMs for knowledge about an entity and returning a visibility score (0-100). It distinguishes from sibling tools by focusing on multi-model probing and scoring, and explicitly mentions use cases like AI-marketing audits and competitive monitoring.

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 usage guidance: when to use (probing LLM knowledge about a brand/product/topic), default model (free workers-ai), and how to use with additional models (Anthropic requires BYO API key). It gives examples of entity values. While it doesn't explicitly state when NOT to use or list alternatives, the context is sufficient for typical use.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the tool's behavior: 'Pipeworx picks the right tool, fills the arguments, and returns the result,' which adds context about automation and result delivery. However, it lacks details on error handling, response format, rate limits, or authentication needs, leaving gaps in behavioral understanding for an agent.

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

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

The description is front-loaded with the core functionality in the first sentence, followed by explanatory details and examples. Every sentence earns its place by clarifying usage, differentiating from alternatives, and providing concrete examples. It is appropriately sized, avoiding unnecessary verbosity while being informative.

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 (natural language querying with automated tool selection), the description is mostly complete. It explains the purpose, usage, and behavior adequately. However, without an output schema, it does not detail the return values or potential error responses, which could be helpful for an agent. The lack of annotations also means some behavioral aspects are underspecified.

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 description coverage is 100%, with the 'question' parameter well-documented in the schema. The description adds value by emphasizing 'plain English' and 'natural language,' clarifying the expected input style beyond the schema's technical description. It also provides examples that illustrate parameter usage, enhancing semantic understanding without redundancy.

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: 'Ask a question in plain English and get an answer from the best available data source.' It specifies the verb ('ask'), resource ('data source'), and distinguishes itself from sibling tools by emphasizing natural language processing rather than browsing specific tools or schemas. The examples further clarify the scope and differentiate it from tools like 'search_stations' or 'list_countries'.

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

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

The description explicitly states when to use this tool: 'No need to browse tools or learn schemas — just describe what you need.' It contrasts with alternatives by implying that other tools might require browsing or schema knowledge, and provides clear examples of appropriate use cases like factual queries or data lookups, guiding users away from using it for unrelated tasks like station searches or country listings.

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

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

Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds significant behavioral context: it resolves markets, classifies bets, fans out to appropriate data packs, and returns an evidence packet with a market-vs-model comparison. 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 a single paragraph but not overly verbose; every sentence contributes meaningful information. It front-loads the key action and purpose. Could be slightly more structured, but is efficient overall.

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 provides a reasonable overview of the return (evidence packet + market-vs-model comparison). It covers input formats, classification, and fan-out behavior. Lacks explicit detail on output structure, but openWorldHint justifies some variability.

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 is 3. The description adds modest value: it clarifies that the 'market' parameter accepts slug, URL, or question text, and implicitly mentions 'depth' via 'quick = 2-3 evidence sources, thorough = full fan-out' but doesn't add meaning beyond the schema's own 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 researches a Polymarket bet by pulling Pipeworx data, specifying the action ('research') and resource ('bet' via slug, URL, or question text). It distinguishes itself from sibling tools by claiming it is the core demo product that converts better than having agents discover packs themselves.

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

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

The description explicitly lists use cases: 'should I bet on X?', 'what does the data say about this Polymarket market?', 'is there edge in this bet?'. It does not explicitly mention when not to use it or compare to specific siblings, but the guidance is clear enough for the intended 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?

No annotations provided, so description carries full burden. It discloses data sources (SEC EDGAR, FDA) and output includes paired data and URIs. However, it does not mention error handling, rate limits, or what happens if an entity is not found, which is a moderate gap.

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

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

Three sentences, front-loaded with the main purpose, no wasted words. Efficient and easy to parse.

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 and two parameters, the description covers input semantics and output highlights (paired data, URIs). It could be more detailed on output structure but is sufficient for agent 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%, baseline 3. Description adds value by explaining 'type' parameter behavior and giving concrete examples for 'values' (tickers/CIKs for company, names for drug), which goes beyond the schema description.

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

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

The description clearly states the tool compares 2–5 entities side by side, specifying two types (company and drug) with distinct data fields. It distinguishes itself from sibling tools like resolve_entity (single entity) and search_stations (different domain).

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

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

The description implies when to use: when comparing multiple entities in one call, and notes it replaces 8–15 sequential calls. However, it does not explicitly state when not to use or list alternatives, but the context is clear enough.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the search functionality and return format (tools with names and descriptions), but doesn't mention performance characteristics, error conditions, or authentication requirements. The description adds some context about when to use it, but lacks details on rate limits, pagination, or what happens with no matches.

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 perfectly concise with two sentences that each earn their place. The first sentence explains what the tool does, and the second provides crucial usage guidance. There's zero waste or redundancy, and the most important information (when to use it) is appropriately front-loaded.

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

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

Given the tool's moderate complexity (search functionality with 2 parameters) and 100% schema coverage, the description is reasonably complete. It explains the purpose and provides excellent usage guidance. However, with no output schema and no annotations, it could benefit from mentioning what the return structure looks like or any limitations of the search algorithm.

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 both parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. It mentions the general purpose ('search by describing what you need') but provides no additional syntax, format, or constraint details for the parameters.

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

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

The description clearly states the tool's purpose with specific verbs ('search', 'returns') and resources ('Pipeworx tool catalog', 'most relevant tools with names and descriptions'). It distinguishes from sibling tools by focusing on tool discovery rather than listing specific entities like stations, countries, or tags.

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

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

The description provides explicit usage guidance: 'Call this FIRST when you have 500+ tools available and need to find the right ones for your task.' This gives clear conditions for when to use this tool versus alternatives, including the threshold (500+ tools) and the specific scenario (finding the right tools for a task).

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 must disclose behavior. It explains the tool is a read-only aggregation returning citation URIs and specific data types. It does not mention auth or rate limits, but the safety profile is clear: no destructive actions, and the output format is partially described.

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

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

The description is a single focused paragraph that front-loads the main purpose. It lists data types concisely and includes actionable guidance. A slight improvement could be bullet points, but it is 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 adequately explains what is returned (specific data types and citation URIs). It covers key use cases and limitations (only company type, name resolution requirement). No pagination or formatting details, but sufficient for an agent to select the tool.

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

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

Schema coverage is 100% (2 parameters described in schema). The description adds critical context: type is limited to 'company', value is ticker or CIK and not a name, and provides examples. This exceeds the baseline 3.

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

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

The description clearly states the tool returns a full entity profile across relevant Pipeworx packs, listing specific data types for companies (SEC filings, revenue, patents, news, LEI) and notes it replaces 10-15 sequential calls. It distinguishes from alternatives like usa_recipient_profile for federal contracts.

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

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

The description provides explicit guidance: use when a comprehensive profile is needed, avoid for federal contracts (pointing to usa_recipient_profile), and use resolve_entity if only a name is given. However, it does not compare to other siblings like compare_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?

With no annotations, the description carries full burden but only states the action ('Delete') without disclosing behavioral traits like whether deletion is permanent, requires specific permissions, or has side effects. It adds minimal context beyond the basic operation.

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

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

The description is a single, efficient sentence with zero waste. It is front-loaded and appropriately sized for a simple tool, making it easy to parse quickly.

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 deletion tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral implications (e.g., permanence, error handling) and doesn't compensate for the absence of structured data, leaving gaps in understanding.

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 parameter ('key'). The description adds no additional meaning beyond what the schema provides, such as format examples or constraints, meeting the baseline for high coverage.

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

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

The description clearly states the verb ('Delete') and resource ('a stored memory by key'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'recall' or 'remember', but the action is distinct enough to infer separation.

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 guidance is provided on when to use this tool versus alternatives. The description lacks context about prerequisites (e.g., needing an existing memory key) or exclusions, leaving the agent to infer usage from the action alone.

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?

Describes the process (fetch, extract, emit) and output format. Annotations already indicate read-only, idempotent, non-destructive; the description adds valuable context beyond annotations.

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

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

Efficient single paragraph with clear purpose, process, and use cases. No redundant or unnecessary sentences.

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

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

Given the tool's simplicity and complete schema coverage, the description fully explains what the tool does, how it works, and what it produces.

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

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

Schema coverage is 100%, so baseline is 3. The description does not add additional semantics beyond what the schema already provides for the parameters.

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

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

The description clearly states the tool generates an llms.txt file for any URL, specifying the action and resource. It distinguishes itself from siblings, none of which perform similar generation.

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 (e.g., getting client site indexed, drafting own project, auditing competitors) but lacks explicit when-not-to-use or alternatives. Context is clear.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool retrieves data ('Get') but doesn't specify if it's read-only, requires authentication, has rate limits, or describes the return format (e.g., list structure, pagination). For a tool with no annotation coverage, this leaves significant behavioral traits unexplained.

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, efficient sentence that front-loads the core purpose and includes the optional filter. There is no wasted language, and every part earns its place by conveying essential information without redundancy.

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

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

Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose and optional filtering, but without annotations or output schema, it lacks details on behavioral traits (e.g., safety, response format) that would help an agent use it correctly. This meets minimum viability with clear gaps.

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

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

The schema description coverage is 100%, so the input schema already fully documents the parameters ('count' and 'country'). The description adds minimal value beyond the schema by hinting at the optional country filter, but it doesn't provide additional semantics like format examples beyond 'Germany' or clarify how popularity is calculated. Baseline 3 is appropriate as the schema does the heavy lifting.

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: 'Get the most popular radio stations by vote count' specifies the action (get) and resource (radio stations) with a popularity metric (vote count). It distinguishes from siblings like 'search_stations' by focusing on popularity ranking rather than general search. However, it doesn't explicitly contrast with 'list_countries' or 'list_tags', keeping it from a perfect score.

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 implied usage through the optional country filter ('optionally filtered by country'), suggesting it can be used for global or country-specific queries. It doesn't explicitly state when to use this tool versus alternatives like 'search_stations' for non-popularity-based searches, nor does it mention prerequisites or exclusions, leaving some guidance gaps.

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 of behavioral disclosure. It mentions that the tool lists countries with station counts, but it doesn't describe key behavioral traits such as whether the list is paginated, sorted, or limited in scope, or if there are any rate limits or authentication requirements. This is a significant gap for a tool with zero annotation coverage.

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, efficient sentence: 'List countries that have radio stations, with station counts.' It is front-loaded with the core purpose and includes no unnecessary words, 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?

Given the tool's complexity (simple listing with no parameters) and the lack of annotations and output schema, the description is minimally adequate. It states what the tool does but misses details like output format, pagination, or error handling. With no output schema, the description should ideally explain return values more fully, but it provides a basic overview.

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 0 parameters with 100% coverage, meaning no parameters are documented in the schema. The description adds value by implying the output includes station counts, which is useful semantic information beyond the empty schema. However, it doesn't detail any optional parameters or filtering options, so it's not a perfect score.

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: 'List countries that have radio stations, with station counts.' It specifies the verb ('list'), resource ('countries'), and includes the additional detail of providing station counts. However, it doesn't explicitly differentiate from sibling tools like 'search_stations' or 'list_tags,' which prevents a perfect score.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'search_stations' (which might filter stations) or 'list_tags' (which might list tags instead of countries), nor does it specify any context or exclusions for usage. This leaves the agent without clear direction on tool 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes a read-only listing operation, which is clear, but lacks details on permissions, rate limits, pagination, or error handling. For a tool with zero annotation coverage, this is a significant gap in transparency.

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, efficient sentence that front-loads the core purpose without unnecessary words. It's appropriately sized for a simple listing tool and earns its place by clearly stating what the tool does.

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 low complexity (one optional parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks guidance on usage versus siblings and behavioral details like output format or error cases, which would be helpful 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?

The input schema has 100% description coverage, with the 'limit' parameter fully documented in the schema. The description doesn't add any parameter-specific details beyond what the schema provides, such as format constraints or examples. Baseline 3 is appropriate when the schema does the heavy lifting.

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: 'List the most common radio station genres and tags by station count.' It specifies the verb ('List'), resource ('radio station genres and tags'), and scope ('by station count'). However, it doesn't explicitly differentiate from sibling tools like 'get_top_stations' or 'search_stations', which might also involve station data.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_top_stations' (which might list stations directly) or 'search_stations' (which might filter stations), leaving the agent to infer usage based on tool names alone.

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 rate limit (5 per day per identifier) and constraint on content. Additional details like whether feedback is anonymous would be helpful, but current info is sufficient.

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 concise, front-loaded sentences. No redundancy. Each sentence adds distinct information: purpose, use cases, content guidance, rate limit.

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 and low complexity (3 params), description covers all necessary aspects for an agent to use correctly. Includes parameter guidance, usage rules, and 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?

Schema coverage is 100% but description adds value beyond schema: clarifies usage for each enum value, recommends message length and specificity. Nested context object described but could benefit from more 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 explicitly states 'Send feedback to the Pipeworx team' and lists specific use cases (bug reports, feature requests, missing data, praise). It clearly distinguishes from sibling tools which are data-oriented.

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

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

Provides explicit when-to-use including types of feedback. Also warns not to include user's prompt verbatim and mentions rate limit. Lacks explicit alternatives, but sibling context makes it obvious this is the only feedback tool.

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

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

Annotations already indicate safe, idempotent read access. The description adds valuable context: caching behavior (5min-1h), data source (CF analytics-engine), privacy (no PII), and window trade-offs, going well beyond the 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 well-structured with front-loaded purpose and bulleted use cases. It is slightly verbose but every sentence adds value, and the structure aids readability.

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

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

For a simple read-only tool with one parameter and no output schema, the description fully covers purpose, usage, behavioral traits, and parameter details, leaving no gaps.

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

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

The schema covers the only parameter (window) with enum and description. The description mostly repeats the schema's guidance on window selection, adding minimal new semantic value.

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

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

The description clearly states the tool returns trending tools, packs, and call volumes, distinguishing it from sibling tools like discover_tools or entity_profile by focusing on aggregate usage signals.

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

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

Three explicit use cases are listed, providing clear context for when to use the tool. However, no exclusions or alternatives are mentioned, though the sibling list provides implicit 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?

The description goes significantly beyond annotations by explaining the internal logic (monotonicity checks), the difference between modes, and the output format (ranked opportunities with reasoning). It does not contradict any 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 well-structured paragraph that front-loads the core purpose and then explains modes. Every sentence is informative and necessary, with 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's complexity (two modes, no output schema), the description fully explains what it does, how to use it, and what to expect as output. It is complete for an AI agent to decide and invoke correctly.

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

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

Despite 100% schema coverage, the description adds value by explaining that parameters are mutually exclusive, providing example values, and clarifying they correspond to distinct modes. This adds meaningful context beyond the schema.

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

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

The description clearly states the tool finds arbitrage opportunities by checking monotonicity violations on Polymarket. It gives a specific verb, resource, and method, and distinguishes between two modes, setting it apart from siblings like polymarket_edges.

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

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

The description explicitly details two modes ('event' and 'topic') with examples and explains when to use each, including why cross-event mode is necessary for cases where single-event mode fails. This provides clear guidance for tool selection.

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

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

Annotations already provide readOnlyHint=true, openWorldHint=true, destructiveHint=false. The description adds valuable context: it uses external data (FRED, coinpaprika), computes model probability, ranks by edge, and returns top N with suggested direction. 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, front-loaded with the core purpose and algorithm. Every sentence adds value; no wasted words. It is well-structured and easy to parse.

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, the description explains the return format ('top N ranked by edge magnitude with suggested trade direction'). It covers input, algorithm, and output comprehensively for a read-only discovery tool with supportive annotations.

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 each parameter has a clear description. The description adds minimal extra meaning beyond the schema (e.g., 'after ranking' for limit). 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 scans high-volume Polymarket markets, computes disagreement with Pipeworx data using a specific model, and returns top edges with trade direction. It distinguishes from siblings like polymarket_arbitrage and bet_research by focusing on opportunity discovery.

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

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

The description explicitly states it answers the 'what should I bet on today' question, helping users discover opportunities without manual browsing. It implicitly differentiates from other tools like bet_research (specific market analysis) and polymarket_arbitrage (arbitrage), but lacks explicit when-not-to-use guidance.

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

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

Annotations already mark it read-only, idempotent. Description adds beyond by detailing output format (leg-by-leg prices, spread in percentage points) and modes. 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?

Description is relatively concise given the complexity of modes and output. It front-loads purpose, then details modes, then output. No unnecessary words; each sentence adds value.

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

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

No output schema, so description covers return values adequately (prices and spread). Explains both modes and parameter interactions. Missing edge case handling, but overall complete for typical 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% (all params have descriptions). Description adds meaning: explains topic is pre-mapped shortcuts, explicit params override topic, provides examples. Exceeds baseline of 3 by clarifying inter-parameter relationships.

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 computes cross-venue spread between Kalshi and Polymarket for the same event. It distinguishes itself from siblings like polymarket_arbitrage by focusing on cross-venue comparison. Specific verb 'cross-venue spread' and resource named.

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?

Explains two usage modes (topic shortcuts or explicit tickers) and gives examples. Implies use for arbitrage signal detection. Lacks explicit when-not-to-use guidance but provides sufficient context for appropriate invocation.

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

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

No annotations are provided, so the description carries the full burden. It discloses that memories can be retrieved from current or previous sessions, which is useful behavioral context. However, it doesn't mention potential limitations like memory persistence, retrieval failures, or performance characteristics. The description doesn't contradict any annotations (none exist).

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

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

Two concise sentences with zero waste. The first sentence states the purpose and parameter behavior, the second provides usage context. Every word earns its place, and the information is front-loaded appropriately.

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 1 parameter with full schema coverage and no output schema, the description adequately covers the tool's purpose and basic usage. However, as a data retrieval tool with no annotations, it could benefit from more behavioral context about what 'memories' contain, format of returned data, or error conditions. It's minimally complete but has room for improvement.

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 key parameter. The description adds value by explaining the semantic behavior: 'omit to list all keys' clarifies what happens when the parameter is omitted. With 1 parameter and high schema coverage, this earns above the baseline 3.

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

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

The description clearly states the tool's purpose: 'Retrieve a previously stored memory by key, or list all stored memories (omit key).' It specifies the verb ('retrieve'/'list') and resource ('memory'), but doesn't explicitly differentiate from sibling tools like 'remember' or 'forget' beyond mentioning retrieval vs. saving context.

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: 'Use this to retrieve context you saved earlier in the session or in previous sessions.' It also explains the key parameter behavior ('omit key' to list all). However, it doesn't explicitly state when NOT to use it or mention alternatives among siblings.

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

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

Discloses parallel fan-out, supported date formats, and return structure (structured changes, total_changes count, pipeworx:// URIs). With no annotations, this is transparent; could add error handling or limits.

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

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

Two sentences, front-loaded with purpose, each sentence adds value. Extremely efficient 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?

Covers key aspects: entity type, date formats, parallel sources, return fields. No output schema, so return description is helpful. Could mention pagination or sorting but adequate for most uses.

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

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

Schema covers all parameters with descriptions; the description adds usage examples ('use "30d" or "1m" for typical monitoring') and clarifies format (ISO date or relative). Enriches beyond schema.

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

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

Description clearly states 'what's new about an entity since a given point in time' with specific sources (SEC EDGAR, GDELT, USPTO). Distinguishes from sibling tools like 'entity_profile' by focusing on changes and time windows.

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

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

Explicitly says 'Use for "brief me on what happened with X" or change-monitoring workflows.' Provides clear use cases, though doesn't explicitly mention when not to use it or alternatives.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly describes the tool's behavior as a storage operation, specifies persistence rules (authenticated vs. anonymous sessions), and implies it's a write operation. However, it doesn't mention potential limitations like storage size, rate limits, or error conditions, leaving some behavioral aspects uncovered.

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 appropriately sized and front-loaded, with the first sentence stating the core purpose and the second adding crucial context about persistence. Every sentence earns its place by providing essential information without redundancy or fluff, making it highly efficient and easy to parse.

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 moderate complexity (a write operation with persistence rules), no annotations, and no output schema, the description does well by covering purpose, usage, and key behavioral traits. However, it lacks details on return values (e.g., confirmation message or error handling) and doesn't fully address all potential edge cases, leaving minor gaps in completeness.

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

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

Schema description coverage is 100%, so the schema already documents both parameters ('key' and 'value') with good descriptions. The description adds minimal value beyond the schema by implying the parameters are used for storage but doesn't provide additional syntax, format, or usage details. This meets the baseline of 3 when the schema does the heavy lifting.

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 specific action ('Store a key-value pair') and resource ('in your session memory'), distinguishing it from sibling tools like 'recall' (likely for retrieval) and 'forget' (likely for deletion). It provides concrete examples of what can be stored ('intermediate findings, user preferences, or context across tool calls'), making the purpose unambiguous and differentiated.

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

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

The description explicitly states when to use this tool ('to save intermediate findings, user preferences, or context across tool calls') and provides clear context about persistence differences ('Authenticated users get persistent memory; anonymous sessions last 24 hours'), which helps the agent decide when to use it versus alternatives like 'recall' for retrieval. It effectively guides usage without being misleading.

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 input formats and output fields (ticker, CIK, company name, pipeworx:// URIs), and highlights it's a single call. It doesn't mention authentication requirements or error handling, but for a read-only lookup, the disclosure is reasonably transparent and sufficient.

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, consisting of two short sentences plus a third line with examples. It front-loads the purpose and immediately gives actionable details. Every sentence adds value, and there is no unnecessary verbosity.

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 low complexity (2 required parameters, simple return structure) and absence of an output schema, the description adequately covers the purpose, input formats, and output fields. It doesn't need to explain pagination or error handling as it's a straightforward lookup. The description is complete for the tool's scope.

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

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

The input schema already describes both parameters with 100% coverage. The description adds value by providing concrete examples (e.g., 'AAPL', '0000320193', 'Apple') and clarifying that v1 only supports 'company', which goes beyond the schema's enum description. This helps the agent understand acceptable formats.

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. It specifies the verb 'resolve' and the resource 'entity to canonical IDs', and distinguishes itself by claiming it replaces 2-3 lookup calls, which differentiates it from potential sibling tools that might do similar lookups individually.

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

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

The description provides clear guidance on when to use the tool by giving examples of accepted input types (ticker, CIK, name) and specifying it's for v1 type='company'. It also implies efficiency advantages over multiple lookups. However, it doesn't explicitly state when not to use it or provide alternatives, though no direct sibling seems to serve the same purpose.

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

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

Annotations declare readOnlyHint, idempotentHint, openWorldHint, destructiveHint=false. Description adds that it probes with ai_visibility_check internally and returns ranked list with score, confidence, signal density, which is consistent and adds useful context beyond annotations.

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

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

Four sentences, front-loaded with key action and purpose. Some extra wording could be trimmed, but overall efficient 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?

No output schema, but description lists return fields (score, confidence, signal density). Lacks details on error handling or pagination, but covers the main outputs adequately 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 is 100%, baseline 3. Description adds meaning by explaining entities treat first entry as subject, ranks by score, and clarifies model/_apiKey usage, going beyond 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 it compares AI visibility across multiple entities side-by-side, using specific verbs like 'compare', 'probes', 'ranks', 'surfaces'. It distinguishes itself from siblings like ai_visibility_check (single entity) and compare_entities by focusing on competitive audits.

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: 'for competitive AI-marketing audits' and gives an example question. Does not explicitly list when not to use or alternatives, but the context and sibling names imply the distinction.

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 of behavioral disclosure. It adds useful context beyond the input schema: it specifies that 'Results are ordered by votes (popularity),' which informs the agent about sorting behavior. However, it lacks details on other behavioral traits such as rate limits, authentication needs, error handling, or what the output looks like (e.g., format, pagination). For a search tool with no annotations, this is a moderate but incomplete disclosure.

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 appropriately sized and front-loaded: it's two concise sentences that directly state the purpose and key behavioral trait (ordering by votes). Every sentence earns its place by providing essential information without redundancy or fluff, making it efficient and easy to parse for an AI agent.

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 moderate complexity (a search function with 2 parameters), no annotations, and no output schema, the description is partially complete. It covers the purpose and sorting behavior but misses details like output format, error cases, or usage context relative to siblings. Without annotations or output schema, more information would be helpful for the agent to fully understand the tool's behavior and integration.

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 description coverage is 100%, meaning the input schema fully documents both parameters ('query' and 'limit') with descriptions. The description adds no additional meaning beyond the schema; it doesn't explain parameter interactions, constraints, or usage examples. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.

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: 'Search for radio stations by name.' It specifies the verb ('search') and resource ('radio stations'), and distinguishes it from siblings like 'get_top_stations' (which likely returns top stations without search) and 'list_countries'/'list_tags' (which list metadata). However, it doesn't explicitly differentiate from potential siblings like 'search_stations_by_genre' or 'search_stations_by_country', so it's not fully specific to all alternatives.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose 'search_stations' over 'get_top_stations' (e.g., for popularity-based results vs. search-based), 'list_countries' (e.g., for filtering by country), or 'list_tags' (e.g., for genre-based searches). There's only an implied usage based on the purpose, with no explicit context or exclusions.

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

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

No annotations provided, so description carries burden. It discloses return values (verdict types, citation, delta) and mentions it replaces sequential calls. However, it does not disclose limitations (e.g., only US public companies, only certain metrics) or error cases, leaving gaps for an agent.

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 purpose, no wasted words. Efficient and to the point.

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

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

Given no output schema, the description explains return values well. For a single-parameter tool, it is fairly complete, but lacks mention of error handling, authentication, or scope limitations beyond 'company-financial claims'. Almost complete.

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

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

Schema coverage is 100% (one param with description). The description adds examples and explains output structure, but the schema already documents the parameter adequately. Baseline 3 is appropriate as description reinforces but does not significantly extend meaning.

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

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

Description clearly states it fact-checks natural-language claims against authoritative sources, with specific domain (company-financial) and sources (SEC EDGAR+XBRL). However, it does not differentiate from sibling tools explicitly; no sibling seems to overlap directly, so clarity is high but missing explicit distinction.

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 company-financial claims (v1 support), but no explicit when-to-use, when-not-to-use, or alternatives. Mentions it replaces 4-6 sequential agent calls, which hints at efficiency but not clear exclusion criteria.

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