pokemon

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

Annotations already indicate readOnly, openWorld, idempotent, non-destructive. Description adds that the default model is free and accounts for Anthropic if API key is provided, and that results include per-model and combined view. This aligns with annotations and provides extra context on cost implications.

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 well-structured sentences. First sentence states main action and output. Second covers default and BYO key. Third lists use cases. Every sentence is meaningful; no wasted words.

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

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

Despite no output schema, description clearly states return format: 'per-model {score, confidence, signals, raw_response} + a combined view'. Covers the 4 parameters sufficiently. Could mention pagination or rate limits but not necessary for this 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%, but description adds value by explaining the default model condition for _apiKey (only needed if 'anthropic' in models) and that 'context' helps disambiguate. This goes beyond the schema descriptions.

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

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

Description starts with a specific verb 'Probe' and clear resource 'LLMs for what they know about a business/brand/product/topic' and states the output 'score visibility (0-100) per model'. This distinguishes it from siblings like 'scan_competitor_ai_presence' which likely focuses on competitive monitoring; the purpose is unique and well-defined.

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'. Also provides context on default model vs BYO key for Anthropic, which guides when to use each option. Lacks explicit 'when not to use', but the stated use cases are sufficient.

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 effectively describes key behaviors: the tool picks the right data source, fills arguments automatically, and returns results. However, it lacks details on limitations such as rate limits, error handling, or authentication needs, which would be helpful for a tool with such broad functionality.

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, starting with the core functionality and following with benefits and examples. Every sentence earns its place by explaining the tool's value proposition and usage without redundancy, making it efficient and easy to understand.

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 processing to select data sources) and lack of annotations or output schema, the description is mostly complete. It covers purpose, usage, and behavioral traits well, but could benefit from mentioning potential limitations or the types of data sources available to set clearer expectations.

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 schema already documents the single parameter 'question' as a natural language string. The description adds value by emphasizing the plain English aspect and providing examples like 'Look up adverse events for ozempic', which clarifies the expected format and scope beyond the schema's basic 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: 'Ask a question in plain English and get an answer from the best available data source.' It specifies the verb ('ask') and resource ('answer from data source'), and distinguishes itself from siblings by emphasizing natural language interaction without needing to browse tools or learn schemas. The examples further clarify its unique role.

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: for asking questions in plain English to get answers from data sources, without needing to browse tools or learn schemas. It provides clear alternatives by implication (e.g., not using other tools that require schema knowledge) and includes practical examples like 'What is the US trade deficit with China?' to illustrate appropriate use cases.

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 provides extensive behavioral details beyond the annotations: it resolves the market, classifies the bet type, fans out to appropriate data packs, and returns an evidence packet with model comparison. This significantly enhances transparency, and no contradictions with annotations are present.

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 slightly lengthy but well-structured, starting with the core purpose, then explaining the process, and finally providing usage examples. Every sentence adds useful context, though some redundancy exists with the schema descriptions.

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 lack of an output schema, the description compensates by detailing the return format (evidence packet plus market-vs-model comparison). It covers the tool's purpose, parameters, usage scenarios, and behavior, making it fully complete for this complexity level.

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

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

The schema already covers 100% of parameters with descriptions, including depth enum values and market input formats. The description adds value by explaining the market resolution process and providing examples, which goes beyond the schema's definitions.

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

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

The description clearly states the tool researches a Polymarket bet by pulling Pipeworx data. It specifies the verb 'research' and resource 'bet', and distinguishes from siblings by noting it's the core demo product that combines multiple data packs, unlike other tools that require manual 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 when to use the tool with phrases like 'should I bet on X?' and 'what does the data say about this Polymarket market?'. It implies it is the preferred tool for bet research, but does not explicitly exclude other tools or provide 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?

No annotations are provided, so the description carries the full burden. It discloses that the tool makes internal calls (replaces sequential calls), returns paired data with resource URIs, and specifies data fields per type. However, it does not mention potential side effects, authentication needs, rate limits, or error conditions. The description adds good behavioral context beyond the bare schema.

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

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

