Catalogueoflife

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 behavioral context: the Anthropic model costs and requires a BYO key, the structure of the return value (per-model scores + combined view), and that the default model is free.

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 (4 sentences) with no filler. The most critical information (verb, resource, scoring range) is front-loaded. Every sentence adds value, from the default model to the return structure.

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

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

Despite no output schema, the description adequately describes the return format (per-model {score, confidence, signals, raw_response} plus combined view). With 4 parameters and high schema coverage, plus annotations covering safety and idempotency, the description fully equips an AI to use the tool correctly.

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

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

Schema coverage is 100% and the description adds meaningful context beyond the schema: explains the function of each parameter (entity as query subject, models as list, _apiKey as optional with cost implication, context for disambiguation) and provides concrete examples.

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

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

The description uses a specific verb ('probe') and resource ('one or more LLMs') and clearly defines the scope: scoring visibility (0-100) per model. It effectively distinguishes from siblings like scan_competitor_ai_presence or compare_entities by focusing on probing LLM knowledge directly.

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 use cases ('AI-marketing audits', 'pre-launch brand checks', 'competitive monitoring') and hints at when not to use (free default model vs paid Anthropic). However, it does not explicitly exclude any alternative tools among the 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint. Description adds that it routes to 3,436 tools and returns structured answers with citation URIs, providing behavioral context beyond annotations.

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

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

Front-loaded with preference statement, concise but includes essential examples. Single paragraph, no wasted words, though slightly dense.

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, description explains what is returned (structured answer with citation URIs). Covers usage, behavior, and examples thoroughly. Annotations and schema cover safety and parameters completely.

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

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

Schema coverage 100% with descriptions for each alias. Description only states 'your question or request in natural language', adding minimal value beyond schema's parameter 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?

Clearly states the tool answers factual questions using authoritative data with citations, and explicitly distinguishes from web search by saying 'PREFER OVER WEB SEARCH'. Provides specific examples of query types.

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 when to use (for factual queries about many topics) and prefers over web search, but doesn't explicitly state when not to use. Gives example queries and phrases that trigger its 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint true, and destructiveHint false. The description goes beyond by detailing resolver behavior (market_match_confidence levels), fan-out patterns, safety mechanisms (blocking on low-confidence or closed markets), and market status flags (illiquid_wide_spread). 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 long (over 500 words) but structured with sections (CLASSIFIERS, FAN-OUT EXAMPLES, RESPONSE SHAPES, etc.) and front-loaded with the main purpose. However, some sections are verbose and could be trimmed without losing essential information.

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

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

Given the tool's complexity (multiple classifiers, fan-out patterns, resolver, parent event, news fields, safety edge cases), the description covers return values comprehensively since there is no output schema. It explains all key result fields, edge cases, and blocking conditions, leaving little ambiguity.

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

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

Schema coverage is 100% with all parameters described. The description adds significant semantic value: explains depth options ('quick = 2-3 evidence sources, thorough = full fan-out'), include_raw purpose, and provides extensive context on how the tool processes inputs and returns data, which 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 starts with a clear verb+resource: 'Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call.' It specifies input types (slug, URL, question text) and output components (evidence packet, comparison), distinguishing it from siblings like 'polymarket_edges' which focus on edge calculations.

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

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

The description explicitly tells when to use: 'Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z".' It also implies when not to use through safety notes (low-confidence matches, closed markets) but does not name specific alternatives.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds that the tool returns only immediate children (not all descendants) and operates one rank at a time. 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 sentence with embedded example queries, making it extremely concise and front-loaded. Every word adds value, no filler.

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

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

Given the output schema exists (though not shown), the description adequately explains the tool's purpose and constraints. It covers the key behavioral aspect (immediate children) but could mention pagination or the default limit behavior more explicitly.

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 33% (only limit has a description). The description provides example JSON with 'id' and 'limit' but does not explain 'dataset' or add syntax/format details beyond the schema. The baseline of 3 is appropriate as the description adds minimal 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 specifies the verb 'list', the resource 'immediate child taxa under a Catalogue of Life parent taxon', and includes example queries like 'What species are in [genus]'. It distinguishes from sibling tools (e.g., classification, taxon) by stating it walks down the tree one rank at a time.

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

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

