exchange

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

Annotations already indicate read-only, idempotent, non-destructive. The description adds valuable context: default model, cost implications (free vs BYO key), return format (per-model and combined view), and disambiguation help via context parameter.

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

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

Three sentences: first sentence states core purpose, second details models and cost, third describes output. Every sentence earns its place with no redundancy.

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

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

Given the tool's complexity (4 parameters, no output schema), the description covers all necessary aspects: what it probes, how scoring works, model options and costs, output structure. It is fully self-contained.

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 4 parameters. The description adds further meaning by explaining default behavior for 'models', when to use '_apiKey', and the purpose of '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 it probes LLMs for knowledge and scores visibility. It uses specific verbs and distinguishes from siblings by specifying the scoring mechanism and default model.

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 use cases (AI-marketing audits, pre-launch brand checks, competitive monitoring) but does not directly mention when not to use or name alternatives among siblings.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains that Pipeworx 'picks the right tool, fills the arguments, and returns the result,' which covers the automation aspect. However, it lacks details on limitations (e.g., data source availability, response time, error handling) or authentication needs, leaving gaps 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 front-loaded with the core functionality, uses efficient sentences, and includes relevant examples without redundancy. Every sentence adds value: the first explains the tool's purpose, the second details its automation, and the third provides concrete usage examples.

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

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

Given the tool's complexity (natural language querying with automated tool selection) and lack of annotations or output schema, the description does well by explaining the process and providing examples. However, it could be more complete by mentioning potential limitations or the types of data sources available, which would help set accurate 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?

Schema description coverage is 100%, so the schema already documents the single 'question' parameter. The description adds value by emphasizing 'plain English' and 'natural language,' providing examples that illustrate the expected format beyond the schema's basic description. However, it doesn't detail constraints like length or supported topics.

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

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

The description clearly states the tool's purpose: 'Ask a question in plain English and get an answer from the best available data source.' It specifies the verb ('ask'), resource ('answer'), and mechanism ('Pipeworx picks the right tool, fills the arguments'), distinguishing it from sibling tools like currency converters or memory tools.

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

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

The description explicitly states when to use this tool: 'No need to browse tools or learn schemas — just describe what you need.' It provides clear alternatives (implicitly suggesting other tools for structured queries) and includes 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?

Beyond annotations (readOnlyHint, idempotentHint, etc.), the description details the tool's internal process: picks tool, fills arguments, fetches data, extracts answer using only the result. It discloses refusal reasons (not_in_source, no_tool_match, etc.) and the extra LLM call cost. 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 lengthy but well-structured, with key information front-loaded. Every sentence contributes value, though minor redundancy exists in listing aliases. Overall, it earns its space without being bloated.

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 explicitly defines the return format (object with answer, evidence, confidence, source, etc.) and covers refusal scenarios. It also explains the tool's internal routing and cost trade-off, making it complete for a query tool in high-stakes contexts.

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?

All 6 parameters (including aliases) are documented in the input schema with 100% coverage. The description does not add meaning beyond the schema; it only reaffirms that 'question' accepts natural language. Baseline score of 3 is appropriate given full 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 it is a 'hallucination-resistant answer mode for high-stakes reads' and distinguishes itself from the sibling ask_pipeworx by emphasizing grounded answers with explicit refusal reasons. The verb 'ask' and resource 'Pipeworx' are specific, and the description clarifies the tool's unique value proposition.

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 when to use ('whenever an answer will be quoted, cited, or acted on') and when not to ('prefer ask_pipeworx for casual lookups'). It also names the alternative tool (ask_pipeworx) and provides clear context for high-stakes scenarios.

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

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

Beyond annotations (readOnly, idempotent, destructive false), the description details resolution contracts, parent event extraction, news fallback, safety short-circuits, closed market handling, and wide-spread warnings. This adds substantial behavioral context and does not contradict annotations.

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

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

The description is long but well-structured with sections (CLASSIFIERS, FAN-OUT EXAMPLES, RESPONSE SHAPES, etc.). It is front-loaded with the core purpose and every sentence adds value. Could be slightly more concise but justified by complexity.

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

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

Given no output schema and complex behavior, the description is exceptionally complete. It covers resolution confidence levels, parent event handling, news fallback mechanisms, safety measures for low-confidence matches, closed markets, and illiquid spread warnings. No gaps are apparent.

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

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

With 100% schema coverage, baseline is 3. The description adds context by explaining depth default behavior and include_raw purpose, and provides examples for market_input. This adds value beyond the schema descriptions.

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

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

The description clearly states it researches a Polymarket bet by pulling Pipeworx data, resolving markets, classifying bets, and fanning out to data packs. It distinguishes from siblings like 'polymarket_edges' and 'polymarket_arbitrage' by focusing on comprehensive research for a single bet.

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?

Explicit usage guidance is given: 'Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z".' It does not explicitly list when not to use or alternatives, but the context is clear and examples help.

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

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

