words

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds critical context: it probes LLMs, returns per-model data and a combined view, and notes that using Anthropic requires the user's own API key and direct payment. 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 two sentences, front-loaded with the main action and key details. Every sentence serves a purpose, and there is no redundancy or 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 lacking an output schema, the description fully explains the return format (per-model {score, confidence, signals, raw_response} + combined view) and use cases. It is complete for a probing tool, covering what the agent needs to know to invoke and interpret results.

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

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

Schema coverage is 100% with all parameters documented. The description enhances understanding by explaining the 'entity' parameter with examples, clarifying the 'models' parameter default, describing the '_apiKey' pass-through, and providing guidance for the 'context' parameter. This adds significant 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 specifies a clear verb ('probe'), resource ('one or more LLMs'), and outcome ('score visibility 0-100 per model'). It distinguishes itself from sibling tools by explicitly mentioning 'AI-marketing audits, pre-launch brand checks, competitive monitoring', which sets it apart from related tools like scan_competitor_ai_presence.

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

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

The description provides clear context for when to use the tool (AI-marketing audits, pre-launch brand checks, competitive monitoring) and explains the default model and optional Anthropic probing with a BYO key. However, it does not explicitly state when not to use it or compare it to alternatives like scan_competitor_ai_presence.

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

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

No annotations are provided, so the description carries the full burden. It discloses key behaviors: the tool selects data sources and fills arguments automatically, and it handles natural language questions. However, it lacks details on limitations (e.g., response format, error handling, rate limits) or prerequisites, which are important for a tool with no 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?

The description is front-loaded with the core functionality, uses efficient sentences, and includes helpful examples without redundancy. Every sentence adds value: the first explains the tool's role, the second details its automation, and the third provides illustrative use cases.

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

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

Given the tool's complexity (natural language querying with automated tool selection) and lack of annotations/output schema, the description does well by explaining the process and providing examples. However, it could be more complete by mentioning potential limitations or the types of data sources available, which would help an agent anticipate 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 100%, so the baseline is 3. The description adds value by explaining the parameter's purpose beyond the schema's 'natural language' note: it emphasizes that questions should be in 'plain English' and provides concrete examples (e.g., trade deficit, adverse events), clarifying the expected input format and scope.

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

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

The description clearly states the tool's purpose: 'Ask a question in plain English and get an answer from the best available data source.' It specifies the verb ('ask'), resource ('answer from data source'), and distinguishes from siblings by emphasizing natural language processing versus structured tool selection (e.g., 'No need to browse tools or learn schemas').

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

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

The description explicitly states when to use this tool: 'just describe what you need' in natural language, and provides clear examples like 'What is the US trade deficit with China?'. It implicitly distinguishes from sibling tools (e.g., autocomplete, find_synonyms) by focusing on broad data queries rather than specific linguistic or memory functions.

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, etc.), the description adds behavioral context: hallucination resistance, explicit refusal reasons, extraction limited to tool results, and extra LLM call cost. No contradiction with annotations.

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

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

The description is concise but packs substantial information into one paragraph. It front-loads the core concept and is clear, though it could be slightly better structured with bullet points for the return format.

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 (routing across 3,641 tools, 851 sources, explicit refusal handling), the description fully explains behavior, return format, and use cases. No output schema exists, so the description handles return values well.

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

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

Schema coverage is 100% with all aliases documented. The description only says 'Your question in natural language', which adds no new meaning 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 it is a 'hallucination-resistant answer mode' that extracts answers only from tool results, distinguishing it from the sibling 'ask_pipeworx' by noting the extra LLM call cost and high-stakes 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 specifies when to use (high-stakes reads where facts must not be invented) and when to prefer the simpler sibling ('prefer ask_pipeworx for casual lookups'), providing clear guidance with 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool is 'useful for autocomplete and spelling suggestions,' which hints at read-only behavior, but doesn't explicitly state whether it's read-only, its performance characteristics, rate limits, or error handling. This leaves significant gaps for a tool with no 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?

The description is concise and well-structured with two sentences: the first states the core purpose, and the second adds practical context. Every sentence earns its place without redundancy, making it efficient 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 tool's moderate complexity (2 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose and usage context but lacks details on behavioral traits, output format, or how it differs from siblings. This meets minimum viability but has clear gaps in providing a full understanding.

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

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

Schema description coverage is 100%, so the schema already documents both parameters ('prefix' and 'limit') with clear descriptions. The description adds no additional parameter semantics beyond what the schema provides, such as examples of prefix usage or details on result ordering. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the tool's purpose: 'Get word completions from a prefix' specifies the verb ('Get') and resource ('word completions'), and 'Useful for autocomplete and spelling suggestions' provides context. However, it doesn't explicitly differentiate from sibling tools like 'find_words' or 'find_related', which might offer similar word-finding functionality.

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 autocomplete and spelling suggestions, giving some context for when to use it. However, it doesn't provide explicit guidance on when to choose this tool over alternatives like 'find_words' or 'find_synonyms', nor does it mention any exclusions or prerequisites for use.

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

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

