Wordnik

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

Annotations already indicate readOnlyHint=true, openWorldHint=true, destructiveHint=false. Description adds that it returns structured answers with stable pipeworx:// citation URIs, which is useful process detail not in annotations.

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

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

Description is somewhat lengthy but front-loaded with key preference guidance and examples. Every sentence contributes to purpose and usage. Could be slightly more concise, but structure is logical.

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

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

Given no output schema, description explains return type (structured answer with citations). Covers purpose, usage, parameter, and behavior comprehensively. No gaps remain.

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

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

Schema coverage 100% with parameter 'question' described as natural language. Description adds extensive examples of valid questions (e.g., 'current US unemployment rate', 'Apple's latest 10-K'), providing meaningful 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?

Description explicitly states the tool routes factual questions to appropriate sources among 2,520 tools, with clear verb 'routes the question' and resource list. Differentiates from web search and lists specific data domains like SEC filings, FDA data, etc.

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 'PREFER OVER WEB SEARCH' and provides when-to-use criteria including specific query patterns ('what is', 'look up', etc.) and examples. Implies alternatives (web search) and gives 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?

The description discloses the core behavior: resolving market, classifying bet, fanning out to data packs, returning evidence and comparison. It aligns with annotations (readOnly, non-destructive). The openWorldHint is consistent with the nature of pulling current data. It does not mention potential delays or data freshness caveats, but for a read-only tool, the transparency is high.

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 efficiently packages purpose, input, process, output, and use cases in a logical order. Sentences are substantive, though the closing line about conversion rates is somewhat promotional. Overall, it's appropriately sized for a complex tool.

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

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

The description covers input, processing logic, and output at a sufficient level for an AI agent to understand usage. It explains the fan-out mechanism and classification. The absence of an output schema means the description partly compensates, though the exact format of the evidence packet is not detailed. Still, it provides enough context for typical use.

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

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

The input schema already describes both parameters well, including enum for depth and description for market. The description provides additional examples of slug and URL but doesn't clarify syntax or constraints beyond the schema. With 100% schema coverage, the description's parameter semantics add minimal new information, keeping the score at baseline 3.

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

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

The description opens with a specific verb+resource: 'Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call.' It details input types (slug, URL, question text) and output (evidence packet + market-vs-model comparison). The closing sentence distinguishes it from having to discover packs manually, contrasting with sibling tools like ask_pipeworx or polymarket_arbitrage. The purpose is unmistakable and well-differentiated.

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

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

The description provides explicit use cases: 'should I bet on X?', 'what does the data say?', 'is there edge in this bet?'. It also indirectly contrasts with self-discovery of packs, implying that this tool is the recommended unified call. However, it does not explicitly exclude other tools like ask_pipeworx for general queries or specify when to use siblings like polymarket_arbitrage.

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

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

Annotations already mark this as read-only and non-destructive. The description adds value by naming data sources (SEC EDGAR/XBRL, FAERS, FDA), indicating returned data includes citation URIs, and contrasting with other tools. This provides solid behavioral context beyond annotations.

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

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

The description is dense but efficient, conveying purpose, usage triggers, data sources, and efficiency benefits in a compact paragraph. It could be slightly better structured (e.g., bullet points), but it is not overly verbose and front-loads the core function.

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, but the description mentions 'paired data + pipeworx:// citation URIs', giving agents a high-level idea of what to expect. For a relatively complex multi-entity comparison tool, this is adequate, though more detail on output structure would improve completeness.

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

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

Despite 100% schema description coverage, the description adds substantial meaning: clarifies the type enum with examples, explains values for each type (tickers/CIKs vs drug names), provides constraints (2-5 items), and illustrates with specific instances like 'AAPL' and 'ozempic'. This goes far beyond the schema's minimal 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 purpose: compare 2-5 companies or drugs side by side. It specifies the verb 'compare' and the differentiated resources (companies via SEC data, drugs via FAERS/FDA/trials). Examples of user queries like 'compare X and Y' make the tool's intent 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?

The description explicitly states when to use: when a user says 'compare X and Y', 'X vs Y', or wants tables/rankings. It also notes efficiency by replacing many sequential calls. It lacks explicit 'when not to use' instructions, but the context is still 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds no behavioral context, such as return format or other traits.

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 short (one word), but this is under-specification rather than conciseness. It lacks structure and does not earn 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 and 7 parameters, the description is woefully incomplete. It does not hint at what is returned or how parameters affect 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 description coverage is 0%, meaning the description provides no meaning for any of the 7 parameters (word, limit, includeTags, etc.). The description is completely silent on parameter semantics.

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

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

The description is 'Definitions.' which is a tautology, restating the tool name without any verb or resource specificity. It doesn't distinguish from siblings like 'phrases' or 'frequency'.

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

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

No guidance on when to use this tool versus alternatives. Many sibling tools exist (e.g., 'phrases', 'related', 'pronunciations'), and the description provides no 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?

The description states it 'Returns the top-N most relevant tools with names + descriptions,' adding value beyond annotations. Annotations already declare readOnlyHint=true and destructiveHint=false, so safety profile is clear. No contradictions. The description does not mention rate limits or authentication, but given annotations, this is acceptable for a read-only tool.

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

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

The description is front-loaded with the core purpose in the first sentence, followed by usage context and a domain list. It is relatively concise for a tool with broad applicability, though the list of domains makes it slightly lengthy. Overall, every sentence contributes value, earning a 4.

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

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

Given no output schema, the description adequately explains the return format: 'top-N most relevant tools with names + descriptions.' It covers the primary use case and return type. No mention of pagination or sorting is needed for a simple discovery tool. Completeness is good for the tool's 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 coverage is 100%: both 'query' and 'limit' are described in schema. The description mentions 'top-N' but does not add new semantic meaning beyond what the schema already provides (e.g., default/max values). Therefore, the description adds marginal value over schema; baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: to find/browse tools by describing data or task. It lists many specific domains and differentiates itself by being a discovery tool rather than a direct answer tool, especially noted by 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' This distinguishes it from siblings like 'search' or 'entity_profile'.

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

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

The description explicitly says 'Use when you need to browse, search, look up, or discover what tools exist' and advises to 'Call this FIRST when you have many tools available and want to see the option set.' It gives clear context for when to use, though it does not explicitly exclude specific sibling tools or provide when-not-to-use scenarios. Still, 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?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds transparency by listing the exact data returned (SEC filings, fundamentals, patents, news, LEI) and mentioning citation URIs. It does not contradict annotations. A minor omission is no mention of pagination or rate limits, but given the annotations, the description is sufficiently transparent.

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

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

The description is a single paragraph but well-structured: starts with core purpose, gives use cases, lists returns, and ends with parameter constraints. Every sentence adds value, and it is front-loaded with the most important information. 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 having no output schema, the description thoroughly explains what the tool returns (recent SEC filings, fundamentals, patents, news, LEI, citation URIs). It covers the complexity of aggregating multiple data sources and gives enough context for an agent to decide when to use it.

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

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

The input schema already has high coverage with descriptions for both parameters (type and value). The description restates that only company type is supported and that value expects a ticker or CIK, not a name. This adds little beyond the schema, so a 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 clearly states the tool's purpose: 'Get everything about a company in one call.' It provides specific use cases and distinguishes from alternatives by listing the data sources (SEC EDGAR, USPTO, etc.) that would otherwise require multiple tool calls. The verb 'get' and resource 'company profile' are specific and unambiguous.

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

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

The description explicitly tells when to use the tool (when a user asks for company info) and provides examples of queries. It also gives exclusion guidance: names are not supported, and recommends 'resolve_entity' as an alternative step. This is comprehensive usage guidance.

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

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

The description adds no behavioral context beyond what is already provided by annotations (readOnlyHint: true, destructiveHint: false). It does not describe return format, pagination, error handling, or any side effects, so it fails to enhance transparency.

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

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

The description is extremely short (two words) but fails to provide necessary information. It is a case of under-specification rather than effective conciseness; every sentence should add value, and this does not.

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 parameters, no output schema, and many sibling tools, the description is grossly incomplete. It does not explain what the tool returns, how parameters interact, or when to use it over closely related tools like 'definitions'.

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 and a terse description, no parameter meaning is conveyed. The description does not explain the purpose of 'word', 'skip', 'limit', 'useCanonical', or 'includeDuplicates', forcing the agent to infer or guess.

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 'Usage examples.' vaguely indicates the tool provides examples of usage, likely for a word. It is not a tautology but lacks specificity about the resource or action. It distinguishes from siblings like 'definitions' and 'pronunciations' by the type of output, but the description is minimal.

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

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

No guidance is provided on when to use this tool versus alternatives such as 'definitions' or 'phrases'. There is no mention of context, prerequisites, or exclusions, leaving the agent with no decision support.

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 correctly indicates a destructive action ('delete'), which aligns with the destructiveHint=true annotation. It adds no new behavioral info beyond what annotations provide, but is consistent and clear.

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

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

Two concise sentences: first defines the action, second gives usage guidelines and companion tools. No wasted words, 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 a single parameter, no output schema, and clear annotations, the description covers purpose, usage, and sibling relationships adequately.

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

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

Schema coverage is 100% with a description for the key parameter. The description adds 'by key' but does not provide additional format or examples beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states 'Delete a previously stored memory by key', using a specific verb (delete) and resource (memory by key). It distinguishes from siblings like remember and recall by mentioning they are paired 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 explicitly states when to use the tool: 'when context is stale, the task is done, or you want to clear sensitive data'. It also mentions pairing with remember and recall, providing clear use-case 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, indicating no destructive effects. However, the description adds no further behavioral context such as authentication requirements, rate limits, or side effects, missing an opportunity to provide 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 extremely brief, but this brevity is a result of under-specification rather than conciseness. It fails to convey necessary information, wasting the opportunity to be helpful.

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 four parameters, no output schema, and no schema descriptions, the description is grossly inadequate. It provides essentially no information beyond the name, leaving the agent without critical details to use the tool correctly.

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

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

With 0% schema description coverage, the description must explain parameter semantics. 'Usage frequency.' does not clarify the meaning or usage of 'word', 'startYear', 'endYear', or 'useCanonical', making it impossible for an agent to know how to populate them 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 'Usage frequency.' is a vague phrase that does not specify a verb or resource. It fails to indicate what action is performed or what data is retrieved, and does not distinguish from sibling tools 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?

No guidance is given on when to use this tool versus alternatives. There is no mention of context, prerequisites, or exclusions, leaving the agent uninformed about appropriate use cases.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds no further behavioral context. It does not mention any traits beyond what annotations provide, but at least it does not contradict them.

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?

Extremely short but not concise because it fails to convey essential information. Every sentence should earn its place, but this single word adds no value beyond the name.

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 4 undocumented parameters, no output schema, and a one-word description, the tool is entirely incomplete for an AI agent to invoke correctly. The description fails to compensate for schema 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?

Input schema has 4 parameters with 0% description coverage. The description adds no meaning for 'word', 'limit', 'useCanonical', or 'sourceDictionary'. Without any param explanations, the agent cannot determine correct usage.

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

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

The description is a tautology: it only repeats the tool name 'Hyphenation.' without any verb or resource specification. It fails to state what the tool does (e.g., returns hyphenated word or checks 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?

No guidance on when to use this tool versus alternatives like 'phrases' or 'definitions'. The description provides no context for appropriate usage 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 declare readOnlyHint=true and destructiveHint=false, so the description need not repeat safety. However, it adds no other behavioral context (e.g., response format, pagination), resulting in a baseline score.

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?

Extremely concise (two words), but this is under-specification rather than efficient communication. The description lacks essential structure and informative 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 4 parameters, no output schema, and no parameter descriptions, the tool requires far more context. The description is insufficient for an agent to understand how to use the tool effectively.

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

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

Schema description coverage is 0%, and the description 'Bigram phrases' provides no explanation of parameters (wlmi, word, limit, useCanonical). The description fails to add meaning beyond the schema.

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

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

The description 'Bigram phrases' vaguely indicates the topic but lacks a verb or action. It does not clearly state what the tool does (e.g., retrieve, search) and does not distinguish it from siblings like 'related' or '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?

No guidance is provided on when to use this tool versus alternatives. The description offers no context about appropriate use cases or 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?

The description discloses behavioral traits beyond annotations: rate-limited to 5 per identifier per day, free, doesn't count against tool-call quota, and team reads digests daily. Annotations (readOnlyHint false, etc.) do not contradict these details, and the description adds valuable transparency.

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

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

The description is a single, well-structured paragraph that front-loads the core purpose, then provides use examples, formatting tips, and behavioral notes. Every sentence is necessary and adds value, with no redundancy.

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

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

For a feedback tool with no output schema, the description covers all needed aspects: purpose, when to use, how to format feedback, rate limits, and impact (roadmap). It is fully complete given the tool's complexity.

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

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

The input schema has 100% description coverage, so the description's job is lighter. However, it adds value by explaining the enum meanings more contextually and reinforcing the purpose of the 'context' object. It also provides guidance on message content ('be specific, which tool, what error'). This slightly exceeds baseline 3.

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

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

The description explicitly states the tool's purpose: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It lists specific use cases (bug, feature, data_gap, praise), making it clear and distinct from sibling tools which are data-retrieval oriented.

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

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

The description provides explicit guidance on when to use the tool (e.g., 'when a tool returns wrong/stale data', 'when a tool you wish existed isn't in the catalog', 'when something worked surprisingly well') and what to avoid ('don't paste the end-user's prompt'). It also mentions rate limits and quota impact, giving comprehensive 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 indicate readOnlyHint, openWorldHint, and destructiveHint. The description adds valuable behavioral context: it explains the two modes, the search process for topic mode, and the output format (ranked opportunities with reasoning). 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 appropriately sized, with concise sentences that each contribute value. It uses clear headings for modes and examples, making it easy to parse quickly without wasted words.

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

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

Given no output schema, the description adequately explains the output content. It covers both modes and their contexts but could mention potential errors or prerequisites. Overall, it is complete enough for a read-only 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?

Although schema coverage is 100%, the description adds meaning by explaining how each parameter enables a different mode, with examples like 'event' slug or 'topic' seed. This enhances understanding beyond the schema's property descriptions.

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

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

The description clearly states the tool's purpose: finding arbitrage opportunities on Polymarket by checking monotonicity violations. It introduces two distinct modes ('event' and 'topic') with specific use cases, which distinguishes it from sibling tools like 'polymarket_edges'.

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

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

The description provides clear guidance on when to use each mode, including examples and a rationale for the cross-event mode to catch cases missed by single-event mode. However, it does not explicitly mention when not to use the tool or suggest alternatives among siblings.

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

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

Beyond annotations (readOnlyHint, openWorldHint, destructiveHint), the description details the methodology (lognormal model from FRED, coinpaprika price, grouping by asset, ranking by |edge|) and the output (top N with suggested trade direction), providing comprehensive 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 with a clear front-loaded purpose, followed by methodology and use case. Every sentence contributes essential information, and the length is appropriate for 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 a detailed description, the absence of an output schema leaves ambiguity about the exact return format. The description mentions 'top N ranked by edge magnitude with suggested trade direction' but does not specify fields, which is a gap for complete understanding.

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

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

Input schema has 100% description coverage with clear descriptions for limit, window, and min_edge_pp. The description adds only marginal value by referencing 'top N' for limit, but does not significantly enhance parameter understanding beyond the schema.

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

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

The description clearly states the tool scans Polymarket markets and returns those with the largest disagreement between Pipeworx data and market price, using a specific model. It differentiates from siblings like 'polymarket_arbitrage' by focusing on edge magnitude for betting opportunities.

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 frames the tool for the 'what should I bet on today' question, implying when to use it, but does not explicitly state when not to use it or provide direct alternatives among the listed siblings.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. However, the description adds no behavioral context (e.g., language scope, format variants). Minimal 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 extremely brief (one word), but this is not conciseness—it is under-specification. 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?

Given five parameters, no output schema, and zero parameter coverage in the description, the tool definition is completely inadequate for correct invocation by an AI agent.

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

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

Schema description coverage is 0%, and the description does not explain any of the five parameters (word, limit, typeFormat, useCanonical, sourceDictionary). The agent receives no semantic help for parameter usage.

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

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

The description is the single word 'Pronunciations,' which is a tautology of the tool name. It lacks a verb or specific resource, so the agent cannot determine what action the tool performs (e.g., retrieving, listing, or searching 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?

The description provides no guidance on when to use this tool versus its siblings (e.g., definitions, examples). No context or exclusion criteria are given.

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

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

Annotations already indicate readOnlyHint=true, openWorldHint=true, destructiveHint=false. The description adds no behavioral context such as if results are cached, rate limits, or how randomness is generated. It fails to add value 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?

At two words, the description is extremely concise but severely under-specified for a tool with 7 parameters and no output schema. Conciseness here is not a virtue; it sacrifices necessary 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 complexity (7 parameters, no output schema) and low schema coverage, the description is wholly inadequate. It does not explain what the tool returns, how parameters affect results, or any operational 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 has 7 parameters with 0% description coverage. The description does not explain the meaning or effect of any parameter (e.g., maxLength, hasDictionaryDef). This is a critical gap for correct tool invocation.

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 'Random word.' is a tautology of the tool name. It vaguely states the tool returns a random word but does not specify the resource (e.g., any word, from dictionary, etc.) or distinguish it from sibling 'random_words' which likely returns multiple words.

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

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

No guidance on when to use this tool versus alternatives like 'random_words' or other search tools. No exclusion criteria or context for appropriate usage.

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

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

Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds no additional behavioral context, such as randomness source, reproducibility, or side effects.

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 (3 words) but severely under-specified. Conciseness is positive but here it sacrifices necessary 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 complex input schema with 8 optional parameters and no output schema, the description is utterly incomplete. It fails to explain what N is, how parameters work, or what the output looks like.

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 and 8 parameters, the description 'N random words' provides no explanation of parameters like minLength or hasDictionaryDef, leaving the agent without critical guidance.

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 'N random words' clearly indicates the tool returns multiple random words, but fails to differentiate from the sibling 'random_word', which likely returns a single word. A better description would explicitly contrast plural vs singular.

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

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

No guidance on when to use this tool over alternatives like 'random_word' for single word retrieval. The description does not mention use cases or exclusions.

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

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

Annotations already set readOnlyHint=true. Description adds that retrieval is scoped to identifier and that omitting key lists all keys, which 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?

Two sentences with front-loaded action, then use cases, then pairing info. Every sentence adds value with no wasted words.

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

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

For a simple tool with one optional param and no output schema, description fully explains behavior, scoping, and relationship to siblings. 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% with a clear description for key. Description reinforces the purpose and adds usage context (omit to list all keys), providing added 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?

Description clearly states verb (retrieve/list) and resource (saved values via remember). It distinguishes from siblings remember and forget by specifying the retrieval action and listing behavior when key is omitted.

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

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

Explains when to use (look up previously stored context) and provides explicit pairing with remember and forget. No explicit when-not-to-use, but the context is clear enough.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds that it fans out in parallel to three sources, explains 'since' formats, and mentions output structure (changes + count + URIs). Adds useful 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?

Three sentences that front-load purpose, provide usage examples, and key details. No unnecessary words.

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

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

With 3 required params and no output schema, the description explains input formats, output content (structured changes, count, URIs), and behavior (parallel fan-out). Complete for agent decision-making.

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

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

Schema coverage is 100% with descriptions for all 3 parameters. Description reiterates 'since' formats and adds output info, but does not significantly enhance parameter meaning beyond schema examples.

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

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

The description clearly states it returns recent changes for a company over a time window, with example queries and specification of data sources (SEC, GDELT, USPTO). It distinguishes from siblings like search and entity_profile.

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 gives example queries ('what's happening with X?', 'any updates on Y?') and says 'Use when...' for monitoring. Does not explicitly exclude alternatives but context makes it clear.

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

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

Annotations already indicate readOnlyHint, openWorldHint, and destructiveHint. The description adds no behavioral context, such as how 'related' is determined or if results vary.

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?

At two words, the description is underspecified rather than concise. Every sentence must earn its place; this one provides negligible information.

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

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

Given the tool has 4 parameters, no output schema, and rich sibling context, the description is severely incomplete. It does not cover expected behavior, return values, or parameter 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 description coverage is 0%, and the description fails to explain any of the 4 parameters (word, useCanonical, relationshipTypes, limitPerRelationshipType). It adds no value beyond the schema structure.

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 'Related words' provides only a vague hint of what the tool does, lacking a specific verb (e.g., 'get', 'list') and failing to distinguish from sibling tools like 'definitions' or 'phrases'. It barely improves on the tool name.

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

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

No guidance on when to use this tool vs alternatives. Sibling tools exist for similar word operations, but the description gives no context or exclusions.

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

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

Annotations provide basic hints (not read-only, not destructive), but the description adds important details: key-value pair scoping by identifier, persistence for authenticated users vs 24-hour retention for anonymous sessions. 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 three sentences, front-loading the purpose and usage. Every sentence adds value without redundancy or unnecessary 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 no output schema, the description explains persistence and scope sufficiently. However, it omits mention of return values or error handling, which would improve completeness for a storage operation.

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 and examples. The description adds context about key-value pair and scoping, but does not significantly enhance understanding beyond the schema, earning the baseline score.

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

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

The description clearly states the tool saves data for reuse across conversations or sessions, using specific verbs like 'save' and 'reuse'. It also distinguishes from siblings 'recall' and 'forget' by mentioning them explicitly.

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 when to use: 'when you discover something worth carrying forward'. It also suggests pairing with recall/forget. However, it does not explicitly state when not to use or provide alternatives beyond siblings.

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

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

Annotations already indicate readOnly and non-destructive. The description adds behavior like returning IDs plus pipeworx:// citation URIs and that it replaces multiple calls. However, it doesn't address potential issues like ambiguity resolution or rate limits.

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

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

The description is a single paragraph of ~5 sentences, front-loading purpose and usage. It is concise but could be slightly more structured (e.g., bullet points). However, it contains no redundancy and every sentence adds value.

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

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

Given no output schema, the description covers return values (IDs and citation URIs). It also addresses when to use the tool (pre-requisite for other tools) and input semantics. For a tool with 2 required parameters and an enum, this is highly 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% but the description adds significant meaning: it clarifies the 'type' enum and explains the 'value' parameter formats (e.g., ticker, CIK, name for company). Examples further illustrate usage, going beyond the schema's minimal descriptions.

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

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

The description clearly states the tool's purpose: 'Look up the canonical/official identifier for a company or drug.' It specifies the ID systems (CIK, ticker, RxCUI, LEI) and provides concrete examples, distinguishing itself from sibling tools by noting it replaces 2–3 lookup 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 tells when to use: 'Use when a user mentions a name and you need the CIK...' and 'Use this BEFORE calling other tools that need official identifiers.' This provides clear context and direction for the agent.

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 openWorldHint=true, so the description adds no behavioral context. Important traits like pagination (skip/limit parameters), result ordering, or search scope are not mentioned.

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 (2 words), but this comes at the expense of necessary information. It is under-specified rather than efficiently informative.

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

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

Given 10 parameters, no output schema, and no parameter descriptions, the description is severely incomplete. It provides almost no contextual information about inputs, behavior, or return values.

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 and 10 parameters, the description 'Word search.' adds no meaning to any parameter. Parameters like 'query', 'skip', 'maxLength', etc., remain entirely 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?

The description 'Word search.' is vague and does not specify what kind of word search (e.g., dictionary lookup, text search). It fails to differentiate from sibling tools like 'definitions', 'phrases', or 'frequency', which also relate to words.

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

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

No guidance is provided on when to use this tool vs. alternatives. The description does not indicate context, prerequisites, or situations where other tools would be more appropriate.

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 destructiveHint=false, so the tool's safety profile is clear. The description adds no behavioral context beyond stating it returns a single example, which aligns with the read-only hint. No contradictions or new information.

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, which is concise, but it is under-specified. It is front-loaded but does not earn its place because it provides minimal information. Adequate for a very simple tool but not optimally helpful.

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 2 parameters with no schema descriptions, no output schema, and no behavioral details beyond annotations, the description is severely incomplete. The agent cannot understand the tool's purpose, parameters, or output meaningfully.

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 provides no parameter meaning. The agent is left to guess what 'word' and 'useCanonical' do. The description could have elaborated on these but did not.

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 'Single top example.' is vague. It suggests the tool returns a single example that is 'top', but does not clarify what 'top' means or what domain the example belongs to. It is a slight improvement over a tautology but lacks a specific verb and resource, especially compared to siblings like 'examples' which might be more descriptive.

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

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

The description provides no guidance on when to use this tool versus alternatives. Sibling tools include 'examples', 'word_of_the_day', etc., but no differentiation is made. The agent cannot determine when to choose 'top_example' over other tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool is safe and non-mutating. The description adds useful behavioral context: it returns a verdict (with five possible values), extracted structured form, actual value with citation, and percent delta. It also notes that it replaces 4–6 sequential calls. No contradiction with annotations. This is good, though it could mention error handling or edge cases.

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 (3-4 sentences) and front-loaded: purpose, usage, scope, return fields, and efficiency note. Every sentence adds value without redundancy. It is well-structured and easy to parse.

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

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

For a simple one-parameter tool with no output schema, the description is adequately complete. It specifies the input format, domain, return fields, and efficiency benefit. However, it lacks information about possible errors, edge cases, or limitations beyond domain coverage. Still, given the low complexity, it is sufficient.

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

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

The schema has one parameter 'claim' with 100% description coverage. The description reinforces the parameter by providing example claims ('Apple's FY2024 revenue was $400 billion'). This adds value beyond the schema's own description, helping the agent format input 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's purpose: 'Fact-check, verify, validate, or confirm/refute a natural-language factual claim or statement against authoritative sources.' It provides specific examples of user queries ('Is it true that…?'), and specifies the domain (company-financial claims for US public companies via SEC EDGAR). This distinguishes it from sibling tools like 'ask_pipeworx' or 'bet_research', which likely serve different functions.

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

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

The description explicitly says 'Use when an agent needs to check whether something a user said is true' and gives example phrasings. It also clarifies the scope: 'v1 supports company-financial claims (revenue, net income, cash position for public US companies)'. While it does not list explicit when-not-to-use or alternatives, the contextual guidance is clear enough for an agent to decide when to invoke this tool.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false, so the safety profile is clear. However, the description adds no behavioral details (e.g., what the date parameter does, default behavior, error conditions).

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 short but under-specified. Conciseness is not beneficial when critical information is omitted. One sentence with an acronym is insufficient.

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

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

Given no output schema and only one parameter, the description is essentially empty. It does not explain what the tool returns, default behavior, or any expected input format. Completely inadequate.

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

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

Input schema has a 'date' parameter with no description (0% coverage). The description fails to explain its purpose or format, making it impossible for the agent to understand how to use it 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?

Description is just 'WotD.' which is an abbreviation. It does not state what the tool does, such as retrieving the word of the day. The purpose is unclear and tautological, providing no value beyond the name.

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

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

No guidance on when to use this tool versus alternatives like 'random_word' or 'definitions'. The description offers no context for appropriate usage, leaving the agent without direction.

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