The description is three sentences: purpose, type-specific details, and return/efficiency. Every sentence is informative and earns its place. No unnecessary words.

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

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

Given no output schema, the description adequately explains what the tool does, its parameters, and the nature of returned data (paired data + URIs). It could mention error handling or format of URIs, but overall it is sufficient for an agent to decide to use 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% with descriptions for both parameters. The description adds significant meaning by explaining what data is compared for each type (e.g., revenue, net income for companies; adverse-event counts for drugs) and sources (SEC EDGAR). This goes beyond the schema's enum and example values.

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

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

The description clearly states that the tool compares 2–5 entities side by side, lists specific data fields per entity type (company/drug), mentions sources (SEC EDGAR), and explains the return format. It also quantifies efficiency gains over sequential calls. This provides a specific verb+resource+scope and distinguishes it from single-entity 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?

It explicitly says 'Replaces 8–15 sequential agent calls', indicating when to use this tool for batch comparison. It does not directly contrast with sibling tools like resolve_entity, but the context is clear that this is for comparative analysis across multiple entities, not single resolution.

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 the tool's search behavior and return format ('Returns the most relevant tools with names and descriptions'), but lacks details on error handling, performance characteristics, or authentication requirements that would be helpful for a discovery 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 perfectly concise with two sentences that each serve distinct purposes: the first explains what the tool does, the second provides crucial usage guidance. Every word earns its place with zero wasted text.

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 discovery tool with 2 parameters and 100% schema coverage but no output schema, the description provides good context about when to use it and what it returns. However, without annotations or output schema, it could benefit from more detail about result format or 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 description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds minimal value beyond the schema by mentioning natural language queries in the context, but doesn't provide additional syntax or format details. Baseline 3 is appropriate when 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 with specific verbs ('Search the Pipeworx tool catalog') and resources ('tool catalog'), and distinguishes it from sibling tools by emphasizing its discovery function rather than direct data retrieval like 'get_pokemon' or 'get_type'.

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

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

The description provides explicit guidance on when to use this tool ('Call this FIRST when you have 500+ tools available and need to find the right ones for your task'), including a clear condition (500+ tools) and alternative approach (using it as an initial discovery step).

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

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