The description explicitly states when to use the tool: 'Use to walk down the tree of life one rank at a time.' It implies that deeper traversal requires repeated calls, and the scope is limited to direct descendants, which helps differentiate from other tools like classification or search.

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds no additional behavioral details beyond stating it works with Catalogue of Life IDs. It does not contradict annotations but also does not enhance transparency beyond what annotations convey.

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 lengthy due to multiple example queries, which adds context but also verbosity. It front-loads the main purpose but could be streamlined to essential information without losing clarity.

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

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

Given the presence of an output schema, the description adequately covers the return value (classification chain) and prerequisite (search). However, it omits any explanation of the 'dataset' parameter, which is needed for full completeness in a 2-parameter 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 documentation coverage is 0%: neither parameter has a description. The description clarifies that 'id' is a Catalogue of Life taxon ID, but does not explain the 'dataset' parameter at all. This leaves a significant gap, requiring the agent to infer or guess the role of 'dataset'.

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

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

The description explicitly states the tool returns the full taxonomic classification chain for a Catalogue of Life taxon ID, with clear examples of queries. It distinguishes from siblings like 'search' and 'taxon' by specifying its role in getting lineage after a search.

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 advises using the tool after 'search' to get lineage, providing clear context for when to use it. However, it does not explicitly state when not to use it or offer alternatives, though the sibling list implies other tools for different tasks.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds significant behavioral context: pulls latest 10-K data for companies (handles off-calendar fiscal years), pulls FAERS/FDA/trial counts for drugs, sorts results by primary metric, and returns citation URIs. 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 well-structured with trigger phrases and clear sections, but it is somewhat verbose. It front-loads purpose effectively, though some redundancy could be trimmed.

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 no output schema, the description thoroughly explains what is returned (paired data with citation URIs) and covers both entity types. It provides sufficient context for an agent to use the tool correctly.

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

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

Schema covers 100% of parameters with descriptions. The description adds examples of valid values (tickers/CIKs for companies, drug names for drugs) and reinforces constraints (2-5 items, min/max). This adds 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?

Clearly states the tool compares 2-5 companies or drugs side-by-side with specific metrics (financial data for companies, adverse events/FDA/trials for drugs). Distinguishes from sequential lookups by emphasizing parallel execution.

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

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

Explicitly advises to prefer this tool over sequential single-pack lookups when comparing entities, providing a clear when-to-use directive. No ambiguity about 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?

Description adds behavioral context beyond annotations: returns 'top-N most relevant tools with names, descriptions, and full input schemas (with curated examples)', says each result is 'ready to call directly, no second schema lookup needed'. No contradictions with annotations (readOnlyHint true, destructiveHint false).

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 three sentences, front-loaded with purpose. Efficient but could be slightly more concise. No wasted words, earns its place.

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

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

Given that there is no output schema, description fully explains return value: top-N relevant tools with names, descriptions, full schemas, examples. Covers all needed context for a discovery 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 description adds minimal value beyond schema. Lists examples and aliases but schema already describes query parameter and aliases. No additional semantic depth beyond what schema provides.

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

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

Description explicitly states 'Find tools by describing the data or task' with specific verb and resource. It clearly distinguishes from sibling tools by focusing on discovery rather than direct queries.

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 guidance: 'Use when you need to browse, search, look up, or discover what tools exist for' and 'Call this FIRST when you have many tools available and want to see the option set (not just one answer)'. Also implies alternative of calling specific tools directly.

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

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

Beyond annotations (readOnly, openWorld, idempotent, non-destructive), description adds details on data sources, internal URI format for filings, and fallback logic. 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?

Single paragraph is front-loaded with examples and covers all key points. Slightly verbose but every sentence adds value.

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

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

For a complex tool with no output schema, description lists all return components (cik, filings, fundamentals, patents, news, LEI). Missing details like pagination or limits beyond 'up to 5' filings, but still comprehensive.

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

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

Schema already fully describes both parameters (type enum, value as ticker/CIK with note about names). Description repeats this without adding new semantic info beyond what's in schema.

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

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

Description clearly states it produces a full cross-source profile of US public companies in one call, with example queries. It distinguishes from chaining single-pack lookups and specifies input types.

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

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

Explicitly advises to prefer this over chaining single-pack lookups for holistic views, and instructs to use resolve_entity if only a name is available. Also mentions patent API sunset and soft-fail behavior.

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 include destructiveHint=true and idempotentHint=true, so description adds context about clearing sensitive data but no new behavioral traits beyond what annotations suggest.

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

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

Two sentences, front-loaded with the action, no redundant words. Every sentence adds value.

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

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