No annotations are provided, so description carries full burden. It describes return data (paired data + URIs) but lacks details on side effects, authentication, rate limits, or error behavior. As a read-like operation, it should state it's non-destructive, but that is implied rather than explicit.

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 pack all essential information: entity types, data fields, efficiency claim. No fluff, front-loaded with purpose.

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

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

No output schema, but description explains returned data (paired + URIs) and covers two modes. Lacks behavior under edge cases (e.g., invalid entities) but sufficient for typical use.

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

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

Schema covers 100% of parameters, but description adds crucial context: examples for values (tickers/CIKs for company, names for drug), and what data each type returns. This goes beyond basic enum and array 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 clearly states the tool compares 2-5 entities side by side, specifies two types (company and drug) with distinct data returned (revenue, net income for company; adverse-event counts, FDA approvals for drug), and notes it replaces 8-15 sequential calls. This is highly specific and differentiates 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?

Description implies usage for batch comparison and mentions efficiency gain, but does not explicitly state when not to use (e.g., for single entity) or alternatives. Sibling tools like resolve_entity or ask_pipeworx might handle single queries, but no exclusion is provided.

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 mentions 'current exchange rate' but doesn't specify source, update frequency, or accuracy. It lacks details on error handling, rate limits, authentication needs, or what happens with invalid inputs. For a financial tool with zero annotation coverage, this is a significant gap.

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

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

The description is a single, efficient sentence that directly states the tool's function. It's front-loaded with the core purpose and contains no unnecessary information. Every word earns its place, making it highly concise and well-structured.

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

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

Given the tool's complexity (financial conversion with real-time data implications), no annotations, and no output schema, the description is incomplete. It doesn't explain return values, error cases, or behavioral nuances like rate freshness. For a tool with these characteristics, more context is needed to be fully helpful to an AI agent.

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

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

The description implies parameters (from, to, amount) but doesn't add meaning beyond what the input schema provides. With 100% schema description coverage, the schema already documents all three parameters clearly. The description doesn't provide additional context like currency code formats or amount constraints, so it meets the baseline for high 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's purpose: converting an amount between currencies at current exchange rates. It specifies the verb ('convert') and resources ('amount from one currency to another'), but doesn't explicitly distinguish it from sibling tools like get_rate or get_historical_rate, which are related but serve different purposes.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like get_currencies, get_historical_rate, or get_rate, nor does it specify scenarios where this conversion tool is preferred over those alternatives. There's no context about prerequisites or limitations.

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, and idempotent behavior. The description adds critical context: verbatim evidence, gaps array for unknown facets, pre-verified facts, parallel execution, and time estimate (15-60s). 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?

Approximately 120 words, front-loaded with core purpose, followed by mechanics, usage guidance, prerequisites, and timing. 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?

Given the tool's complexity and no output schema, the description fully covers purpose, behavior, parameters, prerequisites, and output format (structured findings packet). No gaps remain for an agent to select and invoke correctly.

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

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

Schema coverage is 100%, but the description adds value by explaining enum values (quick=3, standard=5, thorough=8) and clarifying that broad questions are acceptable. Default depth (standard) is implied but not explicit 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?

The description clearly states the tool performs grounded multi-source research in one call, decomposing questions into sub-questions and routing to 3,744 tools across 884 sources. It distinguishes from siblings like ask_pipeworx for single 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?

Explicitly recommends use for broad or multi-part questions and specifies when to use ask_pipeworx instead. Also notes prerequisites (Pipeworx account, paid plan for thorough depth) and expected timing.

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 the search functionality and return format (tools with names/descriptions), but lacks details about performance characteristics (e.g., response time, rate limits), error conditions, or authentication requirements that would be helpful for an agent.

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

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

The description is perfectly concise with two sentences that each serve distinct purposes: the first explains the core functionality, the second provides critical usage guidance. Every word earns its place with zero 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?

For a search tool with no annotations and no output schema, the description provides good context about when to use it and what it returns. However, it could be more complete by mentioning what happens when no tools match the query or providing more detail about the return format beyond 'names and descriptions.'

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 parameters are well-documented in the structured schema. The description doesn't add significant semantic context beyond what's already in the schema descriptions, maintaining the baseline score for high 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's purpose with specific verbs ('search the Pipeworx tool catalog') and resource ('returns the most relevant tools with names and descriptions'). It distinguishes itself from sibling tools like currency converters by focusing on tool discovery rather than data retrieval or conversion 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 ('call this FIRST when you have 500+ tools available and need to find the right ones for your task'). It also implicitly suggests alternatives (directly using known tools) by emphasizing this as an initial discovery step for large tool catalogs.

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, non-destructive, idempotent behavior. Description adds substantial behavioral context: fans out across multiple sources (SEC, XBRL, USPTO, news, GLEIF), details return data (cik, filings with URIs, fundamentals, patents, news, LEI), and mentions USPTO API sunset in May 2025 with soft-fail. No contradictions with annotations.

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

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

Description is information-dense but well-structured, front-loading example queries and purpose. Every sentence serves a purpose: usage guidance, data sources, return values, limitations. No fluff 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?