Despite no annotations, the description discloses return format (pipeworx:// citation URIs) and details data sources. It doesn't mention latency, rate limits, or permissions, but given its read-only aggregation nature, the transparency is good.

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: purpose, details, usage guidance. Front-loaded and efficient. Minor redundancy in repeating 'type='company'' from schema, but overall 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 what data is included and what is excluded (federal contracts). Mentions output format. Could benefit from more detail on response structure, but sufficient for its complexity.

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

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

Schema coverage is 100%, but the description adds value beyond the schema by specifying that value must be a ticker or CIK, not names, and that type only supports 'company'. This gives agents practical usage context.

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

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

The description clearly states the tool's purpose: aggregating a full entity profile from multiple Pipeworx packs (SEC, XBRL, patents, news, LEI). It distinguishes itself from siblings like resolve_entity and compare_entities by specifying its composite nature and mentioning alternatives for specific cases.

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 instructs when to use this tool ('Replaces 10–15 sequential agent calls') and when not to ('For federal contracts call usa_recipient_profile directly'). Also advises using resolve_entity first if only a name is available, providing clear decision guidance.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. 'Delete' implies a destructive mutation, but it doesn't specify whether the deletion is permanent, reversible, requires specific permissions, or what happens on success/failure. This is a significant gap for a mutation 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 a single, efficient sentence with zero waste—it directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded for a simple tool.

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 this is a destructive mutation tool with no annotations and no output schema, the description is incomplete. It lacks critical behavioral details (e.g., permanence, error handling) and doesn't explain return values, leaving the agent with insufficient context for safe and effective use.

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

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

The schema description coverage is 100%, with the single parameter 'key' documented as 'Memory key to delete'. The description adds no additional meaning beyond this, such as key format or examples. With high schema coverage, the 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 the action ('Delete') and the resource ('a stored memory by key'), making the purpose immediately understandable. However, it doesn't distinguish this tool from its sibling 'recall' (which likely retrieves memories) or 'remember' (which likely stores memories), missing explicit sibling differentiation.

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

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

The description provides no guidance on when to use this tool versus alternatives like 'recall' or 'remember', nor does it mention prerequisites (e.g., needing an existing memory key) or exclusions. It's a bare statement of function without context.

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

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

Annotations indicate readOnly, openWorld, idempotent, non-destructive. The description adds that it fetches the page, extracts title/description/links, and outputs markdown, which aligns with and extends 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?

Two sentences plus a bullet-like list of use cases. Front-loaded with primary action. Efficient and well-structured, though slightly verbose.

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

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

For a simple two-parameter tool with no output schema, the description adequately covers behavior, output format, and use cases. Missing error handling details but acceptable for this simplicity.

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 parameter descriptions. The tool description does not add new meaning beyond what the schema already provides.

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

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

The description clearly states the tool generates an llms.txt file for a given URL, specifies the AI crawlers, and distinguishes it from unrelated sibling tools like 'ai_visibility_check' or 'scan_competitor_ai_presence'.

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

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

The description lists three explicit use cases (client site indexing, own project drafting, competitor auditing) but does not exclude scenarios. The context is sufficient given unrelated 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what information is returned but doesn't cover critical aspects like whether this is a read-only operation, error handling, rate limits, authentication needs, or data freshness. For a tool with no annotations, this leaves significant gaps in understanding its behavior.

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

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

The description is a single, efficient sentence that front-loads the key information ('Get ability details') and specifies the returned data without unnecessary words. Every part of the sentence earns its place by clarifying the tool's output.

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 required parameter, no nested objects) and high schema coverage, the description is adequate but incomplete. It lacks output schema, so it doesn't explain return values, and with no annotations, it misses behavioral context. For a simple lookup tool, it's minimally viable but could benefit from more detail on usage or errors.

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 single parameter 'ability' clearly documented as the ability name with examples. The description doesn't add any parameter-specific details beyond what the schema provides, such as format constraints or validation rules, so it meets the baseline for high schema coverage without extra value.

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

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

The description clearly states the tool's purpose with a specific verb ('Get') and resource ('ability details'), including what information is returned ('effect description and the list of Pokémon that can have this ability'). It distinguishes itself from siblings like get_pokemon and get_type by focusing on abilities, though it doesn't explicitly contrast with get_evolution_chain.

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 doesn't mention prerequisites, context for usage, or comparisons with sibling tools like get_pokemon (which might include ability info) or get_evolution_chain. Usage is implied by the name and purpose but not explicitly stated.

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 return data but does not cover critical aspects such as error handling, rate limits, authentication needs, or whether the operation is read-only or has side effects. For a tool with no annotations, this leaves significant gaps in understanding its behavior.

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

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

The description is a single, well-structured sentence that efficiently conveys the tool's purpose and output without unnecessary details. It is front-loaded with the main action and resource, making it easy to understand at a glance, with no wasted words.

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

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

Given the tool's simplicity (one parameter, no output schema, no annotations), the description is adequate but not comprehensive. It explains what the tool returns but lacks details on behavioral traits, error cases, or usage context. For a straightforward read operation, this is minimally viable but could be improved with more contextual information.

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 'id' parameter clearly documented in the schema. The description does not add any additional meaning or context beyond what the schema provides, such as examples of valid IDs or constraints. Baseline score of 3 is appropriate as the schema adequately covers parameter semantics.

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

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

