Wordnik

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

Annotations already provide readOnlyHint, idempotentHint, destructiveHint. Description adds return structure (per-model {score, confidence, signals, raw_response}) and notes that Anthropic probing requires BYO key with direct payment. No contradictions.

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

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

Three sentences: (1) core function, (2) model options and key requirements, (3) output summary and use cases. Front-loaded, every sentence essential, 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?

Tool has 4 params, no output schema, no enums. Description covers return format and use cases adequately. Could mention potential cost implications for Anthropic calls, but not required. Overall complete for agent use.

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

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

Schema coverage is 100%. Description adds explanatory details: entity examples ('Pipeworx'), models supported with default, _apiKey purpose ('passed straight through to api.anthropic.com'), and context for disambiguation. Adds value beyond schema.

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

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

Description clearly states the verb 'Probe one or more LLMs... and score visibility' with specific scope (business/brand/product/topic). Distinguishes from sibling tools like 'ask_pipeworx' and 'scan_competitor_ai_presence' by focusing on multi-model visibility scoring.

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

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

Explicitly lists use cases: 'AI-marketing audits, pre-launch brand checks, competitive monitoring.' No direct comparison to siblings or when-not-to-use, but context is clear enough.

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

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

Annotations already establish read-only/idempotent/non-destructive behavior. The description adds valuable context about how it routes to subtools, returns citation URIs, and works across tiers. It does not go into potential failure modes or rate limits, but with annotations covering the safety profile, this is sufficient.

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

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