No output schema exists, so description fully explains return values (cik, company_name, recent_filings with links, fundamentals, patents, news, LEI). It also covers data sources, fallbacks (GDELT→GNews), and future limitations (USPTO sunset). Complete for a complex multi-source 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 covers 100% of parameters with descriptions. Description adds extra value by providing concrete examples (ticker 'AAPL' or CIK '0000320193') and reinforcing that names are not supported, improving clarity beyond 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?

Description explicitly states tool provides 'full cross-source profile of a US public company in ONE parallel call' and lists example queries like 'Tell me about X' and 'company profile for Microsoft'. It distinguishes from siblings by recommending use over chaining single-pack lookups and directing to resolve_entity for names.

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 explicitly states when to use (holistic company view) and when not to (names not supported), with direct alternative: 'use resolve_entity first if you only have a name'. Also says 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups', providing clear usage context.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool deletes a memory, implying a destructive mutation, but doesn't cover critical aspects like whether deletion is permanent, requires specific permissions, has side effects, or provides confirmation. This leaves significant gaps 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 wasted words. It front-loads the core action ('Delete') and resource, making it immediately understandable. Every word earns its place, achieving optimal conciseness.

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 destructive tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., permanence, error handling), usage context, and return values. While concise, it doesn't provide enough information for safe and effective use in a complex system.

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 description adds minimal value beyond the input schema, which has 100% coverage and documents the 'key' parameter adequately. The description mentions 'by key' but doesn't elaborate on key format, examples, or constraints. Given the 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 specific action ('Delete') and resource ('a stored memory by key'), distinguishing it from sibling tools like 'recall' (retrieve) and 'remember' (store). It uses precise language that leaves no ambiguity about the tool's function.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., that a memory must exist to be deleted), exclusions, or comparisons to siblings like 'recall' (for retrieval) or 'remember' (for storage). Usage is implied 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?

Annotations already declare readOnly, openWorld, idempotent, non-destructive. Description adds valuable context: fetches page, extracts title/descriptions/links, produces standard markdown. No contradiction.

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

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

Three efficient sentences, front-loaded main purpose, then use cases. No wasted 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 2 params, full schema coverage, no output schema, and comprehensive annotations, the description fully covers purpose, input, output format, and use cases. Sufficient for agent understanding.

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

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

Schema coverage is 100% with clear descriptions for both parameters. The tool description does not add significant new parameter-level meaning beyond what schema provides, so baseline 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 uses specific verb 'generate' and resource 'llms.txt file', identifies target users and distinct action (fetches, extracts, emits), and clearly distinguishes from sibling tools like visibility checks or scanning 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 lists three use cases (client indexing, personal project drafting, competitor auditing). While it does not state when not to use, the scenarios are clear and aligned with the tool's function.

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 action as a list operation, implying read-only behavior, and specifies the data source (Frankfurter API) and output detail ('full names'). However, it does not mention potential limitations like rate limits, error handling, or response format beyond the names.

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

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

The description is a single, efficient sentence that front-loads the core action ('List all currencies') and includes essential details (API source and output format) without any wasted words. Every element serves a clear 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?

Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is complete enough for a simple list operation. It specifies the API source and output detail, though it could benefit from mentioning the response structure or any constraints to achieve full 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?

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately adds value by explaining the tool's purpose and output without redundant parameter details, earning a baseline score of 4 for zero-parameter tools.

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

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

The description clearly states the specific action ('List all currencies') and resource ('supported by the Frankfurter API'), distinguishing it from sibling tools like convert, get_historical_rate, and get_rate. It explicitly mentions 'with their full names' to specify the output scope.

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 'supported by the Frankfurter API' and the output format, but does not explicitly state when to use this tool versus alternatives like get_rate or get_historical_rate. It provides clear context but lacks explicit exclusions or comparisons.

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 full burden. It states the basic operation but lacks behavioral details like rate limits, authentication needs, error conditions (e.g., invalid dates or currencies), data source, or return format. The description doesn't contradict annotations (none exist).

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

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