The description clearly states the action ('Get the full evolution chain') and resource ('by chain ID'), specifying what information is returned ('each species in the chain with its evolution trigger, minimum level, and evolution item'). However, it does not explicitly differentiate from sibling tools like get_pokemon or get_ability, which likely retrieve different types of Pokémon 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 like get_pokemon or get_ability. It mentions what the tool does but lacks context on appropriate use cases, prerequisites, or exclusions, 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the return data but doesn't mention important behavioral aspects like error handling (e.g., what happens with invalid names/IDs), rate limits, authentication requirements, or whether this is a read-only operation. The description is purely functional without behavioral 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 perfectly concise and well-structured in a single sentence that front-loads the core functionality ('Get Pokémon details by name or ID') followed by a comprehensive but efficient list of what's returned. Every word serves a purpose with zero waste.

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

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

For a simple read operation with one parameter and no output schema, the description adequately covers the basic functionality and return data. However, given the lack of annotations and output schema, it should ideally mention that this is a read-only operation and provide more behavioral context about error conditions or 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?

The schema description coverage is 100%, with the single parameter 'name' fully documented in the schema. The description adds minimal value beyond the schema by mentioning 'by name or ID' but doesn't provide additional semantic context about parameter usage beyond what's already in the structured data.

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 a specific verb ('Get') and resource ('Pokémon details'), listing exactly what information is returned. It distinguishes from sibling tools like get_ability, get_evolution_chain, and get_type by focusing on comprehensive Pokémon details rather than specific attributes.

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. While it implicitly suggests this is for retrieving general Pokémon details, there's no explicit mention of when to choose this over sibling tools like get_ability for ability-specific queries or get_type for type information.

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 full burden for behavioral disclosure. It effectively describes key behaviors: it returns damage relations (double/half/no damage to and from) and limits results to 'the first 20 Pokémon of that type.' This provides important context about output format and result limitations that isn't available elsewhere.

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 states the core purpose, and the second sentence provides important behavioral details about what's returned and result limitations. No wasted words or 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?

For a tool with one parameter (100% schema coverage) and no output schema, the description provides good contextual completeness. It explains what information is returned (damage relations and Pokémon list) and includes the important limitation of returning only the first 20 Pokémon. The main gap is the lack of output schema, but the description compensates reasonably well.

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

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

The schema description coverage is 100%, with the single parameter 'type' already documented as 'Type name (e.g., "fire", "water", "electric").' The description doesn't add any additional parameter semantics beyond what the schema provides, so the baseline score of 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 with specific verbs ('Get type effectiveness information and Pokémon list') and resource ('for a given type'). It distinguishes from sibling tools like get_ability, get_evolution_chain, and get_pokemon by focusing specifically on type data rather than abilities, evolution chains, or individual Pokémon.

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 by specifying what the tool returns (damage relations and Pokémon list), but doesn't explicitly state when to use this tool versus alternatives. No guidance is provided about when not to use it or what other tools might be better for related 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?

No annotations provided, so description carries burden. It discloses rate limiting and content restrictions. Lacks details on whether the tool returns a confirmation or modifies any state, but it's a feedback tool so mutation is expected.

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, no unnecessary words. Each sentence serves a purpose: stating action, listing use cases, giving a usage tip, and noting 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?

Covers purpose, usage, constraints, and rate limit. Does not mention that there is no return value or expected output, but for a feedback tool that's acceptable given the schema covers parameters well.

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

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

Schema coverage is 100% and parameter descriptions in the schema are thorough. The tool description adds context about the overall purpose but not additional parameter meaning beyond the schema.

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

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

The description clearly states the verb 'Send feedback to the Pipeworx team' and lists specific use cases (bug reports, feature requests, etc.). It distinguishes itself from siblings like ask_pipeworx which are for querying 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?