Given the simple tool (1 param, no output schema, clear annotations), the description covers purpose, usage, and pairing with siblings adequately.

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 parameter 'key' is already described in schema as 'Memory key to delete.' Description adds no additional meaning beyond schema coverage (100%). Baseline score applies.

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?

Explicitly states 'Delete a previously stored memory by key,' providing a specific verb, resource, and method. Distinguishes it from sibling tools like 'remember' and 'recall' by focusing on deletion.

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

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

Clearly states when to use: 'when context is stale, the task is done, or you want to clear sensitive data.' Does not explicitly mention when not to use, but implies alternatives by referencing pair with remember and recall.

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

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

Description explains it fetches the page, extracts title/description/key links, and outputs markdown. This aligns with readOnlyHint, idempotentHint, and destructiveHint=false. It adds useful behavioral context beyond annotations, though lacks details on error handling or rate limits.

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

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

Three concise sentences: purpose and output, process, use cases. No unnecessary words, front-loaded with key 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?

Covers what the tool does, how it works, and use cases. Lacks mention of error scenarios or prerequisites (e.g., public URL), but is sufficient for a simple read-only tool with 2 parameters 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 covers both parameters with descriptions (URL and max_links). The tool description adds no significant new meaning beyond schema, so baseline 3 is appropriate given 100% schema 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?

Description clearly states the tool generates an llms.txt file for any URL, specifying the output format and purpose. It distinguishes from siblings like ai_visibility_check or scan_competitor_ai_presence by focusing on producing the standard llms.txt markdown.

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

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

Description lists three concrete use cases (client indexing, own project, competitor audit), providing clear context. However, it does not explicitly mention when not to use or compare to alternative tools 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?

Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds behavioral context by stating it returns exactly 0 or 1 hit plus close alternatives, which is beyond what annotations provide. 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 short, front-loaded with examples, and uses minimal words to convey purpose and usage. Every sentence adds value.

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

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

Given the presence of an output schema and the clarity of purpose, the description covers most key aspects. However, the 'dataset' parameter is left unexplained, which could be a minor gap for some agents.

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 33% of parameters have schema descriptions (authorship). The description provides examples and mentions authorship for disambiguation, but does not explain the 'dataset' parameter or the format of 'scientific_name'. The examples help partially compensate for low schema 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 tool performs exact scientific-name matching, returning 0 or 1 hit plus close alternatives. It provides concrete examples (e.g., 'Panthera leo') and distinguishes homonyms, making the purpose specific and distinct from sibling tools like 'search' or 'taxon'.

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 says 'Use when you have a precise Latin name and want to confirm acceptance or distinguish homonyms', providing clear guidance. It also notes that authorship can be passed to disambiguate homonyms. However, it does not explicitly state when not to use or mention alternative sibling tools.

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

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

The description discloses key behavioral traits beyond annotations, such as 'Rate-limited to 5 per identifier per day' and 'Free; doesn't count against your tool-call quota.' There is no contradiction with the provided annotations (readOnlyHint=false, etc.).

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

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

The description is concise at four sentences, each serving a clear purpose: stating the overall action, specifying when to use, providing quality criteria, and noting constraints. No unnecessary words.

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

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

Given the tool's complexity (3 parameters, nested objects, no output schema), the description is fully complete. It covers parameter meaning, usage scenarios, rate limits, and cost. The lack of output schema is acceptable for a feedback tool that likely returns a simple acknowledgment.

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

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

With 100% schema description coverage, the schema already documents all parameters. However, the description adds significant context by explaining each enum value in detail (e.g., 'bug = something broke or returned wrong data') and by giving usage guidance for the 'context' parameter. This goes beyond mere schema repetition.

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: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It uses specific verbs and resources, and distinguishes itself from siblings by listing concrete use cases (bug, feature, data_gap, praise).

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

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

The description explicitly tells when to use the tool: 'Use when a tool returns wrong/stale data (bug), when a tool you wish existed isn't in the catalog (feature/data_gap), or when something worked surprisingly well (praise).' It also advises what not to do: 'don't paste the end-user's prompt.' Additionally, it mentions the rate limit, helping the agent anticipate constraints.

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

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

Beyond annotations (readOnlyHint, idempotentHint), the description explains the data source (CF analytics-engine), privacy (no PII), and caching behavior (5min-1h). No contradiction with annotations.

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

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