The description is a single, efficient sentence that front-loads the core purpose with no wasted words. Every element ('Get', 'exchange rate', 'two currencies', 'specific historical date', 'YYYY-MM-DD') contributes directly to understanding the 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 no annotations and no output schema, the description is incomplete for a tool with 3 parameters. It covers the basic operation but lacks critical context like return value structure, error handling, data freshness, or limitations (e.g., date range constraints beyond the schema's 'earliest available' note).

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%, providing clear parameter documentation. The description adds minimal value beyond the schema by reinforcing the date format (YYYY-MM-DD) and historical context, but doesn't explain parameter interactions or provide additional semantics like currency code examples beyond what's in 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 specific action ('Get the exchange rate') and resource ('between two currencies on a specific historical date'), using a precise verb. It distinguishes from sibling tools like 'get_rate' (likely current rate) and 'convert' (likely conversion operation) by specifying the historical aspect.

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 ('on a specific historical date') but doesn't explicitly state when to use this tool versus alternatives like 'get_rate' (presumably for current rates) or 'convert' (presumably for actual conversions). No exclusions or prerequisites are 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves current exchange rates but lacks details on data sources, accuracy, rate limits, error handling, or response format. This is a significant gap for a tool that likely relies on external APIs.

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

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

The description is a single, efficient sentence that front-loads the core purpose with an illustrative example. There's zero waste, and it's appropriately sized for a simple tool with two parameters.

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

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

Given the tool's complexity (simple but with potential external dependencies), lack of annotations, and no output schema, the description is incomplete. It doesn't address behavioral aspects like rate limits, data freshness, or error cases, which are critical for an exchange rate tool. More context is needed for reliable use.

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

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

Schema description coverage is 100%, with clear parameter descriptions in the schema. The description adds minimal value beyond the schema by providing an example (e.g., USD to EUR) but doesn't explain parameter constraints or usage beyond what's already documented. Baseline 3 is appropriate given high 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's purpose with a specific verb ('Get') and resource ('exchange rate between two currencies'), including an example. It distinguishes from sibling tools by focusing on current rates rather than conversion, historical data, or currency lists, though it doesn't explicitly name alternatives.

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

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

Usage is implied through the description's focus on 'current exchange rate,' suggesting this tool is for real-time rates rather than historical data (get_historical_rate) or currency conversion (convert). However, there's no explicit guidance on when to use this versus siblings or any prerequisites.

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 and idempotentHint. The description adds that it returns only the caller's subscriptions and specifies the exact fields returned. This additional context is useful, though not critical given the strong 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: first sentence states purpose and return fields, second gives usage guidance. No extraneous words, fully front-loaded with the most critical 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 simple read-only tool with one optional parameter and no output schema, the description provides all necessary context: what it does, what it returns (field list), and when to use it. The annotations cover safety and idempotency, making the definition 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?

The input schema fully describes the only parameter (include_inactive) with a clear description. The tool description mentions 'active' subscriptions, which aligns with the default false, but adds no new semantic information beyond the schema. With 100% schema coverage, baseline is 3.

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

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

The description explicitly states the tool lists the caller's subscriptions and enumerates the returned fields (id, type, params, etc.). This clearly distinguishes it from sibling tools like subscribe and unsubscribe, which modify subscriptions.

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 specific use cases: review before adding more subscriptions or find an id to cancel. It implies using subscribe/unsubscribe for modifications, but does not explicitly state when not to use this tool. Sibling differentiation is clear.

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

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

No annotations provided, so description carries full burden. Discloses rate limiting (5 per identifier per day), free usage, and content restrictions. Lacks details on post-submission handling, but adequate for a simple feedback tool.

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

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

Three sentences, no redundancy. Purpose, use cases, and guidelines are front-loaded. Every sentence adds information without excess.

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 annotations or output schema, description covers purpose, usage, behavioral constraints, and parameter guidelines adequately. Could mention expected response time or confirmation, but not critical for a feedback 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 covers all 3 parameters with descriptions (100% coverage). Description adds value beyond schema by providing usage tips for the message parameter ('describe what you tried... do not include end-user prompt'). This helps agents craft appropriate inputs.

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 'Send feedback to the Pipeworx team' with specific verb and resource. Lists explicit use cases (bug reports, feature requests, etc.), distinguishing it from all sibling tools which serve different purposes.

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

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

Provides explicit guidance: what to include (tools/data context), what to avoid (end-user prompt verbatim), and rate limits (5 per day). While it doesn't explicitly say when not to use, the enumerated use cases make alternatives 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?

Beyond annotations (readOnly, idempotent, not destructive), the description adds that data is self-aggregating, no PII, and cached 5min-1h depending on window. This gives useful behavioral context without contradicting 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 three bullet points, each earning its place: first sentence states core function, second outlines use cases, third provides source and caching details. Front-loaded and 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 read tool with one optional param and no output schema, the description covers purpose, use cases, and data source, but lacks any detail on the structure or format of the returned data (e.g., how many items, sorted or not). Minor gap.

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%—the parameter 'window' already has a description and enum. The description rephrases the same guidance (short vs long windows) but does not add new semantic information 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 returns top tools, top packs, and call volume over a window. The verb 'returns' and resource 'Pipeworx trending' are explicit, and it distinguishes from siblings like ask_pipeworx or discover_tools by focusing on aggregated usage 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?

Provides three concrete use cases in bullet points: discovering hot data sources, confirming canonical tools, and checking alignment with agent needs. Implicitly guides when to use, but does not explicitly name alternatives or state when not to 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 declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds detailed logic: Jaccard similarity threshold of 0.30, partition filter dropping high-placeholder slugs, and the partition check (sum of YES prices ≈1). 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 detailed and well-structured, starting with the requirement and then explaining modes, response, etc. However, it is somewhat verbose and could be more concise 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 tool's complexity and no output schema, the description covers the return structure (opportunities[], partition_check), edge cases (no args fails, Jaccard similarity, placeholder filtering). It is comprehensive enough for an AI 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 descriptions. The description adds concrete examples (e.g., 'fed-decision-may-2026', 'Strait of Hormuz traffic returns to normal') and explains the behavior of each mode, providing 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 finds arbitrage opportunities on Polymarket using monotonicity violations and partition-sum checks, and distinguishes between single-event and cross-event modes. This differentiates it from siblings like polymarket_edges and 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 explicitly requires one of 'event' or 'topic' and recommends 'event' for specific markets and 'topic' for cross-event scanning. It explains why cross-event mode catches patterns missed by single-event. However, it does not mention when to use this tool over siblings or provide when-not guidance.

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

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

The description goes far beyond annotations by detailing the internal logic, model families, segmentation, edge computation (including slippage and kelly fractions), filter knobs, caching behavior, and diagnostic output. It discloses all relevant behavioral traits without contradicting the annotations.

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

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

The description is highly detailed and well-structured with clear sections, but it is verbose and includes technical model details (e.g., FRED log-returns, GDELT ratio) that may not be necessary for an AI agent to use the tool effectively. Pruning could improve conciseness 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?

Despite lacking an output schema, the description thoroughly explains the response structure (by_segment segments, fed_candidates, diagnostics) and the fields in each opportunity. Given the tool's complexity, the description provides complete contextual information for correct invocation and interpretation.

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 parameters. The description adds meaningful usage context, such as how min_liquidity and max_spread_pp act as tradeable-edge filters and how min_partition_leg_kelly applies specifically to partition opportunities, enhancing 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's purpose: scanning top Polymarket markets for opportunities where Pipeworx data disagrees with market price. It specifies the verb 'scan' and resource 'opportunities', and distinguishes from sibling tools like 'polymarket_arbitrage' by focusing on Pipeworx data and daily scanning.

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

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

The description provides clear context on when to use the tool ('what should I bet on today') and hints at alternatives (e.g., other tools for cross-platform spreads). It lacks explicit when-not-to-use statements but gives enough guidance through the detailed explanation of filters and segments.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds significant detail: snapshot-based data, 60-day TTL, daily close computation, cache-miss gaps, and response structure. No contradictions with annotations.

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

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

The description is thorough but remains focused and front-loaded with purpose. It could be more structured (e.g., sections), but every sentence adds value and there is no fluff.

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

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

Given no output schema and two simple parameters, the description fully explains the response format (tracked, expired, snapshot_dates), limitations (60-day TTL, daily closes), and behavioral nuances (gaps imply no scan). It is complete 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%, so baseline is 3. Description repeats default values (days=14, window='1wk') and adds lookback bounds and snapshot family concept, but does not add substantial new 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's purpose: providing edge persistence and decay telemetry from daily snapshots. It answers the specific question 'how long has this edge existed and is it shrinking?' and differentiates from siblings like polymarket_edges by focusing on telemetry rather than current edges.

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

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

The description provides strong context on when to use the tool (e.g., distinguishing between fresh and old edges) and explains the value of the telemetry. While it doesn't explicitly list alternatives or when NOT to use, the context is clear and helpful.

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, so safety is known. The description adds rich behavioral context: walking the order book ladder, returning specific fields (top_of_book, vwap_fill_price, slippage_pp, etc.), and warning about forced_directional_risk and thin_legs. 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 sections (REQUIRES, SINGLE-MARKET, BASKET, USE THIS) and front-loads the main purpose. While it is relatively long, every sentence adds value given the tool's complexity. Could be slightly more concise.

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 thoroughly covers return values for both modes (top_of_book, vwap_fill_price, slippage_pp, etc. for single; theoretical_sum, realizable_sum, capture_ratio, profit_usd, per-leg detail, thin_legs, forced_directional_risk for basket). It also explains risk of unhedged positions. Very 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 covers 100% of parameters, but the description adds significant context beyond schema: explains dual mode (market vs event), default values, interpretation of size_usd in each mode (spend vs settlement notional), and side defaults. This is valuable for correct 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 the tool checks 'realizable-vs-theoretical edge against live CLOB order-book depth' and distinguishes between single-market and basket modes with specific actions. It explicitly references sibling tools polymarket_arbitrage and polymarket_edges, positioning itself as a prerequisite risk check.

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 ('before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500') and explains why (thin book risk, partial fill directional risk). It does not provide explicit when-not-to scenarios, but the context is clear.

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

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

Annotations indicate readOnly, openWorld, idempotent, and non-destructive behavior. The description goes far beyond by detailing response fields (leg-by-leg prices, spread[], compatibility_warning, temporal_alignment, skipped counters) and explaining cases where spreads are not meaningful (non-equivalent bet shapes, temporal gaps). 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 somewhat lengthy but well-structured: purpose first, then modes, response details, and safety fields. Each section adds necessary context. Minor redundancy could be trimmed (e.g., 'pre-mapped ≠ tradeable' appears twice), but overall 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?

Given the tool's complexity (cross-venue, multiple modes, safety fields) and no output schema, the description is remarkably complete. It covers when to use, response structure, edge cases (compatibility warning, temporal alignment), and interpretation of spread values. No gaps remain.

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 each parameter. The description adds value by explaining the two-mode logic (topic vs. explicit) and listing the allowed topic values. It clarifies that explicit parameters override topic mapping, which is not obvious from 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 computes cross-venue spread between Kalshi and Polymarket for the same question, with two distinct modes. It distinguishes itself from siblings like 'polymarket_arbitrage' by focusing on cross-venue comparison. The verb 'spread' and resource description are specific and 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 explains when to use each mode (topic shortcuts vs. explicit tickers), warns that most pre-mapped topics return compatibility warnings, and advises that pre-mapped does not guarantee tradeability. It also clarifies that spreads are mathematically meaningless when temporal alignment is false.

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

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

No annotations are provided, so the description carries the full burden. It discloses that memories can be retrieved from 'earlier in the session or in previous sessions', indicating persistence across sessions. However, it doesn't mention error handling (e.g., what happens if key doesn't exist), performance characteristics, or authentication needs, leaving behavioral gaps.

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

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