The description is front-loaded with the most important instruction ('PREFER OVER WEB SEARCH') and is organized with clear examples and alternatives. It is somewhat long but every sentence contributes to guiding tool selection and invocation. Minor repetition of the over-web-search message prevents a 5.

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 still conveys the return format (structured answer with pipeworx:// citation URIs). It provides enough context for an agent to decide when to use this tool, what inputs to provide, and how it differs from alternatives. It is complete for a tool of this complexity.

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

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

Schema coverage is 100% with all parameters documented as aliases for 'question'. The description itself does not add parameter-level details, but the schema fully explains each field. Baseline 3 is appropriate since the schema does the heavy lifting and examples are provided.

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's purpose: answering questions about current/historical data drawn from authoritative sources, routing to 5,529 tools, and returning structured answers with citations. It distinguishes from siblings by explicitly naming ask_pipeworx_grounded and deep_research as alternatives for specific use cases.

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

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

Provides explicit guidance on when to use this tool over web search or other tools: 'PREFER OVER WEB SEARCH', 'START HERE for most questions', and 'Step up only when needed' for ask_pipeworx_grounded or deep_research. It also covers breaking news routing. This is exemplary usage differentiation.

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

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

Adds substantial context beyond annotations: no candidate is currently active, it currently matches ask_pipeworx exactly, candidate routing improvements are enabled live during tests, and it falls back to nothing (is a full working router). This richly supplements the readOnly/idempotent hints.

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 uses four sentences, each with a clear purpose: identity, current state, usage recommendation, and clarification of fallback behavior. It is slightly verbose given the beta status details, but every sentence earns its place.

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

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

Fully explains the dynamic beta state, current equivalence to the stable router, and how results are used for merging, which is essential for an experimental tool. Despite no output schema, it references the exact response shape of ask_pipeworx, making the behavior predictable.

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

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

Input schema already covers all six parameters with descriptions for question and each alias (100% coverage). The description only mentions 'same arguments' without adding new parameter details, so it meets the baseline but provides little 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 identifies the tool as a beta version of ask_pipeworx, a universal router with the same tools, arguments, and response shape. It distinguishes from the sibling ask_pipeworx by emphasizing candidate routing improvements and its experimental 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?

Explicitly instructs to 'Use it exactly like ask_pipeworx when you want the newest routing' and notes results are compared against the stable router. It could more directly state when not to use it (e.g., for stable production needs), but the guidance 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 (readOnlyHint, openWorldHint, idempotentHint), the description discloses critical behavioral traits: return format with verbatim evidence, refusal reasons ('not_in_source', 'no_tool_match', etc.), and the extra LLM call cost. It clarifies that the tool may refuse to answer if data does not directly support the answer, adding depth beyond the annotations. 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 dense but well-structured: purpose, mechanism, return format, usage, and trade-off. Each sentence carries unique value. It is a single paragraph but front-loaded with the core purpose. Slightly long due to detailed return/refusal explanation, but all necessary.

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

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

For a tool with no output schema, the description fully explains the return payload and failure modes. It covers what the tool does, how it differs from the sibling, when to use it, and its limitations. The context is complete for an agent to select and invoke 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?

The input schema has 100% description coverage for all six parameters, all documented as aliases for 'question'. The description does not add any additional meaning beyond the schema, such as formatting or syntax examples. With full schema coverage, the 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?

The description states a specific verb and resource: 'Hallucination-resistant answer mode' for high-stakes reads. It clearly explains the tool's distinctive behavior: routing, fetching, and extracting the answer from tool results only, with refusal if unsupported. It differentiates from the sibling ask_pipeworx by highlighting the extraction and evidence-grounded 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?

Provides explicit usage guidance: 'Use whenever an answer will be quoted, cited, or acted on...' and lists example high-stakes domains. It also gives an explicit alternative: 'prefer ask_pipeworx for casual lookups' and a cost rationale. This clearly signals when to choose this tool over its sibling.

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, idempotentHint=true, destructiveHint=false. Description adds detailed behavioral context: resolution process, fan-out, response shapes, safety measures (low-confidence short-circuit, closed markets), edge cases (wide spreads, cancellation rules), and caveats to inspect market_match_confidence. 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?

The description is very long (over 300 words) but well-structured with sections, examples, and clear headings. It is front-loaded with core purpose. Given complexity, length is justified, though it 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?

No output schema exists, so description fully explains return values: result.market, analysis, evidence, market_match_confidence, parent_event, news fields, etc. Covers safety, edge cases, resolution rules, and blockers. Complete for a complex research 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%. Description adds significant meaning beyond schema: explains market accepts slug/URL/question text, depth enum (quick vs thorough), include_raw (when to use). This provides functional context the schema alone lacks.

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: 'Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call.' It provides specific verb+resource and distinguishes from siblings like polymarket_arbitrage by focusing on research rather than edge/arbitrage.

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

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

Explicitly says 'Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z".' It gives classifiers and fan-out examples. However, it does not explicitly state when NOT to use this tool vs alternatives, missing a clear exclusion.

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

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

The description adds details beyond annotations: data sources (SEC EDGAR/XBRL for companies, FAERS for drugs), handling of fiscal-year differences, sorting behavior, and return of citation URIs. Annotations already indicate readOnly/openWorld/idempotent, and description aligns.

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 slightly verbose. Every sentence adds value, and the most critical information (purpose, usage, data sources) is front-loaded. Minor redundancy could be trimmed.

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

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

Covers all necessary aspects: entity types, data sources, number of entries, sorting, return format. No output schema exists, but the description sufficiently describes what is returned (paired data + citation URIs).

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

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

Schema coverage is 100%, and the description adds valuable context: for type 'company' it specifies tickers/CIKs, for 'drug' it gives drug names, and explains the values array constraints (2–5 items). This helps the agent format parameters correctly.

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 side-by-side comparisons of 2–5 companies or drugs, with specific example phrases. It distinguishes itself from sequential lookups by noting it replaces 8–15 single 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?

Explicitly states 'ALWAYS PREFER over sequential single-pack lookups' and provides example user queries. It gives clear guidance on when to use this tool over siblings like entity_profile or search.

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

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

The description adds substantial behavioral context beyond the annotations: latency expectations (15-60s, up to ~90s for thorough), the gaps[] and contradictions[] fields, the 'never invented' policy, citation_uri fetchability, and semantic excerpting. No statement contradicts the readOnly/openWorld/idempotent/non-destructive 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 dense paragraph with no formatting, and it partially repeats depth semantics already covered in the schema. It opens with account requirements rather than the core purpose, delaying front-loading. However, each sentence contains unique operational detail, so it is not filler.

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

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

Since there is no output schema, the description fully covers the return findings packet, citation_uri behavior, gaps[], contradictions[], latency, auth requirements, and alternative-tool routing. This gives the agent a complete picture of the tool's behavior and output.

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 baseline is 3, but the description adds extra semantics by noting that depth:'thorough' requires a paid plan and by elaborating on the hop behavior and latency tied to each depth level. The question parameter's decomposition behavior is also clarified beyond the schema's single sentence.

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 'Grounded multi-source research across Pipeworx's 1455 STRUCTURED data sources' and explicitly contrasts it with 'NOT open-web search'. It also differentiates from siblings by naming ask_pipeworx for single lookups and news, so the agent knows what this tool uniquely offers.

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 gives explicit when-to-use guidance: 'Best for broad/multi-part questions over structured data', and when-not-to-use: 'For a single lookup use ask_pipeworx' and 'For BREAKING or colloquial CURRENT-NEWS... prefer ask_pipeworx'. It also states the prerequisite (account required) and the paid depth tier, providing clear operational boundaries.

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

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

The description adds context beyond annotations by specifying the source (Wordnik) and the return structure ('definitions with source, text, and part of speech'). Annotations already indicate read-only and non-destructive behavior, so no contradiction.

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

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

The description is concise with two sentences. The first sentence delivers the core action and filters, and the second clarifies the return format. Every part is necessary and front-loaded.

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

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

Given the presence of an output schema, the description does not need to detail return values. It covers the essential purpose and key filters. However, with 7 parameters and only 3 mentioned, some completeness is lost, but the tool's overall usage is still clear.

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 only covers 3 out of 7 parameters (partOfSpeech, sourceDictionaries, limit), leaving includeTags, useCanonical, includeRelated, and the context of the 'word' parameter unaddressed. With 0% schema description coverage, the description should provide more parameter meaning but falls short.

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

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

The description clearly states the action ('Fetch dictionary definitions for a word'), the data source ('from Wordnik'), and the resource ('definitions'). It also distinguishes this tool from sibling tools like 'related', 'phrases', and 'pronunciations' which handle other word data.

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

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

The description mentions filtering capabilities ('by part of speech, source dictionary, and limit') which implies when to use this tool for specific needs. However, it does not explicitly state when not to use it or compare it to alternatives like 'top_example' or 'related'.

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, idempotentHint, and destructiveHint. The description adds valuable behavioral context: it returns 'top-N most relevant tools with names, descriptions, and full input schemas (with curated examples) — each result is ready to call directly, no second schema lookup needed.' This goes beyond annotations.

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

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

The description is concise yet comprehensive. It front-loads the tool's purpose, then provides usage guidance, and finally details what the tool returns. Every sentence adds value and is 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?

The description fully explains the tool's behavior and output despite no output schema. It covers the return format, the fact that results are callable directly, and the purpose of the tool. Combined with rich annotations, the description is 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?

Input schema covers 100% of parameters with descriptions. The description adds context by explaining that the query parameter is a 'natural language description' and provides examples, reinforcing usage semantics beyond the schema definitions.

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

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

The description clearly states the tool's purpose: 'Find tools by describing the data or task.' It uses a specific verb ('discover') and resource ('tools'), and distinguishes itself from sibling tools by focusing on exploration of available tools, not direct data access.

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 advises to 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' This provides clear context for when to use the tool, though it does not explicitly state when not to use alternatives.

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

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

Annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false) are consistent. Description adds specifics: fanned sources, return fields (cik, filings, fundamentals, etc.), patents soft-fail, ticker/CIK requirement. 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?

The description is front-loaded with example queries, which is good. While it is lengthy, every sentence serves a purpose. Could be slightly more concise, but remains efficient.

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

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

Given the complexity and lack of output schema, the description adequately covers return fields, data sources, and limitations. Provides enough detail for the agent to understand output and behavior.

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

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

Schema coverage is 100% and description adds meaning beyond enum labels: type is 'company' only, value is ticker or CIK, names not supported. Includes concrete examples. Good context beyond schema.

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

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