Five concise sentences, each adding value. Front-loaded with the core purpose, followed by use cases and technical details. No redundancy.

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

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

Given no output schema, the description explains the return values (top tools, top packs, total call volume) but lacks explicit structure details. However, for a simple trend tool, this is adequate.

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 single parameter 'window' is well-described in both schema and description, with additional context on how shorter vs longer windows affect results. Schema coverage is 100%, and the description adds behavioral nuance.

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

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

The description clearly states what the tool does: 'Returns the top tools, top packs, and total call volume over a recent window.' It uses specific verbs and resources, and the context about being derived from CF analytics differentiates it from sibling tools like ask_pipeworx or discover_tools.

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

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

Three explicit use cases are provided: discovering hot data sources, confirming popular tools, and assessing alignment with common agent needs. This gives clear guidance on when to use the 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?

The description adds substantial behavioral context beyond annotations, including details on the algorithm (monotonicity violations, partition-sum checks), semantic anchor (Jaccard similarity ≥0.30), partition filter (placeholder slug handling), and response structure. No contradiction with annotations (readOnlyHint, idempotentHint, etc.).

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

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

The description is well-structured with a clear requirement upfront and detailed explanations afterward. However, it is verbose and could be tightened while retaining all essential information. Every sentence adds value but the length may reduce 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 complex tool with 2 parameters and no output schema, the description is remarkably complete. It covers the algorithm, filtering rules, edge cases (e.g., >20% placeholder fraction), and response structure, providing an agent with sufficient context to use the tool effectively.

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 significant meaning: explains the difference between modes, provides concrete examples, notes that full URLs are accepted for 'event', and describes how 'topic' searches related events. This goes well beyond what the schema provides.

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

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

The description clearly states the tool finds arbitrage opportunities on Polymarket via monotonicity violations and partition-sum checks, specifying two modes ('event' and 'topic'). The purpose is specific and actionable, though it does not explicitly differentiate from sibling tools like 'polymarket_edges' or 'polymarket_kalshi_spread'.

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

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

The description starts with the requirement that one of 'event' or 'topic' must be provided, and advises which mode to use ('event' recommended for specific markets, 'topic' for cross-event scanning). It provides examples and explains cross-event mode catches patterns single-event misses, but does not mention when to avoid this tool or suggest alternatives.

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

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

Annotations indicate readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds extensive behavioral context: caching at 1h, response structure with diagnostics, and detailed explanation of how each segment works, far exceeding what annotations alone provide.

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

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

The description is very detailed and well-structured with clear sections, but it is verbose. It could be more concise without losing essential information. Front-loading is present (purpose stated first).

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 complexity (9 parameters, three model families, multiple segments) and no output schema, the description is extremely complete. It explains all segments, knobs, response fields, and diagnostics, leaving no gaps for the agent.

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

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

Schema coverage is 100% with all 9 parameters described. The description adds extra context beyond schema, such as explaining that min_kelly skips small opportunities and slippage_pp is subtracted before ranking. This adds value beyond the schema definitions.

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

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

The description clearly states the tool scans Polymarket markets and returns opportunities where Pipeworx data disagrees with market price. It distinguishes from siblings by mentioning three model families and specific segments like MODEL_DRIVEN, STRUCTURAL_ARBITRAGE, CONCENTRATED_LONGSHOT, which are unique to this tool.

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 says 'Built for "what should I bet on today"' and provides detailed guidance on knobs like min_liquidity, max_spread_pp, and min_partition_leg_kelly. However, it does not explicitly state when not to use this tool or compare it to siblings like polymarket_arbitrage.

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

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

Annotations already indicate read-only, open-world, idempotent behavior. The description adds critical context: compatibility_warning conditions, temporal alignment check, skipped cross-type/subtype counters, and when no arbitrage exists. This fully discloses limitations and data reliability.

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 fairly long but well-structured using headers (TWO MODES, RESPONSE, SAFETY FIELDS). Every sentence provides unique value, though some technical details could be tightened. It is front-loaded with the core purpose and usage modes.

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

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

Despite lacking an output schema, the description comprehensively explains the response structure, safety fields, and edge cases. For a complex tool with 3 parameters and zero required parameters, it provides sufficient context for an AI agent to understand usage and interpret results.

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

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