Annotations declare readOnlyHint=true and destructiveHint=false, so no contradiction. The description adds extensive behavioral details: market resolution, classification, fan-out, response shapes, resolver contract, parent event extraction, news fallback, safety features (low-confidence matching, closed markets, tradeability warnings).

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 with multiple sections. While it front-loads the main purpose, it could be more concise by reducing examples and redundant 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?

Despite no output schema, the description covers response shapes, resolver contract, parent event fields, news fields, and safety behaviors, making it complete for a complex 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%. The description adds meaning beyond schema: explains 'market' accepts slug, URL, or question; 'depth' describes quick vs thorough; 'include_raw' explains when to use true and why.

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

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

The description clearly states that the tool researches a Polymarket bet by pulling Pipeworx data, with specific use cases like 'should I bet on X'. It distinguishes from sibling tools (e.g., polymarket_arbitrage, polymarket_edges) by focusing on a single bet research.

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

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

The description provides explicit use cases (e.g., 'should I bet on X', 'what does the data say about Y') and implies when to use, but does not explicitly mention when not to use or alternatives among siblings.

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

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

With no annotations provided, the description indicates the tool reads data from SEC EDGAR and FDA, returns paired data and URIs, and is non-destructive. However, it lacks details on error handling, latency, or rate limits, leaving some behavioral aspects unspecified.

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-loads the main purpose, and each sentence adds meaningful information without redundancy. It is appropriately sized and well-structured.

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

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

Given the tool's simplicity (two params, no output schema), the description provides sufficient context: it explains input values, returned data and URIs, and efficiency gains. It could be slightly more specific about output format but is largely complete.

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

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

Schema description coverage is 100% (both params have descriptions). The tool description adds value by giving concrete examples (tickers/CIKs for company, drug names) and clarifying the metrics returned per type, enhancing understanding beyond the schema.

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

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

The description clearly states the tool compares 2-5 entities side by side, specifies two entity types (company, drug) with distinct metrics, and notes it replaces multiple sequential calls, distinguishing it from siblings which are unrelated.

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

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

The description clearly implies when to use (comparing entities efficiently) but does not explicitly state when not to use or suggest alternatives. However, no similar siblings exist, so the guidance is adequate.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the search functionality and return format ('most relevant tools with names and descriptions'), but lacks details on performance aspects like rate limits, error handling, or authentication needs. It mentions a specific use case (500+ tools) which adds context, but doesn't cover all behavioral traits like pagination 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?

The description is front-loaded with the core purpose in the first sentence, followed by usage guidance. Both sentences earn their place by providing essential information without redundancy. It's appropriately sized for a search tool with clear structure.

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

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

Given the tool's moderate complexity (search operation with 2 parameters), 100% schema coverage, and no output schema, the description is reasonably complete. It covers purpose, usage context, and return format, though it could benefit from more behavioral details (e.g., how relevance is determined). The absence of an output schema is partially compensated by mentioning what's returned ('tools with names and descriptions').

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

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