The description clearly states the tool returns a full cross-source profile of a US public company, with example queries and a list of data sources. It distinguishes from sibling tools like 'compare_entities' and 'resolve_entity' by specifying that names are not supported.

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 guidance: 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view.' Also states when not to use (names) and directs to 'resolve_entity' as alternative. Limitations like patent API sunset are noted.

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 no behavioral context beyond the annotations.

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

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

The description is only two words, which is under-specification rather than efficient conciseness. It fails to convey essential information.

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

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

With 5 parameters and 0% schema coverage, the description is severely incomplete. Even though an output schema exists, the tool's purpose and parameter meanings are not explained.

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

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

Schema description coverage is 0%, and the description does not explain any of the 5 parameters (word, skip, limit, useCanonical, includeDuplicates). No value added.

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 says 'Usage examples' but doesn't specify what the examples are for. From the input schema, it appears to retrieve examples for a word, but this is not stated. Purpose is vague.

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

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

No usage guidance provided. Does not indicate when to use this word example tool vs siblings like definitions, phrases, or pronunciations.

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 annotations already indicate destructiveHint=true and idempotentHint=true, and the description's 'Delete' matches. It adds context about clearing sensitive data. However, it could further clarify permanence or prerequisites, but it is adequate for a simple 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 concise: two sentences and a short phrase. It front-loads the action, and every sentence adds value without redundancy or 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?

For a simple tool with one parameter and no output schema, the description covers the purpose, usage guidelines, and pairing with siblings. It provides sufficient context for correct invocation.

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

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

The input schema has 100% coverage, describing the 'key' parameter as 'Memory key to delete.' The description only repeats 'by key,' adding no new meaning beyond the schema. Baseline score applies.

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

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

The description clearly states 'Delete a previously stored memory by key,' which is a specific verb ('Delete') and resource ('memory'). It distinguishes the tool from siblings like 'remember' (store) and 'recall' (retrieve), making its purpose unambiguous.

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

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

The description explicitly says when to use: 'when context is stale, the task is done, or you want to clear sensitive data.' It also instructs to 'Pair with remember and recall,' providing clear usage and alternatives.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. Description adds source 'from Wordnik' and the specific output structure (year-by-year counts), which aligns with annotations and provides useful context beyond structured data.

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

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

Single sentence, highly efficient, front-loaded with the core action and resource. No superfluous words.

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

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

Given the presence of an output schema, the description does not need to detail return values. It adequately covers the main purpose and optional parameters. However, it could hint at the range of years or data source limitations.

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

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

With 0% schema description coverage, description must compensate. It clarifies 'word' as the query term and the optional 'startYear–endYear' range, but does not explain the 'useCanonical' boolean parameter, leaving it ambiguous.

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?

Clear action verb 'Return' with specific resource 'year-by-year corpus frequency counts' from Wordnik. Uniquely distinguishes from siblings like definitions or pronunciations.

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

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

Describes optional year range constraint but lacks explicit guidance on when to use or avoid this tool versus alternatives. No mention of prerequisites or preferred 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?

Annotations already indicate read-only, idempotent, non-destructive. The description adds that the tool fetches the page, extracts title/description/key links, and emits standard markdown, which explains the process beyond the annotations.

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

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

The description is concise with two sentences plus a use-case list, front-loaded with the primary action and output. 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?

The description adequately explains the output format (single text blob, standard llms.txt markdown) and usage context. No output schema exists but the description compensates clearly.

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 parameters are fully defined. The description adds minor context (e.g., 'ready to drop at site-root/llms.txt') but does not significantly extend schema meaning.

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

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

The description clearly states the tool generates an llms.txt file for any URL, with specific details on what it does (fetch, extract, emit standard format). It distinguishes itself from siblings by focusing on a unique, well-defined output format.

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

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

The description lists concrete use cases (indexing client sites, drafting for own projects, auditing competitors) but does not explicitly state when not to use it or compare to siblings like 'scan_competitor_ai_presence'. Still provides actionable guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds that the data comes from Wordnik's endpoint, but no additional behavioral traits (e.g., error conditions, rate limits) are disclosed.

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?

A single sentence that is front-loaded with the verb 'Return', contains no wasted words, and efficiently conveys the tool's 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?

The description adequately covers the core functionality and leverages the existing output schema. However, it does not describe optional parameters, leaving gaps in completeness for users needing to customize the request.

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

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

With 0% schema description coverage, the description should compensate but only mentions 'a word', adding no meaning beyond the schema. Parameters like limit, useCanonical, and sourceDictionary are left unexplained, providing minimal value.

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

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

The description clearly states the tool returns 'hyphenation breakpoints and syllable stress for a word' from a specific source (Wordnik's hyphenation endpoint). It distinguishes itself from siblings like 'definitions' or 'pronunciations' by specifying the exact linguistic data returned.

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

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

The description implies usage for obtaining hyphenation data, but it does not explicitly mention when to use this tool over alternatives like 'definitions' or 'pronunciations'. No when-not or exclusion criteria are 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the description doesn't need to restate safety. It adds value by specifying the return structure (id, type, params, created_at, last_fired_at, fire_count) and the default behavior of listing only active subscriptions. It does not mention pagination or caching, but given the tool's simplicity, this is sufficient.

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

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

The description is two sentences: the first states the action and return fields, the second provides usage guidance. Every sentence is informative and earns its place. It is front-loaded with the core purpose and avoids any fluff.

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

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

Given the tool's low complexity (one optional parameter, no output schema) and the richness of the annotations, the description is complete. It explains what the tool does, what it returns, and when to use it. No critical information is missing for an agent to select and invoke it 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 the baseline is 3. The description does not explicitly mention the include_inactive parameter, but it implies the default behavior by saying 'active subscriptions.' This adds minimal meaning beyond the schema's description of the parameter. No further compensation needed.

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 'List the caller's active subscriptions,' specifying the verb (list), resource (subscriptions), and scope (caller's active). It also enumerates the returned fields, leaving no ambiguity about what the tool does. This distinguishes it from sibling tools like subscribe and unsubscribe.

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 advises when to use the tool: 'Use this to review what you're monitoring before adding more or to find an id to cancel.' This gives clear context for usage and implicitly directs the agent away from using it for other purposes, referencing sibling actions (adding more = subscribe, cancel = unsubscribe).

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 accurately states the tool's read-only, idempotent nature (already indicated by annotations) and adds context about the WLMi parameter and use of Wordnik's corpus. No contradictions with annotations.

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

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