Schema coverage is 100% with parameter descriptions. The description adds meaning: explains the topic enum values, clarifies that explicit parameters override topic mappings, and provides examples in the schema. It does not detail parameter formats but complements the schema well.

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 identifies the tool as a cross-venue spread analyzer between Kalshi and Polymarket, specifying the verb-resource relationship. It distinguishes itself from sibling tools like polymarket_arbitrage by focusing on inter-venue spreads for the same resolving question.

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 (topic shortcuts vs. explicit pairing) and warns that most pre-mapped topics are not tradeable due to compatibility warnings. It provides scenarios where spreads are meaningless (temporal misalignment, non-equivalent bet shapes), but lacks explicit comparison to alternatives like directly using individual venue tools.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds scoping: 'Scoped to your identifier (anonymous IP, BYO key hash, or account ID).' No contradictions.

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

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

Three sentences, front-loaded with action, no redundant information. Every sentence serves a purpose.

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

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

For a tool with one optional parameter, no output schema, and clear annotations, the description fully covers behavior, scoping, and sibling relationship.

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% and already explains the parameter. Description repeats 'omit to list all keys' and adds retrieval context, but does not add substantial new meaning beyond schema.

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

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

Description clearly states 'Retrieve a value previously saved via remember, or list all saved keys', with specific verb and resource. Distinguishes from siblings by mentioning 'Pair with remember to save, forget to delete.'

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

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

Provides context: 'Use to look up context the agent stored earlier... without re-deriving it from scratch.' Mentions pairing with remember and forget, but does not explicitly exclude alternative tools.

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

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

Annotations already indicate readOnly, idempotent, non-destructive, open world. Description adds details: fan-out to multiple sources, fallback logic (GDELT→GNews), date parsing, and soft-fail for USPTO. 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?

Description is detailed but front-loaded with purpose and examples. Efficient, though slightly long for a concise tool description.

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, description explains return format (structured changes grouped by source, total_changes count, citation URIs). Covers data sources, fallback, and constraints. No obvious 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?

100% schema coverage, but description adds examples, relative shorthand explanation, and recommendation for typical monitoring ('30d' or '1m'). Adds meaning beyond schema.

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

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

The description clearly states it's a 'change feed for a company' with examples of queries, specifies multiple data sources (SEC EDGAR, GDELT→GNews, USPTO), and distinguishes from sibling tool entity_profile for static profiles.

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

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