The description is appropriately sized with two sentences that are front-loaded: the first sentence states the core functionality, and the second provides additional context. Every sentence earns its place by adding clear 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?

Given the tool's moderate complexity (one optional parameter) and no output schema, the description is mostly complete. It explains what the tool does, when to use it, and the parameter's effect. However, it lacks details on return format (e.g., structure of retrieved memories or list) and error cases, which could be important for an agent.

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

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

Schema description coverage is 100%, so the schema already documents the single parameter 'key'. The description adds value by explaining the semantic effect of omitting the key ('omit to list all keys') and connecting it to retrieving 'context you saved earlier', which provides context beyond the schema's technical specification.

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', 'all stored memories'). It distinguishes from siblings by mentioning 'context you saved earlier' which implies it complements 'remember' and contrasts with 'forget'.

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

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

The description provides explicit guidance on when to use this tool vs alternatives: 'Retrieve a previously stored memory by key, or list all stored memories (omit key)' gives clear conditional usage. It also mentions 'Use this to retrieve context you saved earlier in the session or in previous sessions' which distinguishes it from tools like 'get_rate' or 'convert'.

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 reveals important behaviors beyond annotations: mark_read flags events as read, affecting future calls. It also specifies return fields (source, citation_uri, raw payload) and confirms read-only, idempotent nature.

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

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