The description is a single, front-loaded sentence of 18 words. Every word adds value, and there is no redundancy. It efficiently conveys the core functionality and a key parameter detail.

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

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

Given the tool's moderate complexity (4 parameters) and the existence of an output schema, the description covers the core purpose but omits details for parameters 'limit' and 'useCanonical'. It is minimally adequate but not 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 description coverage is 0%, so the description must compensate. Only the wlmi parameter is explained. The required 'word' parameter is obvious, but 'limit' and 'useCanonical' are not described, leaving significant gaps.

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

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

The description clearly states the tool returns common bigram phrases containing a word from Wordnik's corpus, with a specific verb and resource. It distinguishes itself from sibling tools like 'definitions' or 'examples' by focusing on bigram phrases.

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 lacks explicit guidance on when to use this tool versus alternatives. No context is provided about prerequisites or when not to use it. The sibling list includes many related tools, but no differentiation is made.

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?

All annotation hints are false, so the description carries the full behavioral burden. It discloses important traits: anonymous filing returns a claim_token, how to later use that token to read status, rate limits (5 per identifier per day), that it is free, and that the team reads digests daily. This goes well beyond the structured 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 longer than average, but every sentence adds distinct value: purpose, when-to-use, exclusions, formatting tips, claim_token mechanics, rate limits, and cost. It is front-loaded with the primary purpose and structured logically from what to do to how to do it, without irrelevant content.

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

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

With no output schema, the description must explain return behavior, and it does: it promises a claim_token on anonymous filing and explains how to use it to retrieve resolution status. Combined with rate limits, usage exclusions, and parameter guidance, the tool is fully understandable 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?

Although the schema already has 100% coverage, the description adds significant meaning: it tells users to describe issues in terms of Pipeworx tools/packs, not to paste end-user prompts, and it explains the claim_token flow in detail. This materially helps the agent understand how to fill fields correctly.

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 opens with a clear, specific action: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It explicitly names the resource (Pipeworx team) and the distinct purposes (bug, feature/data_gap, praise), fully distinguishing it from sibling tools like ask_pipeworx or discover_tools.

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

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

The description provides explicit when-to-use guidance: bug, feature/data_gap, praise, and even 'other' via the schema. It states a clear when-not-to-use condition (if the tool is from a different MCP server) and names the alternative (file with that server instead). This is exemplary 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?

Adds significant context beyond annotations: self-aggregating signal, derived from CF analytics-engine, no PII, caching behavior (5min-1h), and window interpretation. No contradictions with readOnlyHint, openWorldHint, etc.

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

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

Well-structured with bullet points for use cases, clear sentences, no redundant information. Front-loads purpose and provides efficient context.

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?

Complete for a read-only, parameter-light tool. Covers purpose, usage, behavioral traits, and parameter semantics. Annotations and description together provide 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?

Schema already describes window parameter with enum and default. Description adds value by explaining shorter vs longer windows surface hot vs steady-state demand, aiding agent decision.

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

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

Description clearly states what the tool returns (top tools, top packs, total call volume) over a specified window. The verb 'returns' and resource 'trending data' are explicit, and the scope is distinct from siblings like 'frequency' or 'search'.

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

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

Provides three specific use cases (discovering hot data sources, confirming canonical tool, alignment check) and guidance on window selection. Missing explicit when-not-to-use or direct alternatives, but the use cases are actionable.

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

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

The description adds significant behavior beyond annotations: explains partition filter, semantic anchor, fill check, and what fields the response contains. The annotations (readOnlyHint, openWorldHint, idempotentHint) are consistent and the description enhances understanding.

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

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

The description is fairly long but well-structured with sections for each mode, semantic anchor, partition filter, and fill check. While dense, every sentence serves a purpose, though 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?

Despite no output schema, the description explains the response format (opportunities array with fields) and covers edge cases like placeholder slugs and similarity thresholds. It provides sufficient detail for correct usage.

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

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

Both parameters are fully described in the schema, but the description adds examples (event slugs, topic questions), clarifies accepted formats (URLs accepted for event), and explains behavior (topic searches related events). This adds meaningful value 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 via monotonicity violations and partition-sum checks. It distinguishes between two modes (event and topic) and provides specific examples. The purpose is well-defined 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?

The description explicitly tells when to use each mode: no arguments for trending scan, 'event' for a specific market, 'topic' for cross-event scanning. It also warns against trading when realizable edge is <=0 and suggests polymarket_fill_risk for custom sizing.

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, openWorldHint, idempotentHint, destructiveHint. The description adds extensive behavioral context: caching at KV level keyed on knobs, model families, response structure with diagnostics, and filter details like placeholder-slug drops. 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 very long (over 300 words) and densely packed with technical details. While well-structured and front-loaded with purpose, it lacks conciseness; every sentence earns its place but the length may overwhelm an agent.

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

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

Given the tool's complexity (9 parameters, no output schema, nested response fields), the description covers response structure (by_segment, fed_candidates, diagnostics), model families, edge cases (placeholder filters), and caching. It is exceptionally complete.

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

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

Schema coverage is 100%, baseline 3. The description adds significant value beyond schema, e.g., for min_kelly it explains why to use it, for slippage_pp it gives practical adjustment advice, and each parameter includes context that aids agent decision-making.

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

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

The description clearly states the tool scans Polymarket for opportunities where Pipeworx data disagrees with market price. It distinguishes itself from siblings like polymarket_arbitrage and polymarket_edge_tracker by focusing on discovery without paging hundreds of markets.

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

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

The description explicitly positions the tool for 'what should I bet on today' and mentions that Fed bets are excluded from ranking with a note. However, it doesn't explicitly compare to alternatives or state when not to use it, though sibling tools exist.

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 read-only, open-world, idempotent, and non-destructive behavior. The description adds extensive behavioral details: response structure (tracked, expired, snapshot_dates), data limits (60-day TTL), decay computation method, and handling of gaps. No contradictions with annotations.

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

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