Provides explicit use cases ('What's new with X') and directs to entity_profile for static profile. However, does not exhaustively list when not to use this 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?

Adds significant context beyond annotations: persistence scoping (authenticated vs anonymous), expiration (24 hours), and that it's a write operation (consistent with readOnlyHint=false). No annotation contradictions.

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

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

Three concise sentences, each adding value: what it does, when to use, and how it works. Front-loaded with purpose, 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?

For a simple two-parameter write tool with full schema coverage and annotations, the description covers why, when, how, and persistence details. Complete and self-sufficient.

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

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

Schema coverage is 100% with clear descriptions for both key and value. Description does not add new semantic info beyond schema, so 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?

Description clearly states the verb 'Save' and resource 'data' as a key-value pair. It distinguishes from siblings recall and forget, ensuring the agent knows this is for storing, not retrieving or deleting.

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 when you discover something worth carrying forward', providing clear context. Mentions pairing with recall and forget but does not specify when not to use or alternatives beyond 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?

Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds rich behavioral context: internal cascading through multiple endpoints, return fields (ticker, CIK, citation URIs for company; RxCUI, ingredient, brand, citation for drug), and that each call replaces manual lookups. No contradiction with annotations.

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

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

The description is moderately long but well-structured: examples first, then core purpose, then usage hint, then supported types with details. It is front-loaded with key information. Slight room for trimming but every sentence adds value.

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

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

Given the two entity types (company, drug) with different input/output patterns, the description covers when to use, what each type accepts, what it returns (including citations), and internal behavior. No output schema exists, but the description sufficiently explains returns. Complete enough for an agent to use correctly.

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

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

Schema coverage is 100% with both parameters described. The description adds concrete examples (e.g., 'AAPL', '0000320193', 'ozempic') and explains how each type of value is interpreted for company vs drug. This goes beyond the schema by providing 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 starts with concrete query examples ('ticker for…', 'find the CIK for…'), then states the verb 'resolve' and resource 'name to identifier'. It explicitly distinguishes from siblings by saying 'Use FIRST whenever you have a name but need an ID'. This makes the purpose specific and distinct.

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

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

The description clearly tells when to use ('Use FIRST whenever you have a name but need an ID') and highlights that it replaces 2-3 manual lookups. It does not explicitly state when not to use or name alternatives, but the sibling list provides context, and the guideline 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?

Description explains it probes each entity with ai_visibility_check, ranks by score, and surfaces most/least recognized. Mentions defaults and optional Anthropic model. Annotations already cover safety (readOnly, idempotent). Description adds behavioral detail beyond annotations.

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

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

Three sentences, each with distinct purpose: what it does, how it works, when to use it. No redundant or unnecessary text. Well-structured and efficient.

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

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

Covers all key aspects: parameters, behavior, output structure (score, confidence, signal density), and special handling of first entity. No output schema, but description explains return format. Sufficient for an agent to invoke correctly.

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

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

Schema descriptions are comprehensive (100% coverage). Description adds context: first entity treated as subject, context disambiguates, models default to workers-ai. This adds 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 tool compares AI visibility across multiple entities side-by-side, distinct from sibling ai_visibility_check which is per-entity. It gives a concrete use case (competitive audits) and specifies output (ranked list).

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

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

Provides explicit use case (competitive AI-marketing audits) and an example question. Does not explicitly state when not to use or alternatives, but the context implies its purpose relative to sibling tools.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds value by detailing the composite nature, external APIs (deps.dev, bundlephobia), partial failure graceful degradation, and timing caveats for first bundlephobia measurement. 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?

Efficient single paragraph, front-loaded with purpose, then usage, then behavioral details. Every sentence adds value, and it's structured for quick scanning.

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 and the provided schema/annotations (no output schema), the description is complete. It covers parameters, return value summary fields, external services, fallback behavior, and ecosystem 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?

Schema coverage is 100%, so baseline is 3. The description adds context that scoped packages like '@types/node' are accepted and that version defaults to latest when omitted, which goes slightly 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 it is a composite check for npm packages, covering license, advisories, version history, and bundle size. The verb 'scan' and resource 'dependency' are specific, and it distinguishes itself from siblings like 'deals.dev:version' for other ecosystems.

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

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

Explicitly says when to use: when asked 'is X safe / popular / small' or 'what does adding lodash cost me'. Also specifies when not to use: for PyPI/Maven/Cargo/Go, use 'deals.dev:version' directly.

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, idempotent, openWorld. Description adds that it returns 'matching name-usages with scientific name, authorship, rank, status, and taxon ID' and mentions it includes synonyms and misapplied names. 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?

Description is well-structured with front-loaded examples, but slightly verbose. Each sentence adds value, though compression is possible.

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

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

Given high schema coverage, detailed annotations, and output schema, the description covers purpose, usage, parameters, return values, and sibling relationships completely.

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 83%, so description adds value by explaining the source, return fields, and default dataset key ('3LR'), and provides examples for rank and limit usage.

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 'AUTHORITATIVE taxonomic lookup for any species, genus, family, or higher taxon' with specific examples. It mentions the source (Catalogue of Life) and distinguishes from siblings by naming follow-up tools (taxon, classification).

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 example queries like 'Panthera leo' and 'Canis' with rank filter, and suggests using it for scientific name lookups. Implies when to use taxon or classification as follow-ups, but lacks explicit when-not-to-use conditions.

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 non-destructive. The description adds that synonyms are 'currently mapped to a single Catalogue of Life accepted taxon,' which gives behavioral context about the mapping. No contradiction, but no further details on output or limitations.

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 example queries and is reasonably concise. Every sentence adds value, though the example format could be more compact.

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 output schema exists and annotations cover safety, the description adequately explains the tool's purpose and usage. However, it omits explanation of the dataset parameter and the exact output behavior, leaving minor gaps.

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

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

Schema description coverage is 0%, so the description must explain parameters. It implies the 'id' is a species or organism reference via example queries, but does not explicitly describe either parameter, especially the optional 'dataset'. This leaves ambiguity.

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

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

The description clearly states the tool lists synonyms (alternative or historical scientific names) mapped to a single accepted taxon, with example queries that distinguish its purpose from sibling tools like children, classification, or vernacular.

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 to use it to map outdated taxonomy to current names, providing clear context for when to invoke. It does not explicitly list alternatives or when-not-to-use, but the usage guideline is strong enough for most agents.

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 convey read-only, open-world, idempotent, non-destructive traits. The description adds the nuance that it fetches the accepted concept (not name-usage) and mentions pairing with other tools, but no additional behavioral traps or constraints beyond what annotations cover.

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, effectively front-loaded with the primary purpose and usage context. It is concise but lacks any wasted words.

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

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

Given the simple tool (2 params, no enums, output schema existing), the description covers the core functionality and usage context. However, it fails to explain the optional dataset parameter, leaving a minor gap 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?

With 0% schema description coverage, the description should explain parameters. It only references the 'id' parameter implicitly ('by ID', 'taxon_id') but does not describe the optional 'dataset' parameter or provide any additional meaning for either parameter beyond the schema types.

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 ('Fetch a Catalogue of Life taxon by ID'), the specific resource (accepted concept vs name-usage), and how the ID relates to search results, making the purpose unambiguous.

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

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

The description explicitly recommends pairing with sibling tools like classification, children, and vernacular, and directs users to use the taxon_id from search results. It lacks explicit when-not-to-use guidance but provides actionable context.

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds context about the output (includes taxon, name, status, source dataset) and that it fetches a single record by ID. This goes beyond annotations, as annotations do not describe output contents. However, there is an output schema which likely covers output structure, so the description's behavioral disclosure is complementary but not extensive.

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

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

The description is concise: two sentences with no fluff. The first sentence states core purpose, the second provides usage guidance. It is front-loaded and every sentence adds value.

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

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

Given the tool's simplicity (2 parameters, 1 required), the presence of an output schema, and strong annotations, the description is complete. It explains the primary purpose, what the record includes, and when to use alternative tools. No critical information is missing 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 description coverage is 0%, so the description must compensate. The description only implicitly explains the 'id' parameter (by ID) but provides no explanation for the optional 'dataset' parameter. This is insufficient; the description should clarify both parameters, especially 'dataset' which could filter source datasets.

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: 'Fetch a single Catalogue of Life name-usage record by ID'. It specifies the verb 'Fetch', the resource 'Catalogue of Life name-usage record', and includes what the record contains (taxon, name, status, source dataset). It also distinguishes from sibling tools by referencing classification and vernacular for related tasks.

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: 'Use after search or name_match to get the full structured record; for the taxonomy chain use classification, for common names use vernacular.' This clearly tells the agent when to use this tool and when to use alternatives.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. Description adds details about the verdict types returned (confirmed, refuted, etc.), data sources (SEC EDGAR+XBRL), and citation format, which goes beyond what annotations provide.

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

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

Description is informative but slightly dense; it mixes triggers, purpose, scope, and output details. Could be more structured, but no wasted 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?

With one parameter, no output schema, and clear annotations, the description provides sufficient detail on input format, output values, data sources, and limitations. Complete for this tool's complexity.

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

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

Schema coverage is 100% for the single 'claim' parameter. Description provides concrete examples and explains the natural-language format, adding meaning 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?

Description starts with natural-language triggers like 'fact check' and 'verify the claim', then specifies it's for company-financial claims via SEC EDGAR+XBRL. It clearly states it replaces 4-6 sequential calls, distinguishing it from sibling tools.

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

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

Explicitly says 'Use whenever the agent needs to check whether something a user said is factually correct' and gives examples. Scope is clearly limited to company-financial claims for public US companies, but no explicit exclusions or alternatives mentioned.

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

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

Annotations indicate readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. Description adds context that results can be in various languages, which aligns with openWorldHint. No contradictions. It could be improved by mentioning no side effects beyond listing.

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 natural language queries is concise and effective. No extraneous words. Could be slightly more structured (e.g., bullet points) but is still 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?

The tool has a simple purpose and an output schema, so the description does not need to explain return values. However, the lack of parameter descriptions leaves a gap, especially since the schema has no descriptions. For a tool with two parameters, the description is adequate but not fully 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 0%, and the description does not explain the two parameters (id and dataset). While the example shows a valid id, the meaning of 'dataset' is left unclear. For a tool with low schema coverage, the description should clarify parameters but fails to do so.

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 that the tool lists common/vernacular names for a Catalogue of Life taxon, with example queries like "What's the common name for [Latin binomial]" and mapping examples. It distinguishes from sibling tools such as 'synonyms' or 'classification' by focusing specifically on vernacular names in multiple languages.

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

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

Description provides example queries that clarify when to use the tool (e.g., for converting scientific names to common names). It does not explicitly state when not to use it or suggest alternatives, but the context is clear enough for an AI agent to make a reasonable decision.

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