Four sentences, front-loaded with purpose. Each sentence adds value: purpose, return fields, filtering, state change, and polling/alternative access.

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 return fields, filtering, state change, and polling suitability. Lacks explicit mention of ordering (most recent) but implied by 'recent alerts'. With no output schema, the return description 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?

Description adds context for parameters, e.g., using 'sec_8k' for type and explaining mark_read effect. Schema already covers each parameter, but description provides practical examples and behavioral insights.

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 pulls fired events from the subscription feed and returns recent alerts. It specifies the verb 'pull' and resource 'fired events', distinguishing it from sibling tools like list_subscriptions which manage subscriptions.

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 notes that polls work fine and provides an alternative HTTP endpoint for scripts/dashboards. However, it does not explicitly guide when to use this tool over sibling tools or when not to use it.

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

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

Annotations declare readOnlyHint=true, destructiveHint=false, so the tool is safe. The description adds behavioral detail: parallel fan-out to multiple APIs, GDELT preferred over GNews, and soft-fail for patents due to API sunset. This goes beyond annotations, though missing limits like rate limiting or pagination.

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 key purpose and use cases. It includes necessary detail on sources and fallbacks. Slightly verbose but well-organized; each sentence adds value.

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

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

The description explains the output structure (changes[] grouped by source, total_changes count, citation URIs) despite no output schema. It covers edge cases (patent soft-fail, GDELT→GNews fallback) and ties to sibling entity_profile. Complete for a complex multi-source 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 defines 3 params with 100% description coverage. The description restates schema info (since formats, value formats) but adds minimal new meaning beyond what the schema already provides. Baseline 3 is appropriate.

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

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

The description explicitly states it provides a 'change feed for a company in the last N days/weeks/months' and lists the sources (SEC EDGAR, GDELT→GNews, USPTO). It differentiates from sibling entity_profile by contrasting static profile vs. change feed.

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 includes explicit when-not-to-use guidance: 'Use entity_profile instead when you want the static profile... regardless of window.' It also clarifies fallback behavior (GDELT→GNews, soft-fail for patents), helping the agent decide when to invoke.

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: it stores data in session memory, specifies persistence differences for authenticated vs. anonymous users (persistent vs. 24-hour lifespan), and implies it's a write operation. However, it lacks details on potential limitations like storage capacity, error conditions, or how it interacts with other memory tools.

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

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

The description is front-loaded with the core purpose in the first sentence, followed by usage context and behavioral details. Both sentences earn their place by adding essential information without redundancy, making it efficient and well-structured for quick understanding.

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

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