The description is front-loaded with the core purpose and is comprehensive, but somewhat lengthy. However, every sentence provides valuable information for a complex tool, justifying the length.

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

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

Despite lacking an output schema, the description completely covers the response format (tracked, expired, snapshot_dates), behavior details (decay computation, gaps, limits), and all relevant context for proper usage.

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

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

Schema coverage is 100% with clear descriptions for both parameters (days, window). The description only reiterates default values and does not add significant semantic meaning beyond the schema. 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 defines the tool's purpose: providing edge persistence and decay telemetry from daily snapshots, answering specific questions about edge duration and shrinkage. It distinguishes itself from the sibling tool 'polymarket_edges' by focusing on time-series analysis rather than raw snapshot data.

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

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

The description explains when to use the tool (to know how long an edge has existed and if it is shrinking) and provides context, but does not explicitly state when not to use it or list alternative tools. The differentiation from polymarket_edges is implied.

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 detailed behavioral traits beyond annotations: it walks the order book ladder, returns specific fields like top_of_book, vwap_fill_price, slippage_pp, and verdict. It also highlights the risk of partial basket fills leading to unhedged directional positions, which is critical for understanding tool behavior. Annotations already indicate safe, idempotent, read-only nature, and description adds significant 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 relatively long but well-structured: it begins with a concise purpose statement, then uses case formatting (REQUIRES, SINGLE-MARKET, BASKET) to organize content. It is front-loaded with core information and avoids unnecessary fluff. Every sentence adds value given the tool's 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?

Despite lacking an output schema, the description exhaustively lists return fields for both modes (e.g., top_of_book, vwap_fill_price, slippage_pp, verdict for single-market; theoretical_sum, realizable_sum, capture_ratio, profit_usd, per-leg detail, thin_legs, forced_directional_risk for basket). This makes the tool's behavior fully understandable without needing an output schema.

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

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

With 100% schema coverage, the baseline is 3. The description adds practical meaning: it clarifies the requirement for either `market` or `event`, explains default `side` in basket mode, and elaborates on `size_usd` as settlement notional for baskets. This goes beyond schema descriptions, but some parameter details are already 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 tool's purpose as a 'Realizable-vs-theoretical edge check against live CLOB order-book depth' and distinguishes between single-market and basket modes. It also explicitly positions itself as a prerequisite before using sibling tools like polymarket_arbitrage, effectively differentiating from them.

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 usage guidance, stating 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500'. It also warns about risks like partial basket fills converting arb into unhedged positions. However, it does not explicitly mention when not to use the tool or alternatives, but the guidance is clear and actionable.

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 well beyond annotations by detailing compatibility warnings, temporal alignment, skipped cross-types, and the rarity of real spreads. Annotations indicate readOnlyHint, openWorldHint, idempotentHint, and non-destructive, which are consistent and enhanced by the 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 relatively long but well-structured with sections for modes, response, and safety fields. Every sentence adds value, though slight pruning 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?

Despite no output schema, the description thoroughly explains the response structure (leg-by-leg prices, top_spreads_pp), safety fields, and temporal alignment. It covers all necessary context 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?

The input schema has 100% description coverage, and the description adds value by explaining the interaction between parameters (e.g., topic overridden by explicit tickers) and providing example values. This enhances understanding beyond the schema alone.

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

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

The description clearly states the tool computes cross-venue spread between Kalshi and Polymarket for the same resolving question. It distinguishes from siblings by specifying the exact focus on two prediction markets and their spread. The verb 'spread' and resource specification are precise.

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

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

The description explains two modes (topic shortcuts and explicit tickers) and provides guidance on when spreads are meaningful versus when compatibility warnings fire. However, it does not explicitly compare to sibling tools like polymarket_arbitrage, leaving some ambiguity about when to use this tool over alternatives.

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

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

Annotations already provide readOnlyHint, idempotentHint, and non-destructive hints. The description adds value by specifying return types (IPA, ahd) and filtering capability. It does not contradict annotations and provides additional 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 a single, front-loaded sentence with no wasted words. It efficiently conveys the core purpose and optional filtering.

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 5 parameters (1 required) and an output schema, the description covers the main behavior and filtering options. It does not need to detail return values due to the output schema. Adequate for the complexity.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions filtering by source dictionary and format type, hinting at 'sourceDictionary' and 'typeFormat' parameters, but does not explain 'limit', 'useCanonical', or the exact values. This adds some meaning but is incomplete.

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 returns pronunciation strings for a word from Wordnik, with filtering by source dictionary and format type. It uses a specific verb ('return') and resource ('pronunciation strings'), distinguishing it from siblings like 'definitions' or 'hyphenation'.

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

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

The description implies when to use (when needing pronunciations) but does not explicitly contrast with alternatives like 'definitions' or 'hyphenation'. However, the purpose is clear enough for an agent to infer usage context.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. Description adds source (Wordnik) and filter options but does not disclose additional behavioral traits like rate limits, error handling, or return format. Acceptable given annotation coverage.

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

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

Single sentence with clear structure. Front-loaded with verb and resource, then filters. No redundant or unnecessary words.

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

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

Description is brief but covers core purpose and filters. However, it does not explain return values (output schema exists but not described), behavior when no word matches filters, or usage of optional params. Adequate for simple tool but lacks depth for 7 param 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 description coverage is 0%, so description must compensate. It mentions 'part of speech' (which maps to two params) and length/corpus count but omits hasDictionaryDef, minDictionaryCount, and full detail on part-of-speech params. Partial coverage leaves some parameters unexplained.

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 'Return a single random word from Wordnik' (verb+resource+source) and lists filtering capabilities. It distinguishes from sibling tools like 'random_words' (plural) and 'word_of_the_day' by specifying 'single' random word.

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 obtaining a random word with filters but does not explicitly state when to use vs alternatives like 'random_words' or other word-related tools. No exclusions or when-not guidance 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering safety. The description adds context about filtering but does not disclose whether results are truly random or deterministic (potentially conflicting with idempotentHint).

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

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