Explicitly states when to use ('Use for bug reports...') and provides constraints ('do not include the end-user's prompt verbatim', rate-limited to 5 per day). No explicit when-not, but context makes it 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, openWorldHint, idempotentHint, and destructiveHint false. The description adds valuable context: the data is self-aggregating from CF analytics, no PII, and cached 5min-1h. 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 concise, with a clear opening sentence, bullet-style use cases, and technical details. Every sentence adds value 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?

Despite having no output schema, the description covers the tool's purpose, use cases, parameter guidance, aggregation source, privacy, and caching. This is thorough for a 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?

The input schema describes the only parameter (window) with enum values and a clear description. The tool description reinforces the semantic difference between windows. Since schema coverage is 100%, the baseline is 3, but the added context on usage elevates it to 4.

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

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

The description clearly states the tool returns top tools, packs, and call volumes over a recent window. It distinguishes itself from siblings like discover_tools by focusing on trending activity aggregated from other agents.

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 three use cases: discovering hot data sources, confirming canonical tools, and checking alignment. It also explains window choice. However, it does not mention when to avoid this tool or alternatives, which prevents a 5.

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

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

The description fully discloses the tool's behavior: it checks monotonicity violations, groups related markets, and returns ranked opportunities with trade direction and reasoning. This aligns with annotations (readOnlyHint, openWorldHint) and adds contextual detail beyond them, such as the two modes and search logic.

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 and front-loaded with the core purpose. It uses clear segmentation for the two modes. While slightly verbose, every sentence contributes information. A minor improvement would be to condense the mode explanation slightly, but overall it's 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?

The description lacks details about the output format since there is no output schema. It mentions 'ranked opportunities with suggested trade direction + reasoning' but does not specify the structure, fields, or interpretation of the ranking. For a complex tool with no output contract, this gap limits full agent comprehension.

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 provides detailed descriptions for 'event' and 'topic' parameters (100% coverage). The tool description adds value by explaining how parameters are used in each mode (e.g., walking child markets vs. cross-event search) and providing example inputs, which goes beyond the schema alone.

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

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

The description clearly states the tool's purpose: finding arbitrage opportunities on Polymarket via monotonicity violations. It distinguishes two operational modes ('event' and 'topic'), each with specific use cases, effectively differentiating from sibling tools like 'polymarket_edges' or 'bet_research'.

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

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

The description provides explicit guidance on when to use each mode: 'event' for a single event slug and 'topic' for cross-event related markets. It explains why cross-event mode is necessary (Polymarket's structure) and gives concrete examples, enabling the agent to select the correct mode without ambiguity.

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

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

Annotations already indicate readOnly, non-destructive. Description adds algorithmic steps (groups by asset, fetches price history once, computes model probability) and output details (top N ranked by edge). 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?

Concise paragraph front-loads purpose, then explains methodology and output. Every sentence adds value 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?

Covers algorithm, input parameters, and high-level output. Lacks specific output format (e.g., fields returned) but sufficient given annotations and no output schema.

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

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

Schema coverage is 100% with descriptions for all three parameters, including defaults. Tool description does not add significant meaning beyond schema, baseline 3 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 specifies verb 'scan' and resource 'highest-volume Polymarket markets' with outcome 'return where Pipeworx data disagrees most with market price'. It distinguishes from sibling 'polymarket_arbitrage' by focusing on model-based edge detection.

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 'Built for the "what should I bet on today" question' providing clear use case. Lacks explicit exclusions or comparison to siblings, but context is sufficient.

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 the tool as read-only, open-world, idempotent, and non-destructive. The description adds behavioral detail: the spread calculation (Kalshi - Polymarket in percentage points), the output includes leg-by-leg prices (raw probability 0-1), and the topic mapping behavior. 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 a single paragraph that is information-dense but somewhat verbose. It includes background motivation which is helpful, but could be more structured (e.g., bullet points for modes and returns). Still, it is not overly long and communicates effectively.

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 three optional parameters, no required params, and no output schema, the description adequately explains the return format (leg-by-leg prices and spreads). However, without a formal output schema, the description carries the full burden, and it does so with enough detail for an agent to interpret the result.

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

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

Schema coverage is 100% with descriptions for all three parameters. The description adds context by explaining the two modes, how explicit parameters override topic-mapped sides, and provides example values (e.g., 'KXFED-26OCT'). This adds meaning beyond the schema alone.

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

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

The description clearly states the tool's purpose: computing cross-venue spreads between Kalshi and Polymarket. It explains the rationale (price differences due to different participant pools) and distinguishes from siblings like polymarket_arbitrage. The two modes (topic and explicit) are clearly defined.

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

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

The description explains two modes: pre-mapped topic shortcuts for common events and explicit overrides for custom pairings. It provides example values. While it doesn't explicitly exclude alternative tools, the context of sibling tools (e.g., polymarket_arbitrage vs this) is implied, and the description gives clear guidance on when to use each mode.

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. It discloses key behavioral traits: the tool can retrieve individual memories by key or list all memories, works across sessions, and accesses previously stored context. However, it doesn't mention potential limitations like memory size constraints or retrieval failures.

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 the core functionality, and the second provides usage context. No wasted words, and 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 the tool's moderate complexity (retrieval with optional parameter), no annotations, and no output schema, the description does well by explaining the dual functionality and cross-session capability. However, it doesn't describe the return format (what a 'memory' looks like) or error conditions, leaving some 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 has 100% description coverage, so the baseline is 3. The description adds meaningful context: it explains the semantic difference between providing a key (retrieve specific memory) and omitting it (list all keys), which clarifies the optional parameter's behavior beyond the schema's technical documentation.

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 ('retrieve', 'list') and resources ('previously stored memory by key', 'all stored memories'). It distinguishes from siblings like 'remember' (store) and 'forget' (delete) by focusing on retrieval operations.

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

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

The description provides explicit guidance on when to use this tool: 'to retrieve context you saved earlier in the session or in previous sessions.' It also specifies when to omit the key parameter ('omit key to list all keys'), giving clear operational instructions.

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

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

No annotations are provided, so the description carries the full burden. It discloses the parallel fan-out behavior, supported parameters (type, since, value), return format (structured changes + count + URIs), and the constraint that only 'company' type is supported. It omits potential issues like rate limits or empty results, but the coverage is strong.

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

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

The description is a single, well-structured paragraph. It front-loads the core purpose, then expands with details and a clear use-case statement. Every sentence is informative 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 no output schema or annotations, the description does a good job covering tool behavior, parameters, and returns. It explains the fan-out logic and provides usage guidance. A minor gap: it does not mention any limits on result size or pagination, but overall it is sufficient for an agent to understand and invoke the tool.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the 'since' parameter's format (ISO date or relative terms) with concrete examples ('7d', '30d', '1y') and recommending '30d' or '1m' for typical monitoring. It also clarifies that 'value' accepts ticker or CIK. This goes 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 the tool's verb ('what's new') and resource ('entity'), and distinguishes it by detailing the parallel fan-out across SEC EDGAR, GDELT, and USPTO for company entities. This differentiates it from sibling tools like 'entity_profile' or 'ask_pipeworx'.

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

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

The description explicitly recommends usage for 'brief me on what happened with X' or change-monitoring workflows, providing clear context. However, it does not explicitly state when not to use or name alternatives, though the use cases are well-defined.

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 effectively describes key behavioral traits: the persistence difference between authenticated users ('persistent memory') and anonymous sessions ('last 24 hours'), and the cross-tool context capability ('across tool calls'). It doesn't mention rate limits, error conditions, or memory size limits, but covers the essential operational behavior.

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

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

The description is perfectly concise with just two sentences. The first sentence states the core purpose with examples, and the second sentence adds crucial behavioral context about persistence differences. Every word earns its place with no redundancy or filler content.

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

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

For a 2-parameter tool with no annotations and no output schema, the description provides good contextual completeness. It covers the tool's purpose, usage context, and key behavioral traits (persistence differences). The main gap is lack of information about return values or error conditions, but given the tool's relative simplicity, the description is reasonably complete.

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

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

Schema description coverage is 100%, so the schema already fully documents both parameters. The description doesn't add any parameter-specific information beyond what's in the schema descriptions. It mentions 'key-value pair' generically but doesn't provide 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 ('store a key-value pair') and resource ('in your session memory'). It distinguishes from sibling tools like 'forget' and 'recall' by focusing on storage rather than retrieval or deletion. The examples of what to store ('intermediate findings, user preferences, or context across tool calls') provide concrete use cases.

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 this tool ('to save intermediate findings, user preferences, or context across tool calls'), which helps differentiate it from siblings like 'get_pokemon' or 'discover_tools'. However, it doesn't explicitly state when NOT to use it or mention specific alternatives (e.g., when to use 'recall' instead for retrieval).

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

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

No annotations are provided, so the description must cover behavioral traits. It discloses return fields (ticker, CIK, company name, pipeworx:// URIs) and that v1 only supports company type. However, it does not state if the operation is read-only, potential side effects, authentication needs, or rate limits. The disclosure is adequate but lacks some 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 concise with two sentences. The first sentence states the purpose and benefit, and the second provides version specifics, parameter details, and return values. No unnecessary words.

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

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

Given no output schema, the description adequately lists return fields (ticker, CIK, company name, pipeworx:// URIs) and positions the tool as a replacement for multiple calls. With only two simple parameters and a clear use case, the description is complete for an agent to understand what to expect.

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

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

Schema has 100% coverage with descriptions for both parameters. The description adds value by providing examples (e.g., 'AAPL', '0000320193', 'Apple') and clarifying that v1 supports only 'company' for the type enum. This enhances understanding beyond the schema.

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

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

The description clearly states the tool resolves an entity to canonical IDs across Pipeworx data sources in a single call. It specifies the verb 'resolve', the resource 'entity', and gives a concrete example for company type with ticker, CIK, or name. It distinguishes itself from sibling tools by emphasizing it's a single-call solution replacing multiple lookups.

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

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

The description explains when to use the tool: for company entity resolution, accepting ticker, CIK, or name. It notes it replaces 2–3 lookup calls, implying efficiency. However, it does not explicitly state when not to use it or mention alternative tools for other entity types.

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

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

Annotations already declare readOnly, idempotent, and non-destructive. The description adds that it internally calls ai_visibility_check per entity and returns a ranked list with score, confidence, and signal density. This goes beyond 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 concise at five sentences, front-loading the main action and purpose. Every sentence adds value 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?

While no output schema exists, the description compensates by detailing the return format (ranked list with score, confidence, signal density). It explains the internal call to ai_visibility_check and provides a concrete example. Missing edge-case handling but sufficient 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?

Input schema has 100% coverage, so the description doesn't add much parameter-specific detail. It does note that the first entity is treated as the subject, which is marginally helpful but already implied in 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 AI visibility across multiple entities side-by-side, probes each with ai_visibility_check, ranks by score, and identifies most/least recognized. This distinguishes it from the sibling ai_visibility_check which is single-entity.

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

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

The description provides a clear use case ('competitive AI-marketing audits') and an example question, implying its utility for comparing entities. However, it lacks explicit guidance on when not to use (e.g., for a single entity, use ai_visibility_check instead).

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

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

No annotations provided, so description carries full burden. Describes return values (verdict, structured form, actual value, citation, percent delta) and sources. Indicates version v1 and supported claim types, but does not cover error handling or side effects. Sufficiently transparent for a read-only 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?

Concise, front-loaded with purpose, then scope, then output details, then value proposition. No wasted sentences or redundancy.

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

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

Given the single parameter and no output schema, the description fully explains input, output, sources, and domain. Complete for its 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?

Only one parameter 'claim' with schema description coverage at 100%. The tool description does not add additional meaning beyond the schema examples. Baseline 3 is appropriate as 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: fact-check natural-language claims against authoritative sources, specifically company-financial claims. It details the returned verdict types, structured form, actual value with citation, and percent delta. It also distinguishes itself from siblings by noting it replaces 4-6 sequential 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?

Provides specific domain and sources (company-financial claims for public US companies via SEC EDGAR + XBRL). Explicitly states it replaces sequential agent calls, implying when to use it. However, does not explicitly mention when not to use it or provide alternatives among sibling tools.

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