Given the tool's moderate complexity (a write operation with no annotations and no output schema), the description is largely complete: it covers purpose, usage, and key behavioral aspects like persistence. However, it lacks details on return values or error handling, which would be beneficial since there's no output schema, leaving a minor gap in full context.

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

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

The schema description coverage is 100%, with both parameters ('key' and 'value') well-documented in the schema. The description does not add significant meaning beyond the schema (e.g., it doesn't explain parameter constraints or usage nuances), so it meets the baseline of 3 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 specific action ('Store a key-value pair') and resource ('in your session memory'), distinguishing it from sibling tools like 'forget' (likely for deletion) and 'recall' (likely for retrieval). It specifies the purpose as saving intermediate findings, user preferences, or context across tool calls, making it distinct and 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 provides clear context on when to use this tool ('to save intermediate findings, user preferences, or context across tool calls'), but it does not explicitly state when not to use it or name alternatives (e.g., compared to 'recall' for retrieval). The guidance is helpful but lacks explicit exclusions or sibling tool comparisons.

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 read-like behavior (resolve, return) with no side effects mentioned. Adds detail on output (ticker, CIK, name, URIs) and efficiency claim. However, does not disclose authorization, rate limits, or edge cases. Adequate but not comprehensive.

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

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

Two sentences, no redundancy. Purpose and examples are front-loaded. Every sentence adds value: first defines action, second provides specifics and quantifies benefit. Efficient and clear.

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

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

Given simple schema (2 params, both documented) and no output schema, description adequately explains inputs and output. Covers return fields and replacement of multiple calls. Lacks error handling or variant cases, but for a focused tool this is 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 both parameters described. Description reinforces schema info (e.g., 'v1 supports company', 'Ticker, CIK, or company name') but adds no new parameter-specific details. Baseline 3 is appropriate since schema already covers 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?

Specific verb 'resolve' and resource 'entity to canonical IDs' clearly states purpose. Distinguishes from siblings like ask_pipeworx or convert by focusing on ID resolution. Mentions replacing multiple lookup calls, reinforcing distinct value.

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

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

Explicitly states use case: resolving entities to canonical IDs in a single call. Provides context that v1 supports only 'company' type. Implicitly suggests using it instead of 2-3 separate lookups. Lacks explicit 'when not to use' or alternatives, 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 readOnlyHint, openWorldHint, idempotentHint, and no destructiveHint. The description adds valuable behavioral context: it probes each entity with ai_visibility_check, treats the first entity as 'subject', and returns a ranked list with score, confidence, and signal density. 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?

Two sentences, front-loaded with the core action. Every sentence contributes meaning: purpose, method, use case, output. 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 4 parameters and no output schema, the description covers the tool's behavior well: it explains the probing mechanism, ranking, and output fields (score, confidence, signal density). It could be slightly more explicit about the exact return format, but overall it is complete enough for an agent.

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

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

Schema coverage is 100%, so baseline is 3. The description adds some value by noting the first entity is treated as 'subject' and mentioning models and context, but it largely restates schema info without adding significant detail.

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 specific verb+resource ('Compare AI visibility across multiple entities side-by-side') and distinguishes from sibling tools like ai_visibility_check (single entity) and compare_entities (generic comparison). It clearly explains the tool's function and use case.

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

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

The description provides explicit context for use ('competitive AI-marketing audits') and an example question. It does not explicitly state when not to use or mention alternatives, but the context is clear and the purpose is 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?

Beyond annotations (readOnly, idempotent), the description discloses the composite nature, potential delay for first measurement on new versions, and graceful degradation with partial failures. 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 a single paragraph but packs essential information efficiently. Could be slightly more structured, but every sentence adds value and it's not overly 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?

Given the tool's complexity (composite check, no output schema), the description covers purpose, behavior, limitations, error handling, and return fields (summary block, advisories, links, alternatives). Completely adequate 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?

With 100% schema coverage, baseline is 3. The description adds value by clarifying scoped package syntax and default version behavior, though schema already defines these. Minor additional 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 explicitly states the tool's purpose: a composite check for evaluating npm packages combining deps.dev and bundlephobia data. It clearly differentiates from siblings by specifying NPM-only scope and providing alternatives 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?

The description provides explicit use cases ('is X safe / popular / small' or 'what does adding lodash cost me') and clearly states when NOT to use it (non-NPM ecosystems, directing to deps.dev:version directly). Also notes graceful degradation and potential 5-30s delay for new versions.

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 safe, idempotent, non-destructive. Description adds rich detail: embedding model (BGE-base-en), search algorithm (cosine over 500-char windows), 200K char cap with truncation and flagging. 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, front-loaded purpose, then usage, then technical details. 5 sentences with no redundancy.

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

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

Explains return format (passages, offsets, scores) despite no output schema. Covers constraints and pairing. Could explicitly list return fields but sufficient for understanding.

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

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

Schema coverage is 100%. Description adds minor extra context (examples for query, cap details for text) but does not significantly enhance beyond schema descriptions. Baseline 3 is appropriate.

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

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

Clearly states 'Semantic search INSIDE a fetched record' with concrete examples (SEC 10-K, article). Distinguishes from sibling tools by mentioning pairing with ask_pipeworx_grounded.

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

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

Explicitly describes when to use: when record is too large for prompt. Mentions pairing with ask_pipeworx_grounded. Lacks explicit when-not-to-use but context is clear.

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

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

The description discloses that the tool creates a subscription (write operation), consistent with readOnlyHint=false. It explains delivery channel behaviors such as webhook HMAC signing and auto-disable after 10 consecutive failures. Idempotency is implied by annotations but not explicitly stated; however, the description does not contradict annotations.

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

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

The description is well-structured with clear separation between subscription types and delivery channels, and front-loads the core purpose. It is somewhat lengthy but every sentence adds value; minor trimming could improve conciseness.

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

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

The description covers prerequisites, subscription types with parameter examples, delivery channels, return value (subscription id), and limitations (SMS cap, phone verification). No output schema exists, but the return value is adequately specified. The tool is complex, but the description provides complete context.

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

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

With 100% schema coverage, the description adds significant meaning beyond the schema by providing concrete examples for each subscription type (e.g., sec_8k items codes, polymarket_edge topics) and detailing delivery channel options including webhook HMAC signing. This fully compensates for the schema's generic 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 that the tool creates a proactive monitoring subscription to a live-data event stream and returns the new subscription id. It distinguishes itself from sibling tools like list_subscriptions, unsubscribe, and recent_alerts by specifying the creation aspect and the stream nature.

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 the requirement for a Pipeworx OAuth account, lists supported subscription types with example parameters, and describes delivery channels with limitations (e.g., SMS 10/day cap). While it does not explicitly state when not to use this tool compared to alternatives, the context is sufficient for an agent to decide.

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 behavioral context beyond annotations, such as that it returns 'category-bucketed example questions' drawn from a live catalog, and that it serves as an onboarding tool. It does not contradict annotations; it complements them with specific output details.

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 information-dense but front-loaded with alternative phrasings. Every sentence adds value: it explains purpose, output, usage, and parameter. Slightly longer than necessary but well-structured and easy to parse.

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

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

Given the tool has one optional parameter and no output schema, the description provides all necessary context. It explains the output format (category-bucketed example questions with exact tool+argument shape) and the parameter behavior. No additional information is needed for the 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 coverage is 100% with one optional parameter described in the schema. The description reiterates the schema information: 'Call with no arguments for the full spread, or pass topic to focus.' It adds no new semantic meaning beyond what is already in the schema, so score is at baseline 3.

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

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

The description clearly defines the tool as the onboarding entry point for a new agent. It lists alternative phrasings that users might ask, states it returns category-bucketed example questions with exact tool+argument shape, and explicitly distinguishes it from siblings like ask_pipeworx and discover_tools by saying 'Use this FIRST when you do not yet know what Pipeworx can do for you, or to learn how to call the meta-tools.'

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

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

The description explicitly states when to use the tool: when the agent just connected and wants to know what is worth asking. It gives clear usage instructions: call with no arguments for full spread, or pass a topic to focus. It also advises to use this first before other meta-tools, providing good guidance on when to use versus 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 mutation (readOnlyHint=false), non-destructive (destructiveHint=false), and idempotent. Description adds value by specifying ownership enforcement and deactivation behavior, complementing 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?

Three short sentences, no redundancy, front-loaded with key action. Highly efficient.

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

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

For a single-parameter tool with annotations and no output schema, description fully covers purpose, constraints, side effects, and cross-reference to recent_alerts.

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; description mentions 'id' and its source ('returned by subscribe'), adding minimal extra context. Baseline 3 is appropriate.

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

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

Description clearly states 'Cancel a subscription by id.' Verb 'cancel' and resource 'subscription' are specific. Distinguishes from siblings like 'subscribe' and 'list_subscriptions'.

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

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

Explains ownership enforcement and that cancellation deactivates rather than deletes. Implicitly guides when to use (to cancel own subscription). No explicit exclusion of alternatives, but context is clear.

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

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

Beyond annotations (readOnly, openWorld, idempotent, non-destructive), the description adds details: supported claim types, data source (SEC EDGAR + XBRL), return values (verdicts, structured form, citation, delta), and process efficiency. Rich 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 moderately lengthy but efficiently structured, front-loaded with trigger phrases and each sentence adding value. 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 no output schema, the description fully enumerates return types (verdict, structure, value, citation, delta) and clarifies scope and data source. Complete for a single-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 coverage is 100% with a well-described 'claim' parameter. The description supplements with examples and underlying process, adding 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 that the tool performs natural-language claim verification against authoritative sources, with specific trigger phrases and domain (company-financial claims). It distinguishes itself from siblings by replacing multiple sequential calls.

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

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

The description explicitly says to use whenever checking factual correctness, and mentions what it replaces. However, it does not provide when-not-to-use or list alternatives, though context is clear.

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