The description is a single, well-structured sentence that front-loads the main action and immediately conveys the tool's purpose and key parameters without extraneous details.

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 8 parameters, no required fields, and an output schema, the description covers the main filtering dimensions. It does not mention pagination or defaults, but the output schema likely explains the return format, making the description fairly 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?

With 0% schema description coverage, the description adds meaning by naming filter categories (part of speech, min/max length, corpus/dictionary counts). It does not explicitly mention 'hasDictionaryDef', but the overview is helpful for an agent.

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

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

The description clearly states the verb 'Return' and the resource 'random words from Wordnik', distinguishing it from siblings like 'random_word' (likely singular) by specifying multiple words and filters.

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 use when needing random words with specific constraints, but it lacks explicit guidance on when to avoid this tool or compare to alternatives like 'definitions' or 'random_word'.

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

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

Annotations already provide readOnlyHint, idempotentHint. Description adds scoping by identifier and behavior when key is omitted. 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?

Four sentences, front-loaded with purpose, then usage context, scoping, and companion tools. No redundant information.

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

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

Given one optional param, no output schema, and strong annotations, the description is complete: it explains purpose, when to use, parameter behavior, scoping, and related tools.

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

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

Schema coverage is 100%, baseline 3. Description adds meaning by explaining that omitting the key lists all keys, and that the key retrieves a stored value, going beyond the schema's brief description.

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

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

The description clearly states the tool retrieves a value via 'remember' or lists all keys if omitted. It uses specific verbs ('retrieve', 'list') and distinguishes from sibling tools 'remember' and '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?

Explicitly says to use it for looking up context without re-deriving, and pairs with remember/forget. No explicit alternatives, but context is clear for this retrieval tool.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds useful behavioral details such as the structure of returned events, the mark_read effect, and the existence of an alternative HTTP endpoint. 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 moderately long but front-loaded with the main action. Each sentence serves a purpose, though some details (like the HTTP endpoint) could be secondary. Overall well-structured.

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

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

Given 5 optional parameters, no output schema, and moderate complexity, the description covers purpose, parameter usage, and behavioral traits adequately. Mentions of the feed URL add extra context. Adequate for an agent to use effectively.

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

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

Schema coverage is 100%, so baseline is 3. The description adds examples for type and since, and clarifies mark_read behavior. This adds some value but does not significantly supplement 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 the tool pulls fired events from a subscription feed, and specifies what each event carries. It is specific about the resource and action, but does not explicitly distinguish from sibling tools like search or list_subscriptions, though the uniqueness is implied.

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 guidance on filtering and marking reads, and mentions polling is fine. However, it lacks explicit when-to-use or when-not-to-use guidance compared to alternatives, leaving the agent to infer 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?

Beyond the annotations (readOnlyHint, idempotentHint), the description details parallel fan-out, fallback behavior (GDELT→GNews on rate limits/5xx), USPTO soft-fail, return structure, and that it makes a single parallel call. This adds significant 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 well-structured and front-loaded with purpose and examples. However, it is slightly verbose with multiple example queries and detailed source descriptions. Still, 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?

The description covers all aspects: functionality, usage, parameters, sources, fallbacks, return structure, and mentions limitations (USPTO sunset). No output schema exists, so the description adequately explains what is returned.

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

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

Schema coverage is 100%, and the description adds value by explaining `since` accepts ISO and relative formats, recommends '30d' or '1m', and notes `value` can be ticker or CIK. It also clarifies the `type` enum is only 'company'.

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

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

The description clearly states the tool provides a change feed for a company in a time window, with specific data sources (SEC, GDELT/GNews, USPTO). It distinguishes from the sibling entity_profile by noting that tool is for static profiles regardless of window.

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 guidance is given: use for 'latest on Y' queries, and when not to use (for static profiles, use entity_profile). Example queries illustrate typical 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?

Annotations already provide readOnlyHint=true and idempotentHint=true. The description adds that it uses Wordnik's relatedWords endpoint, giving source transparency. No contradictions, and no additional behavioral traits needed beyond annotations and source.

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

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

Single sentence, concise and front-loaded. Could briefly mention optional parameters, but remains efficient.

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

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

Given output schema exists, return values need not be explained. The description covers purpose and source adequately for a simple query tool. Could address edge cases like empty results, but not critically missing.

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 0%. Description explains 'word' and 'relationshipTypes' (listing example values), but does not mention 'useCanonical' or 'limitPerRelationshipType'. This leaves half the parameters without any extra meaning beyond their names.

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 returns related words for a given word, naming relationship types like synonym, antonym. It distinguishes from sibling tools like definitions or examples by specifying the endpoint and purpose.

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

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

No explicit guidance on when to use this tool versus alternatives like definitions, examples, or phrases. The purpose is clear but lacks comparative context for an agent to choose among many sibling tools.

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

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

The description goes beyond annotations by explaining storage is scoped by identifier, authenticated users get persistent memory, and anonymous sessions retain for 24 hours. No contradiction with annotations (idempotentHint=true, destructiveHint=false).

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

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

The description is concise (four sentences) and front-loaded with the core purpose. Every sentence adds value: purpose, usage, storage behavior, and companion tools. No fluff.

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

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

Given the tool's simplicity (2 required params, no output schema), the description covers all necessary aspects: what it does, when to use, how data is stored, persistence, and related tools. Complete for agent selection and invocation.

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

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

Schema coverage is 100% with clear descriptions. The description adds value by providing example key conventions (e.g., 'subject_property', 'target_ticker') and clarifying value is 'any text', enhancing the schema's meaning.

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

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

The description clearly states the tool's purpose: 'Save data the agent will need to reuse later' with specific verb 'save' and resource 'data'. It distinguishes from sibling tools by naming recall and forget as complementary actions.

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

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

The description provides explicit usage scenarios ('when you discover something worth carrying forward') with examples (resolved ticker, target address, etc). It also mentions persistence differences but lacks an explicit 'when not to use' statement, though the context is strong.

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 beyond the readOnly/idempotent annotations by disclosing that the tool cascades through multiple lookup endpoints, gracefully degrades if enrichment sources are unavailable, and explicitly reports unresolved identifiers under `unresolved` rather than omitting them. These are valuable behavioral traits not captured in structured fields.

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

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