Schema description coverage is 100%, so the baseline is 3. The description doesn't add significant parameter semantics beyond what's in the schema (e.g., it doesn't elaborate on query formatting or limit implications). It mentions the tool catalog context which relates to the query parameter, but this is minimal enhancement over the schema's natural language description.

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

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

The description clearly states the tool's purpose with specific verbs ('Search the Pipeworx tool catalog') and resource ('tool catalog'), and distinguishes it from siblings by specifying it returns 'tools with names and descriptions' rather than words or synonyms. It explicitly mentions the catalog context ('Pipeworx tool catalog') which differentiates it from the sibling tools that appear to be linguistic operations.

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

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

The description provides explicit usage guidelines: 'Call this FIRST when you have 500+ tools available and need to find the right ones for your task.' This gives clear when-to-use criteria (large catalog, task-specific tool discovery) and implies alternatives (other tools for smaller sets or different needs). It effectively guides the agent on when to prioritize 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 declare the tool as read-only, open-world, idempotent, and non-destructive. The description adds significant behavioral context: it fans out across multiple sources (SEC EDGAR, XBRL, USPTO, news, GLEIF), returns specific fields (cik, company_name, recent_filings with URIs, fundamentals, patents with API sunset note, news via fallback), and discloses that patents may soft-fail.

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-loads examples and purpose. Every sentence adds value, explaining inputs, outputs, and behavior. Minor redundancy in listing sources but overall well-structured.

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

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

No output schema, so description must detail return values. It lists all returned fields: cik, company_name, recent_filings (up to 5 with URIs), fundamentals (latest 10-K data), patents (with caveat), news (fallback), LEI. Given tool complexity and lack of output schema, description is fully 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?

Schema coverage is 100% (both parameters documented). The description adds value by specifying that value can be a ticker or zero-padded CIK and that names are not supported. It also clarifies that type is currently limited to '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's purpose with examples like 'Tell me about X' and describes it as 'full cross-source profile of a US public company in ONE parallel call.' It distinguishes from sibling tools such as resolve_entity and compare_entities by specifying that it provides a holistic view.

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 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view.' It also advises using resolve_entity first if only a name is available. However, it does not mention when to use sibling tools like compare_entities for comparison tasks.

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

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

With no annotations, the description carries full burden but only covers basic functionality. It doesn't disclose behavioral traits like rate limits, error conditions, response format, or whether results are sorted/filtered. The description is functional but lacks operational context.

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

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

The description is perfectly concise and front-loaded: a single sentence stating the core purpose followed by a comprehensive list of relation types. Every element serves a clear purpose with zero 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 annotations, no output schema, and 3 parameters, the description is incomplete. It explains what the tool does but not how it behaves operationally—missing details on response format, error handling, or performance characteristics that would help an agent use it 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 100%, so the baseline is 3. The description adds minimal value by listing relation types with codes, which the schema already documents clearly. No additional parameter semantics beyond what's in the schema 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?

The description clearly states the specific action ('Find words related to') and resource ('a given word'), with explicit differentiation from sibling tools by listing all relation types. It distinguishes itself from find_rhymes and find_synonyms by being more comprehensive.

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 through the detailed relation type list, suggesting when to use specific codes, but lacks explicit guidance on when to choose this tool over siblings like find_rhymes or find_synonyms. No clear when-not-to-use or alternative scenarios 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool finds and ranks rhymes but doesn't describe what 'score' means, whether results are paginated, error handling, rate limits, or performance characteristics. This leaves significant gaps in understanding how the tool behaves beyond its basic function.

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

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

The description is a single, efficient sentence that front-loads the core purpose ('find words that rhyme') and adds a key behavioral detail ('ranked by score'). There's zero wasted text, making it appropriately sized and easy to parse quickly.

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

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

Given no annotations and no output schema, the description is incomplete for a tool with behavioral complexity. It doesn't explain what 'score' represents, the format of returned results, or any constraints on the input word. For a tool that ranks results, more context about the ranking mechanism and output structure is needed.

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

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

Schema description coverage is 100%, so the schema already fully documents both parameters ('word' and 'limit'). The description adds no additional parameter semantics beyond what's in the schema, such as explaining word format constraints or score calculation. Baseline 3 is appropriate when the schema does all the parameter documentation work.

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 'find' and the resource 'words that rhyme with a given word', specifying the exact function. It distinguishes from sibling tools like 'find_synonyms' or 'find_related' by focusing specifically on rhyming words, not synonyms or related concepts.

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

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

The description provides no guidance on when to use this tool versus alternatives like 'find_synonyms' or 'find_related'. It mentions ranking by score but doesn't explain when rhyming is preferred over other word-finding methods, leaving the agent without contextual usage instructions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds value by specifying that results are 'ranked by similarity score,' which isn't obvious from the name or schema. However, it lacks details on error handling, rate limits, data sources, or output format (e.g., whether it returns a list of strings or structured objects). For a tool with no annotations, this leaves gaps in understanding its behavior.

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

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

The description is extremely concise—a single sentence that efficiently conveys the core functionality. Every word earns its place: 'Find synonyms' states the action, 'for a word' specifies the input, and 'ranked by similarity score' adds critical behavioral context. It's front-loaded with the main purpose.

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

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

Given the tool's moderate complexity (2 parameters, no annotations, no output schema), the description is minimally adequate. It covers the basic purpose and ranking behavior but lacks details on output structure, error cases, or usage distinctions from siblings. Without an output schema, the agent doesn't know what the return values look like (e.g., list of strings vs. objects with scores).

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

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

Schema description coverage is 100%, so the schema fully documents both parameters ('word' and 'limit'). The description doesn't add any parameter-specific information beyond what's in the schema. According to the rules, when coverage is high (>80%), the baseline score is 3 even with no param info in the description.

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

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

The description clearly states the tool's purpose: 'Find synonyms for a word, ranked by similarity score.' It specifies the verb ('find'), resource ('synonyms'), and key behavioral aspect ('ranked by similarity score'). However, it doesn't explicitly differentiate from sibling tools like 'find_related' or 'find_words', which might also involve word relationships.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'find_related' or 'autocomplete', nor does it specify contexts where synonyms are preferred over other word-finding operations. The agent must infer usage from the name and description alone.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the tool as an 'advanced word search' but doesn't mention critical behaviors like whether it's read-only, how results are ordered, if there are rate limits, or what the output format looks like. For a search tool with no annotation coverage, this leaves significant gaps in understanding its operation.

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

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

The description is a single, efficient sentence that front-loads the core purpose ('Advanced word search') and lists the constraint types. It avoids redundancy and wastes no words, though it could be slightly more structured by explicitly separating the constraint categories for easier parsing.

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 of a word search with multiple constraint types, no annotations, and no output schema, the description is incomplete. It doesn't explain how constraints combine (e.g., AND/OR logic), what the return values look like, or behavioral aspects like error handling. This leaves the agent with insufficient context for reliable tool 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% description coverage, so the schema already documents all four parameters (limit, sounds_like, meaning_like, spelled_like) with clear descriptions. The tool description adds value by summarizing the constraint types (meaning, pronunciation, spelling) but doesn't provide additional syntax, examples, or interaction details beyond what the schema offers, 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 tool's purpose as an 'advanced word search' that finds words matching constraints on meaning, pronunciation, and spelling. It specifies the verb ('find') and resource ('words') with the scope of constraints, but doesn't explicitly differentiate from sibling tools like 'find_synonyms' or 'find_rhymes' which might overlap in word-finding functionality.

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

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

The description provides no guidance on when to use this tool versus alternatives like 'find_synonyms' or 'find_rhymes'. It mentions a 'combination of constraints' but doesn't specify scenarios, exclusions, or prerequisites for choosing this over other word-finding tools, leaving the agent to infer usage based on the parameters alone.

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

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

No annotations are provided, so the description carries full burden. While 'Delete' implies a destructive mutation, it doesn't disclose whether this requires specific permissions, whether deletion is permanent or reversible, what happens if the key doesn't exist, or any rate limits. This leaves significant behavioral gaps for a destructive operation.

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

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

The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple tool with one parameter and gets straight to the point without unnecessary elaboration.

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

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

For a destructive tool with no annotations and no output schema, the description is incomplete. It doesn't address important contextual aspects like what 'stored memory' means in this system, whether deletion has side effects, what confirmation or response to expect, or how this tool relates to sibling memory operations.

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

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

Schema description coverage is 100%, so the schema already documents the single 'key' parameter. The description adds no additional meaning beyond what the schema provides, such as explaining what constitutes a valid memory key format or providing examples. Baseline 3 is appropriate when schema does the heavy lifting.

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

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

The description clearly states the action ('Delete') and resource ('a stored memory by key'), making the purpose immediately understandable. However, it doesn't distinguish this tool from potential siblings like 'recall' or 'remember' that might also work with stored memories, preventing a perfect score.

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. With sibling tools like 'recall' and 'remember' that likely interact with stored memories, there's no indication of when deletion is appropriate versus retrieval or creation.

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. Description aligns with these, adds no contradictions but also no extra behavioral context beyond fetching and extracting.

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

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

Three sentences, front-loaded with action and audience, process in second sentence, use cases in third. No fluff, 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?

Given no output schema, the description explains the output format (single text blob) and where to place it. Annotations cover safety and idempotency. Complete for a simple generation 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% and descriptions are already detailed. The tool description repeats some param info (default 25, max 50) and adds context about extraction, but not significant new 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?

Clearly states it generates an llms.txt file for a URL, targeting specific AI crawlers. Distinguishes from siblings like ai_visibility_check and scan_competitor_ai_presence by focusing on file generation.

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

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

Explicitly lists three use cases (client indexing, own project, competitor audit). Could mention when not to use or alternatives, but context is clear.

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

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds return field details and the scope (caller's subscriptions), which is useful but not required 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, no fluff. First sentence states purpose and return format; second provides usage guidance. Highly concise 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 simple tool with one optional parameter and no output schema, the description adequately covers its behavior, return values, and usage context.

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

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

The sole parameter include_inactive is fully described in the schema with 100% coverage. The tool description does not add additional semantics 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 lists the caller's active subscriptions and specifies the fields returned. It distinguishes from siblings 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: to review monitored subscriptions before adding more or to find an id for cancellation, providing clear context.

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

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

With no annotations, the description carries full burden. It discloses rate limiting (5 per day per identifier) and advises describing attempts in terms of Pipeworx tools/data. It doesn't mention authentication or post-submission response, but for a feedback tool, this is adequate.

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 four sentences, front-loaded with purpose, then usage guidelines, then rate limit. Every sentence adds value, and there is no fluff. It is highly concise and well-structured.

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

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

Given the tool has 3 parameters (one nested), no output schema, and is a straightforward feedback tool, the description covers purpose, parameter usage, rate limits, and content restrictions. No critical information is 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 100%, so baseline is 3. The description adds meaning by detailing the 'type' enum options beyond the schema's short descriptions, and adds context about what to include in 'message'. This extra context justifies a 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 sends feedback to the Pipeworx team, listing specific use cases (bug reports, feature requests, data gaps, praise). It distinguishes itself from siblings, which are data retrieval or analysis tools, by being a feedback mechanism.

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 for various feedback types and instructs not to include the end-user's prompt verbatim. It also mentions rate limits. Although it does not explicitly state when not to use it, the context of sibling tools makes the use case clear.

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

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

Annotations already declare readOnly, idempotent, non-destructive. The description adds caching behavior (5min-1h) and data origin (CF analytics, no PII), which are useful beyond annotations.

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

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

Three sentences, front-loaded with purpose, then bulleted use cases. Every sentence adds value, no redundancy.

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

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

Given the tool's simplicity (one optional parameter, read-only, no output schema), the description covers purpose, usage, caching, and data source completely.

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

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

Schema coverage is 100% with the window parameter. The description adds semantic guidance: shorter windows for hot topics, longer for steady-state, which is helpful beyond the schema.

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

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

The description clearly states it returns top tools, packs, and call volume over a window. It distinguishes itself from sibling tools by specifying it is self-aggregating and derived from analytics, not just another entity listing.

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

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

Three explicit use cases are given: discovering hot data sources, confirming canonical choices, and aligning use cases. It lacks explicit alternatives or when-not-to-use, but the use cases are clear enough for an 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?

The description discloses extensive behavioral details beyond annotations: it explains that the tool requires one of two mutually exclusive parameters, describes the semantic anchor (Jaccard similarity >=0.30) and partition filter (placeholder slugs omitted), and specifies the response structure. It does not contradict annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint are all supported).

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 (about 300 words) but every sentence adds important operational detail. It is front-loaded with the critical requirement. While not overly verbose, it could potentially be more concise by structuring into bullet points, but the density is justified by 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 thoroughly explains the response structure (opportunities array with specific fields, partition_check object). It covers edge cases like placeholder slugs and low similarity. The tool has no output schema, so the description compensates fully, making it complete for an AI 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% with descriptions for both parameters, but the description adds significant value by explaining the difference between single-event and cross-event modes, providing usage examples, and detailing how each parameter affects the search and processing logic (e.g., semantic anchor, partition filters). This goes well beyond the schema.

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

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

The description clearly states the tool's purpose: 'Find arbitrage opportunities on Polymarket via monotonicity violations + partition-sum checks.' It specifies two distinct modes (event and topic) and differentiates them effectively. The verb 'find' and resource 'arbitrage opportunities' are specific, and the tool is well-distinguished from sibling tools like polymarket_edges or polymarket_kalshi_spread.

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

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

The description explicitly tells when to use each mode: 'event (recommended for a specific market)' and 'topic (for cross-event scanning)'. It gives examples of event slugs and topic seeds, and warns that calling with no args fails. However, it does not explicitly compare to sibling tools or state when not to use this tool.

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

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

The description provides extensive behavioral detail beyond annotations, including cache behavior ('Cached 1h'), detailed model families (e.g., lognormal barrier, news momentum), tradeable-edge knobs, and diagnostics for empty segments. All align with annotations (readOnlyHint, 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 front-loaded with the purpose but is verbose, exceeding 200 words. The dense technical details could be summarized more concisely without losing key information, making it somewhat burdensome for quick comprehension.

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

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

Given the lack of an output schema, the description thoroughly explains return values: three response segments, diagnostics (including filter skips), warnings (24h-move), and field details. It ensures callers understand empty segments and edge calculation.

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 detailed parameter descriptions. The tool description adds contextual semantics, such as explaining how 'min_partition_leg_kelly' interacts with partition opportunities and the rationale for filter knobs like 'slippage_pp' and 'min_liquidity'.

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

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

The description starts with 'Scan top Polymarket markets and return opportunities where Pipeworx data disagrees with market price,' clearly stating the verb, resource, and unique value proposition. The phrase 'Built for "what should I bet on today"' further distinguishes it from siblings like polymarket_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?

The description explicitly states the use case: 'Built for "what should I bet on today"' and implies it's for daily discovery without paging. However, it does not explicitly mention when not to use the tool or compare it directly to alternative 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?

The description goes well beyond annotations by detailing exact conditions for compatibility_warning (matched_pairs:0 with skipped_cross_type or without), temporal alignment checks, and skipped cross-type/subtype counters. Annotations already indicated read-only and idempotent nature, and the description adds valuable behavioral context about limitations and 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 lengthy but well-structured with clearly labeled sections (TWO MODES, RESPONSE, SAFETY FIELDS). It front-loads the core purpose. Some redundancy could be trimmed (e.g., repeating 'cross-venue spread' multiple times), but overall it's organized for easy scanning.

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

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

Despite lacking an output schema, the description comprehensively explains the response structure: leg-by-leg prices, top_spreads_pp, compatibility_warning with two cases, temporal_alignment, and skipped counters. It covers all relevant aspects for a tool of this complexity, making it self-contained.

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

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

Schema coverage is 100% with descriptions already present, but the narrative description adds significant context: explains topic values as pre-mapped shortcuts, gives examples of explicit ticker formats, and clarifies that explicit parameters override topic-mapped side. This extra semantics justifies above baseline 3.

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

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

The description clearly states the tool computes cross-venue spreads between Kalshi and Polymarket for the same resolving question. It distinguishes from siblings like polymarket_arbitrage (which likely focuses on Polymarket only) by explicitly naming both venues and the cross-venue nature. The verb 'spread' and resource 'cross-venue' are specific and informative.

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 when each is appropriate. It warns that most pre-mapped topics return compatibility_warnings and that spreads are only meaningful when bet shapes are equivalent. However, it does not explicitly state when to avoid the tool (e.g., if no compatible events exist) or provide alternatives, which keeps it from a 5.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: retrieving or listing memories based on the presence of the key parameter, and clarifies persistence across sessions. However, it lacks details on error handling (e.g., what happens if the key doesn't exist) or performance aspects like rate limits, leaving some gaps.

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

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

The description is front-loaded and highly efficient: two sentences that directly convey purpose, usage, and parameter semantics without redundancy. Every sentence earns its place by adding critical information, making it easy for an AI agent to parse and apply.

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

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

Given the tool's moderate complexity (one optional parameter, no output schema, no annotations), the description is mostly complete. It covers purpose, usage, and parameter behavior adequately. However, it lacks details on return values (since no output schema exists) and error conditions, which could help the agent handle edge cases more 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?

The schema description coverage is 100%, so the schema already documents the single parameter 'key' and its optional nature. The description adds meaningful context by explaining the semantic effect of omitting the key ('list all stored memories'), which goes beyond the schema's technical documentation, though it doesn't provide additional syntax or format details.

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

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

The description clearly states the tool's purpose with specific verbs ('retrieve', 'list') and resources ('previously stored memory', 'all stored memories'), distinguishing it from siblings like 'remember' (store) and 'forget' (delete). It explicitly mentions retrieving context saved earlier in the session or previous sessions, making the scope unambiguous.

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

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

The description provides explicit guidance on when to use this tool vs. alternatives: 'Use this to retrieve context you saved earlier in the session or in previous sessions.' It also specifies when to omit the key parameter to list all memories, offering clear operational context without misleading information.

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

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

Beyond annotations (readOnly, idempotent), the description explains that mark_read:true flags events as read, affecting subsequent calls, and that polling works fine. No contradictions are present.

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

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

The description is a single, well-structured paragraph of about 100 words, front-loaded with the tool's action. Every sentence adds essential information without redundancy.

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

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

Given 5 parameters and no output schema, the description adequately explains return fields (source, citation_uri, raw payload), filtering options, and the effect of mark_read. It also mentions the alternative URL for external use, providing complete context for effective use.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value with a concrete type example ('sec_8k') and clarifies the effect of mark_read, improving usability beyond the schema descriptions.

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

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

The description clearly states the tool pulls fired events from the subscription feed, specifies it returns the most recent alerts with key fields (source, citation_uri, raw payload), and is distinct from sibling tools like list_subscriptions or subscribe.

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 filters (type, since) and mark_read behavior, mentions polling suitability, and provides an alternative URL for scripts/dashboards. Lacks explicit when-not-to-use or comparison to siblings, but sufficient context is 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?

The description details the fan-out to SEC, GDELT/GNews with fallback, USPTO with soft-fail, and the return structure (changes grouped by source, total_changes, citation URIs). This adds significant context beyond the annotations (readOnly, openWorld, idempotent, nondestructive) without contradiction.

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

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

The description is detailed but efficiently packed. Every sentence adds value, though the length is slightly above minimal. It is well-structured and front-loaded with 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?

Given the tool's complexity (multiple sources, fallback logic, temporal parameter) and lack of output schema, the description fully covers return format, behavior, limitations, and contrasts with sibling. The rich annotations further enhance 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?

While schema coverage is 100%, the description enriches parameter meaning with examples ('since' accepts ISO or relative shorthand, suggests '30d' or '1m'), clarifies 'value' accepts ticker or CIK, and confirms 'type' is limited to 'company'. This goes beyond the schema's 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 provides a change feed for a company over a specified time window by fanning out to multiple sources. It uses specific verbs and distinguishes itself from the sibling tool '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 lists example queries ('What's new with X', 'latest on Y') and provides a direct alternative ('Use entity_profile instead when you want the static profile'). It also gives practical advice on typical monitoring windows.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: the tool performs a write operation ('store'), specifies storage duration ('persistent memory' vs. '24 hours'), and implies session-scoped memory. However, it lacks details on error conditions (e.g., key collisions) or performance limits, leaving minor gaps.

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

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

The description is front-loaded with the core purpose in the first sentence, followed by usage guidelines and behavioral details. Every sentence adds value—no redundancy or fluff. It efficiently covers purpose, usage, and key behavioral traits in three concise sentences, making it easy to parse.

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

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

Given the tool's moderate complexity (write operation with session memory), no annotations, and no output schema, the description is largely complete. It covers purpose, usage, and key behavioral aspects like persistence rules. However, it lacks details on return values or error handling, which would be beneficial for full completeness.

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

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

The input schema has 100% description coverage, with clear documentation for both 'key' and 'value' parameters. The description adds minimal semantic context beyond the schema, mentioning examples like 'subject_property' and 'user_preference' (which overlap with schema examples) and general use cases. This meets the baseline of 3 since the schema does the heavy lifting.

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

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

The description clearly states the tool's purpose with specific verbs ('store a key-value pair') and resource ('in your session memory'), distinguishing it from sibling tools like 'forget' (deletion) and 'recall' (retrieval). It explicitly mentions what can be stored ('intermediate findings, user preferences, or context across tool calls'), making the purpose unambiguous and distinct.

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

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

The description provides explicit guidance on when to use this tool ('to save intermediate findings, user preferences, or context across tool calls'), and implicitly distinguishes it from alternatives like 'recall' (for retrieval) and 'forget' (for deletion). It also clarifies usage contexts with 'authenticated users get persistent memory; anonymous sessions last 24 hours', offering clear when-to-use criteria.

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

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

No annotations exist, so the description carries full behavioral burden. It discloses that v1 only supports 'company' type, and explains input examples and output fields (ticker, CIK, name, URIs). However, it does not explicitly state that the tool is read-only or mention potential side effects, rate limits, or error behavior.

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

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

The description is a concise two-sentence structure. The first sentence states the purpose, and the second provides versioning, type support, examples, outputs, and benefit. No unnecessary words.

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

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

Given the tool has two required parameters with full schema descriptions, and no output schema, the description adequately covers inputs and outputs. It also explains the tool's efficiency advantage. However, it does not address error cases (e.g., no match found) or potential limitations beyond versioning.

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

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

Schema coverage is 100% with descriptions for both parameters. The description adds significant value by providing concrete examples of valid inputs (e.g., 'AAPL', '0000320193', 'Apple') and detailing the exact output fields, which 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 resolves entities to canonical IDs, specifies the support for company type, and lists accepted input formats (ticker, CIK, name). It also mentions the output and distinguishes itself by stating 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?

The description highlights efficiency (single call, replaces multiple lookups) but does not explicitly address when not to use this tool or mention alternative sibling tools. Context from sibling names suggests alternatives like ask_pipeworx or find_related, but no guidance is provided.

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

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

Annotations already mark readOnlyHint, idempotentHint, destructiveHint as true/false. Description adds that it probes entities with ai_visibility_check, treats first as subject for narrative, and returns a ranked list with specific fields (score, confidence, signal density). This is helpful 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?

Two sentences: first states the core purpose, second adds usage context and example. No wasted words, all information is essential and well-structured.

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

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

Describes return value structure (ranked list with score, confidence, signal density per entity). Parameters and behavior are adequately covered given the tool's moderate complexity. Could mention error handling or limits, but current description is sufficient for basic understanding.

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

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

Schema coverage is 100% with descriptions for all 4 parameters. Description adds value by clarifying that the first entity in the 'entities' array is treated as the 'subject' for narrative, which is not in the schema description.

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

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

The description explicitly states 'Compare AI visibility across multiple entities side-by-side' with verb 'compare' and resource 'AI visibility'. It distinguishes from sibling ai_visibility_check by noting it probes multiple entities and ranks 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?

Provides concrete use case ('competitive AI-marketing audits') and example question ('does Claude know about us as well as our competitors?'). Implicitly differentiates from ai_visibility_check by mentioning it probes each entity with that tool, but does not explicitly state when not to use or list alternatives like compare_entities.

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

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

Beyond annotations (readOnly, idempotent, openWorld), the description details behavioral traits: composite nature, data sources, partial failure degradation, potential 5-30s timeout on bundlephobia first measurement, and the fact that sources_failed field will list timed-out sources. No contradictions with annotations.

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

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

Description is fairly long but well-structured: first sentence defines the composite check, second gives usage guidance, third lists return fields, fourth explains ecosystem limits and partial failures. Every sentence adds necessary context, 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?

Given the tool's complexity (two data sources, multiple return fields, potential partial failures), the description is comprehensive. It covers return format, failure behavior, and ecosystem limits, leaving no critical gaps. Output schema is not needed as the description suffices.

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 noting that scoped packages (e.g., '@types/node') are accepted, which is not in the schema. This extra context justifies a slightly higher 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?

Description clearly states the tool's purpose as a composite check for npm packages, combining data from deps.dev and bundlephobia to answer if a package is safe, popular, or small. It explicitly distinguishes from sibling tools by specifying its NPM-only scope and directing other ecosystems to deps.dev:version directly.

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

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

Explicitly states when to use the tool ('is X safe / popular / small' or 'what does adding lodash cost me') and when not to (non-NPM packages), providing clear exclusions and alternatives. The description also mentions graceful partial failures, guiding agent expectations.

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, openWorld, idempotent. Description adds specific technical details: BGE-base-en embeddings, 500-char windows, 200K char cap with truncation flag, and that each passage includes offsets for verification. 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?

One well-structured paragraph with front-loaded core action. Every sentence adds essential information: when to use, what it returns, pairing advice, technical details. No redundancy.

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

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

Despite lacking an output schema, the description fully explains what is returned (passages with offsets and scores), the underlying mechanism, and constraints (200K char cap). Provides all necessary context for an agent to use 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 baseline is 3. Description adds value beyond schema by explaining the semantic search nature, return format (offsets, scores), and providing concrete query examples, raising it to 4.

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

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

Clearly states it performs semantic search inside a fetched record, returning top-N passages with offsets and scores. Distinguishes from siblings like ask_pipeworx_grounded by specifying its complementary role.

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

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

Explicitly says 'Use when the record is too big to cram into the prompt' and describes pairing with ask_pipeworx_grounded, giving clear context for when to use this tool versus alternatives.

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

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

Beyond the annotations (readOnlyHint=false, etc.), the description adds important behavioral traits: returns a subscription ID, requires authentication, details on delivery channels with limitations (SMS cap of 10/day, phone verification), and idempotency hint is not contradicted. This adds considerable 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 front-loaded with the core purpose and requirements, then expands on types and delivery. Every sentence adds value, though it is somewhat lengthy. It could be slightly tighter, but the structure is logical and efficient.

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

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

Given the complexity (multiple types, delivery channels, no output schema), the description covers essential aspects: requirements, return value (subscription ID), rate limits, and verification steps. It adequately prepares the agent for correct invocation, though a brief note on how to handle the returned ID could further enhance 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?

While the schema already covers 100% of parameters, the description enriches them with concrete examples for each subscription type (e.g., 'items:["5.02"]' for sec_8k) and delivery options (email/SMS with validation notes). It adds practical meaning beyond the schema's generic descriptions.

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

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

The description clearly states the tool's verb ('Create') and resource ('proactive monitoring subscription to a live-data event stream'), and distinguishes it from siblings like 'list_subscriptions' and 'unsubscribe'. The purpose is 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 explains prerequisites (Pipeworx OAuth account) and supported types/delivery channels, but does not explicitly contrast with siblings (e.g., 'use list_subscriptions to view existing ones' or 'use recent_alerts to pull from feed'). The guidance is good but not exhaustive on when to use this vs. 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?

Discloses soft-deletion behavior and historical availability, adding context beyond annotations; 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?

Two sentences, front-loaded with action and constraint, 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?

Simple one-param tool fully described: purpose, usage constraint, behavioral effect, and mention of historical availability.

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 'id' described; description adds no extra meaning, meeting baseline.

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 verb 'cancel' and resource 'subscription by id', distinguishes from siblings like subscribe and list_subscriptions.

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

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

Explicit ownership enforcement guides when to use (own subscriptions) and implies when not to, though alternative tools not named.

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, so the description adds beyond that by specifying the data source (SEC EDGAR + XBRL), the return format (verdict, structured form, citation), and efficiency gain. 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 example query phrases for quick identification, then succinctly covers purpose, domain, return format, and efficiency. Every sentence adds value with 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?

Despite no output schema, the description fully covers return types (verdict categories), citation mechanism, and percent delta. It also explains the tool's composite nature. Given the simplicity and annotation coverage, 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?

Schema coverage is 100% with a detailed parameter description including examples. The tool description reinforces the parameter's purpose but doesn't add significant new semantics beyond the schema. Baseline 3 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 the tool's purpose as natural-language claim verification with specific verbs like 'verify', 'fact check', 'confirm or refute'. It distinguishes from sibling tools by specifying its domain (company-financial claims) and that it replaces multiple sequential calls.

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

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

The description explicitly says 'Use whenever the agent needs to check whether something a user said is factually correct' and provides triggering phrases. It also notes the domain limitation (v1 supports company-financial claims). However, it doesn't explicitly mention alternative tools or when not to use, though the domain scope implies limitations.

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