The description is lengthy but well-structured, starting with user-facing query examples, then a crisp directive, then detailed type-specific explanations. Each section serves a purpose, though it could be trimmed slightly. It is front-loaded with the most important usage instruction early.

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

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

With no output schema, the description effectively explains return values: for company it lists the identifier types (CIK, ticker, LEI, FIGI) and notes unresolved handling; for drug it specifies RxCUI + ingredient + brand. It also covers failure behavior (degradation), making the tool's behavior well understood.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by giving concrete examples (AAPL, 0000320193) and clarifying that for company both ticker/CIK/name are accepted, and for drug brand/generic names are accepted. It also explains what each type returns, adding semantic meaning beyond the raw 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 uses a specific verb 'resolve' and resource 'entity name to identifiers', and clearly distinguishes from siblings by emphasizing 'Use FIRST whenever you have a name but need an ID.' It also lists supported entity types and their specific IDs, making the tool's function unmistakable.

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

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

It explicitly states when to use the tool ('Use FIRST whenever you have a name but need an ID'), and provides detailed guidance on accepted inputs for each type. While it doesn't name alternatives, the 'Use FIRST' directive and the specific context of ID resolution effectively communicate usage vs. other tools like entity_profile or search.

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

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

Description adds significant behavioral context beyond annotations: reveals ranking by score, confidence, signal density, and the process of probing each entity with ai_visibility_check. Annotations already declare idempotent, read-only, non-destructive; description aligns and enriches.

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

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

Three sentences, front-loaded with core purpose, uses concrete example, no redundant information. Every sentence earns its place.

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

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

With no output schema, description fully explains return structure (ranked list with score, confidence, signal density per entity). Covers all parameters and use case. Complete for the complexity level.

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

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

Schema already has 100% description coverage. Description adds crucial context: first entity treated as subject, rest as competitors, and context applied to every probe. This adds meaning beyond schema field 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 AI visibility across multiple entities side-by-side, distinguishes from siblings like ai_visibility_check (single entity probe) by specifying multi-entity ranking and competitive audit 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?

Explicitly suggests use for competitive AI-marketing audits and gives an example. Implicitly contrasts with ai_visibility_check for single entities, but does not explicitly state when not to use or list alternative tools.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint false. The description adds meaningful behavioral detail: partial failures when bundlephobia times out (5-30s) and graceful degradation via sources_failed field, which annotations don't cover.

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

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

The description is front-loaded with purpose and usage, followed by details. It's slightly verbose with parenthetical explanations but structured well for readability. Could tighten without losing value.

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

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

Given no output schema, the description fully explains the return structure (summary block, advisories, links, alternatives) and handles failure modes. Everything an AI needs to use the tool correctly is covered.

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 package and version. The description adds no additional semantics beyond that baseline, so a 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 defines the tool as a composite check for 'should I add this npm package?' covering license, advisories, bundle size, etc. It distinguishes itself from siblings by specifying the NPM ecosystem and the services it fans out to.

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

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

Explicitly states when to use: 'whenever an agent asks is X safe / popular / small' or 'what does adding lodash cost me'. Also notes ecosystem limitation and provides alternative for other package managers via deps.dev directly.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. Description adds wildcard support and return type (word strings), but lacks details on pagination, rate limits, or result ordering.

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 key action and result. 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?

Output schema exists, so return type is covered. However, with 10 parameters and 0% schema description coverage, the description should provide more detailed parameter guidance. Currently leaves many parameters undocumented.

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

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

Schema description coverage is 0%, so description must carry parameter meaning. It mentions filtering by part of speech, length, and corpus count but does not map to specific parameter names like includePartOfSpeech, minLength, minCorpusCount. Does not explain wildcard syntax or required query param.

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?

Describes tool as searching Wordnik dictionary with query string and wildcard support, and mentions filtering by part of speech, length, and corpus count. Clear verb and resource, but does not differentiate from sibling tools like search_within or deep_research.

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

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

No explicit guidance on when to use this tool versus alternatives. Does not list exclusions or mention context such as query 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?

The description adds significant behavioral context beyond the annotations: embedding model (BGE-base-en), window size (500-char overlapping), character cap (200K with truncation and flagging), and output structure (passages with offsets and similarity scores). No contradictions with annotations.

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

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

The description is a single paragraph of three sentences. It front-loads purpose, then usage, then technical details. While efficient, it could break into smaller sentences for easier scanning, but no wasted words.

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

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

Despite no output schema, the description fully explains what is returned (top-N passages with offsets and similarity scores). It also covers limitations (200K cap, truncation) and pairing suggestions. Complete for a semantic search tool.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaningful details: examples for 'text' (SEC 10-K, article), examples for 'query', and default value for 'limit' (5). This adds value 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 uses a specific verb+resource: 'Semantic search INSIDE a fetched record.' It clearly distinguishes from siblings by mentioning pairing with 'ask_pipeworx_grounded' and implying difference from a general 'search' tool.

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

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

The description explicitly states when to use: 'when the record is too big to cram into the prompt.' It also gives an alternative tool name ('ask_pipeworx_grounded') and explains the benefit (saves context, returns only relevant passages).

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

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

Annotations are readOnlyHint=false, openWorldHint=true, idempotentHint=true, destructiveHint=false. Description adds significant behavioral context: returns subscription id, delivery limitations (SMS cap, webhook auto-disable), phone verification requirement, and that subscriptions persist only for OAuth accounts. 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?

Well-structured with the purpose upfront. Every sentence adds value, though the webhook section is slightly verbose. Overall efficient for the 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 the tool's complexity (multiple event types, delivery channels, constraints), the description covers prerequisites, type-specific parameters, delivery details, and limitations. No output schema but return value is mentioned. Complete for an agent to invoke correctly.

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

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

Schema coverage is 100%, but description goes far beyond: explains each enum value with examples (e.g., sec_8k items codes), details the params object for all types, and elaborates on delivery channels with validation rules (phone verification, webhook signing secret).

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 'Create a proactive monitoring subscription to a live-data event stream' and distinguishes the tool from siblings like list_subscriptions and unsubscribe by detailing event types and delivery channels.

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 clear context on when to use ('proactive monitoring') and prerequisites ('Requires a Pipeworx OAuth account'). Does not explicitly exclude other tools or list alternatives, but the guidance is sufficient for the tool's purpose.

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds context that it returns non-destructive, category-bucketed examples and is for onboarding. No contradiction; adds value beyond annotations.

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

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

The description is front-loaded with common queries and contains useful information. While slightly long, every sentence adds value. Could be more concise but not wasteful.

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

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

Given the simple parameter schema and lack of output schema, the description fully explains the tool's output (category-bucketed examples) and use case (onboarding). No gaps.

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

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

Schema coverage is 100%. The description adds meaning by explaining that omitting 'topic' gives a cross-category spread and lists example topics. Baseline 3, but additional context justifies 4.

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

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

The description clearly states the tool's purpose: returns category-bucketed example questions for onboarding, with exact tool+argument shapes. It distinguishes itself from siblings (e.g., ask_pipeworx, examples, discover_tools) by positioning as the first-use entry point.

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

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

Explicitly advises to 'Use this FIRST when you do not yet know what Pipeworx can do' and explains when to call with no arguments vs. with a specific topic. Provides clear context on 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?

Annotations already provide readOnly, openWorld, idempotent, and non-destructive hints, so the description's additional claim of returning a single sentence adds minimal behavioral insight. However, it does not disclose error behavior or quality criteria.

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

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

The description is a single sentence of 14 words, front-loading the key action and result. No extraneous information is present.

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

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

Given the presence of an output schema (which likely explains return values) and annotations covering safety, the description is mostly complete for a simple tool. It could mention edge cases (e.g., word not found) but is generally 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?

With 0% schema description coverage, the description should explain parameters but does not. While 'word' is self-explanatory, 'useCanonical' is not described at all, leaving the agent guessing about its meaning.

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

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

The description clearly states the tool returns a single highest-quality usage example sentence for a word from Wordnik's corpus. It specifies the verb 'Return', the resource 'usage example sentence', and includes a qualifier 'single highest-quality', which distinguishes it from sibling tools like 'examples' that likely return multiple examples.

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

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

The description implies usage for obtaining the top example but does not explicitly state when to use this versus alternatives (e.g., 'examples' for multiple). It also omits guidance on the optional 'useCanonical' parameter.

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 non-read-only, idempotent, non-destructive behavior; the description adds crucial context: ownership enforcement, deactivation (not deletion), and that historical events remain accessible via 'recent_alerts'. 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 extremely concise: two sentences that convey all essential information without redundancy. Every sentence adds value.

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

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

Given the simple single-parameter structure and detailed annotations, the description fully covers what an agent needs: action, ownership constraint, deactivation vs deletion, and link to related tool. No gaps.

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

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

The input schema provides 100% coverage for the only parameter ('id') with a clear description. The tool description merely restates 'by id' without adding new meaning, meeting 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 action ('Cancel a subscription by id') and specifies the resource ('subscription'). It distinguishes itself from siblings like 'subscribe' (which creates) and 'recent_alerts' (which reads historical events) by mentioning deactivation behavior and historical event availability.

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 tells when to use the tool (to cancel a subscription) and imposes an ownership constraint ('you can only cancel your own subscriptions'). It implicitly advises against expecting deletion by stating 'deactivated (not deleted)'. However, it does not explicitly list when not to use or contrast with alternatives like 'list_subscriptions' for viewing active subscriptions.

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 well beyond the readOnly/openWorld/idempotent annotations. It clearly explains the verdict set (confirmed, approximately_correct, etc.), the critical distinction between could_not_verify (tool failure, not evidence) and unsupported (no source), and the use of verbatim evidence with citations. It also reveals the internal fallback behavior between structured and grounded pipelines, which is valuable 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 well-structured but somewhat verbose, with a long list of trigger phrases and many details. However, every section contributes: the trigger list aids matching, the verdict explanation is critical, and the pipeline explanation is useful. It is not as tight as a two-sentence description, but not excessively padded.

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

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

Despite lacking an output schema, the description comprehensively explains the output verdicts, the meaning of failure states, the evidence/citation format, and the two processing paths. For a tool of this complexity, the description covers the key behavioral and output aspects well enough for an agent to invoke and interpret results correctly.

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

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

Schema coverage is 100% and both parameters have descriptions, giving a baseline of 3. The description adds meaningful nuance by explaining that tolerance_pct overrides the implied tolerance from the claim and by recommending 1–2 for hallucination detection. This goes beyond the schema's basic description, so a 4 is warranted.

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 verifies natural-language factual claims against authoritative sources, with specific scope (company-financial vs. other claims). It is a clear verb+resource definition, but it does not explicitly name or distinguish from sibling tools like ask_pipeworx or search, so it stops short of full sibling differentiation.

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

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

The description explicitly says 'Use whenever the agent needs to check whether something a user said is factually correct', providing a clear use case. It also explains the two routing paths (SEC EDGAR for financial claims, grounded pipeline otherwise). However, it does not mention when not to use the tool or point to alternative tools, so exclusions are missing.

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

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint=false. The description adds behavioral details: date format (YYYY-MM-DD), default to today if omitted, and return type (word, definitions, example sentences). This adds value beyond annotations.

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

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

The description is a single, front-loaded sentence with no wasted words. Every element ('Fetch', 'Wordnik Word of the Day', date format, default behavior, return content) is necessary and efficiently stated.

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

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

The tool has one optional parameter and an output schema (not shown but referenced). The description adequately covers the input (date format/default) and output (word, definitions, example sentences). For a simple tool, this is sufficiently 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?

With 0% schema description coverage, the description compensates by specifying the date format (YYYY-MM-DD) and the default behavior (today if omitted). This adds meaning beyond the raw schema that only shows type string.

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

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

The description clearly states the action ('Fetch'), the resource ('Wordnik Word of the Day'), and the output ('word, definitions, and example sentences'). It distinguishes from siblings like 'random_word' and 'definitions' by specifying it's the 'Word of the Day' for a given date.

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

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

The description implies usage for fetching the word of the day, but does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives among siblings. The context is clear but lacks exclusions.

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