Tenor

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

Beyond annotations (readOnly, idempotent, etc.), the description adds that results include per-model {score, confidence, signals, raw_response} plus a combined view, and that Anthropic calls require a BYO key with direct payment to Anthropic. This provides useful behavioral context beyond the annotations.

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

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

The description is two sentences, front-loaded with the primary function, and every sentence adds value. No redundancy or filler.

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

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

The description covers all parameter semantics, usage scenarios, output structure, and behavioral nuances (cost, required key). Given no output schema, it fully explains return values. No gaps identified.

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 explaining that the default model is Workers AI Llama-3.3-70b (free) and that _apiKey is only needed for Anthropic. It also clarifies that 'context' helps disambiguate entities, 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 clearly states the tool probes LLMs about an entity and scores visibility (0-100) per model, with a specific verb ('probe') and resource ('LLMs for what they know'). It differentiates from siblings like 'scan_competitor_ai_presence' by focusing on general AI visibility rather than competitor-specific scanning.

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

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

Provides explicit use cases ('AI-marketing audits, pre-launch brand checks, competitive monitoring') and clarifies when to use the optional _apiKey parameter (for Anthropic models). However, it does not explicitly state when not to use the tool or compare it to 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?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds behavioral context: it routes to one of 5,529 tools, fills arguments, returns stable pipeworx:// citation URIs, and 'works on every tier'. No contradiction with annotations, and it goes beyond the structured fields to explain internal routing 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 long but front-loaded with the most critical guidance ('PREFER OVER WEB SEARCH') and maintains a logical flow: scope, usage triggers, examples, escalation. A few redundant phrase lists ('what is', 'look up', etc.) could be tightened, but every sentence contributes to usage understanding, so it earns a 4 rather than 3.

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

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

For a tool that routes to over 5,000 sub-sources with no output schema, the description is remarkably complete. It covers what it does, when to use it, what it returns (structured answer with citations), and how it compares to alternatives. Given the tool's complexity, no important context 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 has 6 parameters, all aliases for 'question', with 100% coverage. The description adds value by providing natural-language question examples that illustrate how to use the tool, complementing the schema's alias documentation. It doesn't need to repeat parameter details since schema is clear, but the examples push it above 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?

The description states 'Routes the question to the right one of 5,529 tools across 1455 verified sources' and lists concrete domains (SEC filings, FDA, FRED, etc.). It distinguishes from siblings by naming ask_pipeworx_grounded and deep_research as escalation paths, making its specific role clear.

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 'PREFER OVER WEB SEARCH' and 'START HERE for most questions', then gives detailed when-to-use triggers ('what is', 'look up', 'find', etc.) with examples. It also tells when to step up to alternatives ('for a hallucination-resistant single answer... use ask_pipeworx_grounded; for a broad/multi-part question... use deep_research'). This is exemplary guidance.

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

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

Annotations already declare read-only, idempotent, open-world, and non-destructive behavior. The description goes beyond this by disclosing 'falls back to nothing' (no fallback to a different tool), the experimental nature, and that no candidate is currently active. This adds meaningful context about runtime behavior and current state without contradicting the annotations.

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

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

The description is three sentences and front-loaded with the key purpose ('Beta version of ask_pipeworx'). It includes useful details like the date of the last retired candidate and the comparison process, though these could be seen as slightly verbose. Every sentence earns its place, but some redundancy exists ('identical' and 'matches exactly' in two sentences).

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

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

The tool is a complex router with no output schema, but the description notes 'same response shape' as ask_pipeworx, leveraging the sibling for return format details. It does not independently describe the response shape, which could be insufficient if the agent does not know ask_pipeworx. However, the description covers the tool's current behavioral state (no active candidate, full working router) well enough for a beta variant.

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 is fully documented with a description for every property (100% coverage), so the schema carries the parameter semantics. The description only says 'same arguments' as ask_pipeworx, which adds no additional meaning beyond what is already in the schema. Baseline of 3 is appropriate.

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

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

The description clearly states it is a beta version of ask_pipeworx, a universal router that handles the same 5,529 tools and arguments. It explicitly distinguishes from the stable sibling by calling out the experimental routing improvements, making the purpose 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?

Provides explicit guidance: 'Use it exactly like ask_pipeworx when you want the newest routing.' This tells when to choose this tool over the stable alternative, and the comparison process is explained. It also clarifies that results are used for evaluation, which is valuable context for the agent.

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

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

The description goes well beyond annotations by detailing the exact response contract: success returns {answer, evidence, confidence, source, fetched_at, refusal_reason:null}, while failure returns an explicit refusal with specific refusal_reason enums. It also discloses the cost tradeoff (extra LLM call) and the guarantee of using only tool result content. Annotations are consistent, with no contradiction.

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

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

The description is dense but every sentence earns its place: purpose, mechanism, output contract, refusal cases, use cases, and cost comparison. It front-loads the core value and uses structured inline examples (e.g., refusal_reason enums) to avoid ambiguity.

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

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

Given the tool's complexity and the absence of an output schema, the description fully compensates by detailing success and failure return shapes, refusal reasons, and the relationship to ask_pipeworx. It also covers practical constraints (extra LLM call, high-stakes use cases) and the routing context, making it self-sufficient for an agent.

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

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

Schema description coverage is 100%: the schema already document the 'question' parameter and all five aliases. The description adds no new parameter-specific semantics beyond mentioning 'fills arguments' generically. Baseline 3 is appropriate because schema carries the load.

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

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

The description opens with a specific, distinctive purpose: 'Hallucination-resistant answer mode for high-stakes reads.' It clearly states the tool's verb (extracts answers using only tool result) and resource (Pipeworx tool routing across 5,529 tools/1455 sources), and explicitly differentiates from sibling ask_pipeworx by noting the grounding mechanism and extra LLM call.

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 when-to-use guidance is given: 'Use whenever an answer will be quoted, cited, or acted on, and the agent must not invent facts.' It also provides a clear alternative and when-not-to-use: 'Costs one extra LLM call vs ask_pipeworx — prefer ask_pipeworx for casual lookups.' This fully orients the agent.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds that results are 'ordered by popularity' and returns up to 'limit' completions. This adds some behavioral context beyond annotations, but does not disclose auth needs, rate limits, or error handling. Given rich annotations, a score of 3 is appropriate.

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

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

Single sentence, front-loaded with key information. Every word serves a purpose. No redundancy.

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

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

For a simple autocomplete tool with an output schema, the description covers core functionality. However, it fails to explain two parameters ('locale', 'client_key'), and lacks usage context. Given annotations and output schema exist, it is minimally adequate but has clear gaps.

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

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

Schema coverage is 0%, so description must explain parameters. It explains 'q' as 'partial search term' and 'limit' as 'up to limit completed search phrases'. However, 'locale' and 'client_key' are not mentioned. The description adds some meaning beyond the schema but leaves two of four parameters unexplained.

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

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

Description clearly states it returns autocomplete completions from Tenor for a partial search term, ordered by popularity. It specifies the resource (Tenor autocomplete) and the action (return completions). While it does not explicitly distinguish from siblings like 'search_suggestions', 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?

No guidance on when to use this tool versus alternatives such as 'search_suggestions' or 'trending_terms'. The description implies usage for autocomplete but lacks explicit context for when-not-to-use or comparison with similar tools.

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

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

The description is exceptionally transparent, detailing fan-out behavior, response shapes, resolver contracts, parent event extraction, news fields with fallback mechanisms, safety short-circuits for low-confidence and closed markets, spread warnings, and resolution-rule risk. All beyond annotations, which are readOnly, openWorld, idempotent, non-destructive. No contradictions.

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

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

The description is lengthy but well-structured, front-loaded with core purpose. Every section adds necessary detail, though it could be slightly more concise without losing critical information.

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

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

Given the tool's complexity (multiple classifiers, fan-outs, response fields, edge cases) and absence of an output schema, the description is remarkably complete. It covers fan-out examples, response shapes, safety mechanisms, and resolution rules, leaving no essential context 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?

With 100% schema coverage, the baseline is 3. The description adds value by clarifying usage nuances (e.g., default depth, when to use include_raw) and providing examples, but much of the parameter information is already in the schema.

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

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

The description explicitly states it researches Polymarket bets by pulling Pipeworx data in one call. It specifies inputs (slug, URL, question text) and outputs (evidence packet, market-vs-model comparison), with clear verb and resource. It distinguishes from siblings like 'polymarket_edges' by focusing on comprehensive 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 ('should I bet on X', 'what does the data say', 'is there edge in Z') and lists classifiers and fan-out examples. However, it does not explicitly exclude scenarios or differentiate from sibling tools, which would strengthen the guidelines.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds context about filterable parameters and representative previews, but does not disclose rate limits, data freshness, or other behavioral traits beyond the annotations.

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

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

Single sentence efficiently conveys the tool's purpose, key features, and filter options. No redundancy or unnecessary detail.

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

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

While the output schema exists (reducing need to describe returns), the description lacks details on parameter values and cannot fully guide an agent on correct inputs. The tool is simple but parameter semantics are missing.

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

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

Schema coverage is 0%, so description should fully explain parameters. It mentions locale, type, and content safety level as filter options, but does not specify allowed values, formats, or defaults for any parameter.

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 states it returns Tenor's GIF browse categories with representative previews, which is clear. However, it does not explicitly differentiate from sibling tools like search_suggestions or trending_terms, leaving room for ambiguity.

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

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

Description provides no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. It only implies usage for browsing categories.

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

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

Adds substantial detail beyond annotations: data sources (SEC XBRL, FAERS), metrics pulled, handling of fiscal years, sorting, 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?

Description is packed with useful info but slightly lengthy. Front-loads purpose and examples. Each sentence adds value, but could be more concise.

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

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

No output schema, but description explains return type (paired data + citation URIs) and sorting. For a two-parameter comparison tool, covers all necessary context.

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

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

Schema coverage is 100%, but description adds meaning: examples of query patterns for type, explanation of values with tickers/CIKs and drug names, and min/max constraints.

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 'side-by-side comparison of 2–5 companies or drugs in ONE parallel call' with specific verbs and resources. Distinguishes from sibling tools by recommending over sequential lookups.

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

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

Provides explicit guidance: 'ALWAYS PREFER over sequential single-pack lookups when comparing entities.' Also lists example queries. Does not include negative cases but strong positive guidance.

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

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

Beyond annotations (readOnly, openWorld, idempotent), the description discloses important behaviors: account/payment requirements, that it returns gaps[] for unanswered facets and 'never invented' content, citation format with pipeworx:// URIs, semantic excerpting of large records, second-hop gap recovery, contradiction detection, and expected latency. 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?

Although long, every sentence adds unique value and the description is densely packed with essential operational details (preconditions, alternatives, behavior, limitations, timing). It is front-loaded with the critical account requirement and the key 'NOT open-web search' caveat. No redundant filler.

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

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

For a complex tool with no output schema, the description is remarkably complete: it explains the return packet (verbatim evidence, confidence, source, fetched_at, citation, gaps, contradictions, hop), the time expectations, the difference from siblings, and the depth options. Given the tool's complexity, this is fully sufficient for an agent to select and invoke correctly.

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

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

Schema coverage is 100%, but the description adds significant meaning beyond the schema: depth levels are elaborated (quick=3, standard=5 with gap recovery, thorough=8 with iterative hops), and the 'question' parameter is described as broad/multi-part fine because decomposition is the point. This exceeds the baseline and fully clarifies parameter intent.

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

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

The description uses a specific verb+resource: 'Grounded multi-source research across Pipeworx's 1455 STRUCTURED data sources' and explains the mechanism ('Decomposes your question into focused facets, routes each to the right one of 5,529 tools IN PARALLEL, and returns a findings packet'). It clearly distinguishes from siblings, notably asking to 'use ask_pipeworx instead' for single lookups, and the contrast with open-web search is explicit.

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

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

Provides explicit when-to-use: best for broad/multi-part questions over structured data. Gives multiple exclusions and alternatives: if not signed in use ask_pipeworx, for single lookup use ask_pipeworx, for breaking/news topics prefer ask_pipeworx. Also explains depth-level usage for multi-step questions. This is exemplary usage guidance.

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

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

Annotations (readOnlyHint, idempotentHint) are already present. The description adds valuable behavioral context: returns top-N tools with full schemas and curated examples, ready to call directly. 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 comprehensive and front-loaded with the core purpose, but slightly verbose with the long list of domains. Still, every sentence adds value, and structure is clear.

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

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

Tool is simple with no output schema, but the description fully explains return values (tool names, descriptions, schemas). Parameter coverage is 100%. No gaps given tool complexity.

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

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

Schema coverage is 100%, so baseline is 3. The description does not add extra meaning beyond the schema's parameter descriptions. It mentions aliases, but schema already covers them. No additional param documentation needed.

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

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

The description states 'Find tools by describing the data or task' with specific examples of domains (SEC filings, FDA drugs, etc.). It clearly distinguishes itself from sibling search tools by focusing on tool discovery and returning full schemas for immediate use.

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 'Call this FIRST when you have many tools available' and provides specific use cases like browsing or searching for tools. This gives clear when-to-use guidance and implies it's a starting point before using other tools.

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

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

Annotations declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral detail: fans out across multiple sources, returns specific fields with sorting, mentions patent soft-failure (USPTO sunset May 2025), and news fallback (GDELT→GNews). 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?

Single dense paragraph front-loaded with examples and purpose. Every sentence adds value, but the description could be slightly more concise by grouping related details. Still efficient for the information provided.

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 data sources, many return fields) and no output schema, the description comprehensively covers what is returned (cik, company_name, recent_filings with URIs, fundamentals sorted, patents, news, LEI), ordering, fallbacks, and limitations. No gaps.

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

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

Schema coverage is 100% with descriptions for both parameters. The description adds context: 'value' can be ticker or zero-padded CIK, and 'names not supported' (use resolve_entity). This enhances understanding beyond the schema but is somewhat redundant.

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

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

The description clearly specifies that the tool provides a cross-source profile of a US public company, listing data sources (SEC EDGAR, XBRL, USPTO, news, GLEIF) and return fields. Example queries (e.g., 'tell me about X', 'research Acme') make it highly scoped and distinguishable from siblings like 'compare_entities' or 'deep_research'.

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

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

Explicitly states 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view.' Also specifies that names are not supported and directs to 'resolve_entity' first, providing clear when-to-use and when-not-to-use guidance.

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

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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds context about the return format (media URLs and metadata) and supported features like pagination, going beyond annotations.

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

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

The description is a single, dense sentence with no fluff. It efficiently conveys the core purpose and capabilities.

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

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

Given the presence of an output schema, the description adequately covers the return type ('media URLs and metadata'). All parameters are optional, and the tool's read-only nature is clear. Minor gap: no mention of default behaviors for omitted parameters.

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

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

With 0% schema description coverage, the description attempts to compensate by listing parameter categories (locale, content filter, aspect-ratio range, pagination). However, it does not provide detailed semantics for each of the 6 parameters, leaving some ambiguity.

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

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

The description clearly states the verb 'Fetch' and the specific resource 'Tenor's current editorially featured GIFs', distinguishing it from sibling tools like 'categories' or 'search'. The scope is well-defined.

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

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

The description implies usage for fetching featured content with various filters, but does not explicitly state when to use this tool versus alternatives or provide exclusions.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true. Description adds context about clearing sensitive data but doesn't detail effects like irreversible deletion. 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, zero waste. Every sentence adds value.

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

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

For a simple destructive tool with one parameter, no output schema, description covers purpose, usage, and pairing completely. No gaps.

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

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

Schema coverage is 100% with one parameter described as 'Memory key to delete'. Description adds no extra semantics beyond the schema, meeting baseline for high coverage.

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

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

Description clearly states 'Delete a previously stored memory by key' – specific verb and resource. Distinguishes from siblings 'remember' and 'recall'.

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: 'context is stale, task is done, or want to clear sensitive data'. Mentions pairing with 'remember' and 'recall', providing guidance on alternatives.

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

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

Annotations already indicate read-only, open-world, idempotent, non-destructive behavior. The description adds transparency by detailing the fetch-extract-emit process and the output format, complementing the annotations without contradiction.

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

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

Three sentences that efficiently cover purpose, process, and use cases. No unnecessary words; each 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 the tool's simplicity (2 params, no output schema) and rich annotations, the description covers purpose, process, output format, and use cases. Could mention error handling or output details, but it's largely complete for its complexity.

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

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

Schema coverage is 100%, so both parameters (url, max_links) are fully described in the schema itself. The description adds no additional meaning beyond what the schema provides, meeting the baseline of 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 it generates a production-ready llms.txt file for any URL, specifying the verb (generate) and the resource. It distinguishes from siblings like 'scan_competitor_ai_presence' by focusing on file generation, not analysis.

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

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

The description lists three specific use cases (indexing a client's site, drafting your own, auditing competitors). While it doesn't explicitly state when not to use or provide alternatives, the guidance is clear and contextual.

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, destructiveHint, idempotentHint, and openWorldHint. The description adds the list of return fields and the default active-only scope, providing minor additional 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?

Two well-structured sentences: first defines purpose and output, second gives usage guidance. No extraneous words. Highly 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?

For a simple list tool with one optional parameter and no output schema, the description is fully complete. It explains functionality, return fields, and use cases. All necessary information is present.

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

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

Schema coverage is 100% with a clear description for the lone parameter (include_inactive). The tool description does not add new parameter information beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description clearly states the verb 'List', the resource 'subscriptions', and scope 'caller's active'. It also specifies the returned fields, distinguishing it from sibling tools like subscribe and unsubscribe.

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

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

Explicit guidance: 'Use this to review what you're monitoring before adding more or to find an id to cancel.' This tells when to use the tool and hints at alternatives (subscribe to add, unsubscribe to cancel).

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

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

Annotations are all false, providing no safety/behavioral signals, so the description carries the full burden. It discloses meaningful behaviors beyond the obvious send action: filing returns a claim_token for later inquiry, invocation with claim_token alone reads status, rate limiting (5/day/identifier), quota exemption, and operational cadence (digests read daily). This gives the agent a clear behavioral model without contradicting annotations.

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

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

The description is long but nearly every sentence adds operational value, from the core purpose in the first sentence to the rate limit and quota note at the end. It is front-loaded and well-ordered, but slightly verbose with motivational context ('signal directly affects roadmap') that, while useful, is not strictly necessary.

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

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

With 4 parameters, no output schema, and nuanced usage rules, the description fully covers the tool's lifecycle: what it does, when to use it, what to avoid, how to follow up with a claim_token, and rate limits. The nested context object is explained in the schema, and the description compensates for the missing output schema by describing the token return. Nothing significant is left unaddressed.

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

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

Although the schema covers 100% of parameters with descriptions, the description adds semantics beyond schema: it explains the claim_token lifecycle concretely with an example call, and instructs what the message should contain ('Describe the issue in terms of Pipeworx tools/packs — don't paste the end-user's prompt'). This elevates the minimal value above the baseline 3.

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

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

The description opens with a specific verb+resource: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It immediately enumerates the exact feedback types (bug, feature/data_gap, praise), making the tool's scope unmistakable. This clearly distinguishes it from all sibling tools, none of which are feedback-related.

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 when-to-use guidance is provided: 'Use when a tool returns wrong/stale data (bug), when a tool you wish existed isn't in the catalog (feature/data_gap), or when something worked surprisingly well (praise).' It also gives a strong when-not-to-use with a specific alternative: 'if the tool came from a different MCP server... file it with that server instead.' This is model behavior for usage guidance.

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

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

Description adds value beyond annotations by disclosing: self-aggregating signal, no PII, caching behavior (5min-1h window-dependent). No contradictions with readOnlyHint, openWorldHint, etc.

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

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

Two sentences plus three bullet points. Front-loaded with key output, no filler. Every sentence adds value.

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

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

No output schema, but description adequately explains return format (top tools, top packs, call volume). Could clarify if results are paginated or limited, but for a compact trending tool this is sufficient.

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

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

Single parameter 'window' has enum and description in schema (100% coverage). Description adds context on 'shorter windows surface what's hot right now; longer windows show steady-state demand' – helpful nuance beyond schema.

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

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

Description clearly states 'Returns the top tools, top packs, and total call volume' with specific window options. Distinguishes from siblings like ask_pipeworx and trending_terms by being an analytics-only, read-only tool.

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

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

Lists three concrete use cases (discovering hot data sources, confirming canonical tool, seeing alignment) and explains window trade-offs. Could be improved by explicitly mentioning when not to use, but sufficient for typical agent decision.

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

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

Annotations indicate read-only, open-world, idempotent, and non-destructive. The description adds extensive behavioral context: details on checking order, partition sums, placeholders, fill check with realizable edge, and semantic anchor for similarity. No contradictions.

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

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

The description is dense but well-structured: starts with purpose, then mode guidance, detailed mode explanation, fill check, and response structure. Slightly verbose but not wasteful; front-loads key info.

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

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

Despite no output schema, the description explains the response structure (opportunities array with fields, partition_check object in event mode) and fill check behavior. All parameter modes and edge cases (placeholders, similarity) are addressed. Comprehensive 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% with parameter descriptions. The description goes beyond by providing examples (event slugs, topic seed questions), noting that full URLs are accepted for event, and explaining the cross-event scanning behavior for topic.

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 finds arbitrage opportunities on Polymarket via monotonicity violations and partition-sum checks. It distinguishes from siblings like polymarket_edges and polymarket_edge_tracker by specifying the unique methods and modes (no args, event, topic).

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

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

Provides explicit guidance on when to use each mode: no args for trending scan, event for specific event slug, topic for cross-event scans. Explains the benefits of each but lacks explicit when-not conditions.

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

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

The description reveals extensive behavioral details: the three model families with specific formulas, caching behavior (1h at KV level), diagnostic outputs explaining empty segments, and even corner cases like Fed bets excluded from ranking. All annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint) are consistent, with the description adding significant context beyond them.

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

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

The description is verbose but well-structured with clear sections (model families, response structure, knobs). It front-loads the primary purpose. While every sentence adds value, the density of technical detail may slightly reduce readability. Still, appropriate for the complexity.

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

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

Given 9 parameters, no output schema, and complex behavior, the description is exceptionally complete. It explains the three response segments, top-level fields including diagnostics, caching, and even specific model parameters like alpha values. There are no gaps in understanding what the tool returns or how to use it.

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

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

Schema coverage is 100%, but the description adds substantial context: for example, slippage_pp explains Polymarket's zero fees and typical bid/ask spread, min_kelly clarifies it filters 'opportunities that are too small to bet sensibly', and min_partition_leg_kelly addresses the nuance that partition arbs return zero parent Kelly. This goes well beyond the schema definitions.

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

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

The description starts with 'Scan top Polymarket markets and return opportunities where Pipeworx data disagrees with market price' which clearly states the tool's function. It distinguishes from siblings like polymarket_arbitrage by focusing on multi-factor edge detection across three segments, and explains its intended use for daily betting discovery.

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

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

The description includes 'Built for "what should I bet on today" — agents discover opportunities without paging hundreds of markets', indicating when to use. It also references tradeable-edge knobs (min_liquidity, max_spread_pp) as filters. However, it does not explicitly state when not to use this tool or mention alternatives.

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

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

Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds behavioral details beyond these: history limited by 60-day TTL, decay computed from daily closes (not intraday), and snapshot gaps indicating days without scans. This provides useful context beyond the annotations.

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

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

The description is detailed but well-structured, starting with the core purpose. Every sentence adds value, though the response format description could be slightly more concise. Overall, it is front-loaded 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 tool has only two simple parameters and no output schema, the description provides full context: it explains the response fields, boundaries (TTL, snapshot gaps), and computation details. It leaves no significant ambiguity for an AI agent.

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

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

Schema coverage is 100% with both parameters documented. The description adds rich meaning: 'days' is explained as lookback with default and max range, 'window' as snapshot family with examples. Moreover, the description thoroughly explains the response structure (tracked, expired, snapshot_dates), compensating for the lack of an output 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 provides 'edge persistence and decay telemetry' from daily snapshots, answering specific questions about edge age and trend. It distinguishes itself from siblings like 'polymarket_edges' by focusing on historical analysis rather than raw snapshots.

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

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

The description gives clear context on when to use the tool (to assess edge persistence and decay) and includes a contrast between fresh and old edges, implying when it is valuable. However, it does not explicitly mention when not to use it or name alternative tools for other scenarios.

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

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

Annotations indicate it's a read-only, open-world, idempotent check. The description adds behavioral details: it walks the order book ladder, returns specific fields (top_of_book, vwap_fill_price, slippage_pp, etc.), and explains basket mode's forced_directional_risk. 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 well-structured with section headers (SINGLE-MARKET, BASKET, USE THIS) and front-loaded key information. While somewhat verbose, the length is justified given the complexity of two modes and multiple return fields. Minor wordiness could be trimmed.

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

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

For a tool with 4 parameters, full schema descriptions, and no output schema, the description covers expected return fields (verdict, fill details, capture_ratio, etc.) and provides sufficient context for an agent to understand when and how to invoke it.

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

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

Schema coverage is 100% with parameter descriptions. The description adds meaning beyond schema: explains default values (size_usd=1000, side default for basket is auto), clarifies interpretation differences for size_usd between modes, and provides context for event/market slug vs URL.

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 performs a 'realizable-vs-theoretical edge check against live CLOB order-book depth' for both single-market and basket modes. It explicitly differentiates from siblings like polymarket_arbitrage and polymarket_edges by advising to use this tool before acting on their signals.

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: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500'. It also details when to use single-market vs basket mode and warns about the risk of partial basket fills converting an arb into an unhedged directional position.

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 behavior beyond annotations: it explains the two compatibility_warning cases, temporal_alignment, and skipped counters. It also notes that real spreads are rarer than the shortcut list suggests and that when bet shapes are not equivalent, the tool says so. This aligns with readOnlyHint and idempotentHint while adding valuable 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 long but dense with useful information. It is front-loaded with purpose and modes, then details response fields and safety warnings. Every sentence adds value, though it could be more structured with bullet points for modes.

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

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

Given no output schema, the description explains return values (leg-by-leg prices, top_spreads_pp, compatibility_warning, temporal_alignment, skipped counters). It covers response fields and safety indicators well, though it does not mention potential pagination or limits.

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

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

Schema coverage is 100%, and the description adds meaning: defines allowed topic values, explains that kalshi_event_ticker and polymarket_event_slug override topic-mapped sides, and provides example values. This enriches the schema descriptions significantly.

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

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

The description clearly states the tool computes 'cross-venue spread between Kalshi and Polymarket for the same resolving question'. It specifies two modes (topic shortcuts and explicit pairings), and the title and opening sentence immediately convey the unique cross-venue function, distinguishing it from siblings like polymarket_arbitrage and polymarket_edges.

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

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

The description explains when to use topic shortcuts vs explicit tickers, and warns that most pre-mapped topics return compatibility_warning, so not all are tradeable. It does not explicitly contrast with sibling tools, but provides clear context for tool usage and limitations.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive nature. The description adds behavioral context by specifying the comma-separated IDs format and the return purpose (re-resolving media URLs and metadata). It does not introduce contradictions or undisclosed destructive behaviors, and the added context is valuable beyond annotations.

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

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

The description is a single, well-structured sentence that front-loads the primary action. It is concise with no redundant wording, and every piece of information (resource, scope, use case) contributes to understanding.

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

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

The tool has a simple 3-parameter schema, a comprehensive annotation set (read-only, idempotent, non-destructive), and an output schema. The description covers the main purpose and usage context, and it adds the comma-separated detail. It does not need to explain return values due to output schema; the only minor gap is no mention of optional parameters, but their names are self-explanatory.

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

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

Schema description coverage is 0%, so the description must compensate. It provides the comma-separated format for the 'ids' parameter, which is not in the schema. However, it does not explain 'client_key' or 'media_filter', leaving these parameters without additional semantics. Partial compensation, hence a 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 uses a specific verb 'Fetch' and clearly states the target resource (Tenor GIFs/stickers) and scope (by post IDs). It explicitly distinguishes from sibling tools like search and featured by noting it re-resolves results from those tools, indicating a unique purpose.

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

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

It explicitly states when to use the tool: 're-resolve media URLs and metadata for results returned earlier by search or featured.' This gives clear context for usage, though it does not explicitly list when-not-to-use or alternative tools; however, the mention of search/featured as the source of IDs implies this is not for discovery.

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, idempotentHint, and non-destructive behavior. The description adds context about scoping to an identifier and the dual behavior with/without the key argument, which goes beyond annotations.

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

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

The description is three sentences long, front-loads the core function, and provides examples and pairing info without unnecessary detail. Could be slightly more structured but is efficient.

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

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

For a simple read tool with one optional parameter and no output schema, the description covers retrieval of a specific key or listing all keys, scoping, and pairing. No critical missing information.

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 clearly documents the 'key' parameter. The description restates the omit-to-list behavior but does not add new semantic information beyond the schema.

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

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

The description clearly states the action ('Retrieve a value previously saved via remember, or list all saved keys') and the resource (memory values). It distinguishes itself from siblings like 'remember' and 'forget' by explicitly naming them.

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

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

The description provides specific use cases (look up context like ticker, address, research notes) and scoping details ('Scoped to your identifier'). It mentions pairing with remember and forget but does not explicitly state when to avoid using 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 discloses that setting mark_read:true will flag returned events as read, modifying the feed's state. This directly contradicts the annotation readOnlyHint: true, which suggests no state change. The contradiction reduces the transparency score.

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

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

The description is concise (5 sentences), front-loads the purpose, covers returns, filters, side effects, and alternative access method. Every sentence adds value without redundancy.

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

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

The description covers the main return fields and explains mark_read, but it does not mention the limit or unread_only parameters in the text, and the return structure is only partially described (source, citation_uri, raw payload). Since there is no output schema, the agent might need more detail on the exact response format.

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. The description adds extra value by providing an example for the type parameter ('sec_8k'), explaining the mark_read behavior, and mentioning return fields, which goes 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 recent alerts from the subscription feed, specifying the verb (pull/returns) and the resource (alerts from the subscription feed). It also distinguishes from siblings like list_subscriptions by focusing on events rather than subscription management.

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 states that polling works fine and mentions an alternative REST endpoint for scripts/dashboards, providing context for when to use this tool versus an external API. However, it does not explicitly compare to sibling tools or list conditions where other tools are preferable.

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 complements annotations (readOnlyHint, idempotentHint, etc.) by detailing the parallel fan-out to multiple sources, the fallback chain, and the return structure (changes grouped by source, total_changes count, citation URIs). 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 comprehensive and well-organized, but slightly verbose. It front-loads natural language examples and covers all necessary details without redundancy. Minor improvements could tighten phrasing.

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

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

Given no output schema, the description adequately explains return values (changes grouped by source, total_changes count, citation URIs). It covers tool purpose, parameter usage, source behavior, and limitations, making it fully self-contained.

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

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

Schema coverage is 100%, and the description adds valuable context: accepted formats for 'since' (ISO date or relative shorthand like '7d', '30d'), recommended default ('30d' or '1m'), and explanation of 'value' (ticker or CIK). 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 provides a 'change feed for a company' fanning out to multiple sources. It uses example queries like 'What's new with X' and explicitly distinguishes from sibling tool 'entity_profile' by directing users to that tool for static profiles.

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

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

The description provides explicit when-to-use guidance with example natural language queries. It contrasts with entity_profile for static profile use cases. It also explains fallback behavior (GDELT→GNews) and notes the USPTO soft-failure limitation.

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 idempotentHint=true, destructiveHint=false, and readOnlyHint=false. The description adds scoping by identifier, persistence differences between authenticated and anonymous users, and 24-hour retention. Does not mention potential key-length limits or overwrite behavior, but adds meaningful 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?

Three sentences, each earning its place: purpose, usage guidance, and behavioral nuances. No fluff, front-loaded with core action.

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

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

Covers purpose, usage, paired tools, and retention policy. No output schema, but description adequately explains return value is implicit (store action). Could mention key-length limits or overwrite behavior, but overall complete for a simple key-value store.

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

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

Schema description coverage is 100% with descriptive parameter mentions. The description adds concrete examples (e.g., 'subject_property', 'target_ticker') that reinforce real-world usage, going 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 saves data for reuse across conversations and sessions, with specific verb 'save' and resource 'data'. It distinguishes from siblings 'recall' and 'forget' by name-dropping 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?

Explicitly says 'Use when you discover something worth carrying forward', provides concrete examples (resolved ticker, target address), and instructs pairing with recall and forget. No ambiguity about when to use.

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

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

The description goes well beyond the readOnly/idempotent annotations by disclosing that unresolved identifiers are explicitly listed under `unresolved` rather than omitted, that LEI/FIGI enrichment degrades gracefully if upstream sources are unavailable, and that each call cascades through multiple lookup endpoints. These behavioral details are valuable and not present in annotations.

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

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

Although the description is longer than typical, it is efficiently structured: it opens with concrete user queries, then defines the core behavior, describes each supported type with relevant details, and closes with degradation behavior. Every sentence contributes substantive 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?

With no output schema, the description carries the full burden of explaining return values. It thoroughly specifies what identifiers are returned for company and drug types, source labeling, unresolved handling, and graceful degradation, making it complete for an agent to understand what to expect.

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

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

Schema coverage is 100% and both `type` and `value` are well-documented in the schema, including enums and input format examples. The description reinforces these details but does not add significant additional meaning beyond the schema for the parameters themselves.

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

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

The description opens with concrete example queries ('What's the ticker for…' / 'find the CIK for…') and then clearly states the core purpose: resolving a user-spoken name to canonical identifiers. It lists supported types (company, drug) and the identifiers returned, which fully distinguishes it from sibling tools like search or entity_profile.

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

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

The description explicitly says 'Use FIRST whenever you have a name but need an ID' and frames the tool as a replacement for 2-3 manual lookups, providing strong contextual guidance. It does not, however, name alternative tools or explicitly state when not to use this tool, so it stops short of full exclusion guidance.

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

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

Annotations already confirm read-only, idempotent, open-world, and non-destructive behavior. The description adds value by detailing the ranking behavior, output fields (score, confidence, signal density), and the probing mechanism. It does not contradict annotations.

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

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

The description is two sentences long, front-loads the purpose, and packs critical information without fluff. Every sentence earns its place, and it is efficiently structured 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 no output schema, the description partially covers the return format (ranked list with score, confidence, signal density) but does not specify exact structure or field names. However, for a tool with four parameters and no nested objects, the description is fairly complete and leaves minimal ambiguity.

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

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

Schema coverage is 100% with descriptions for all parameters. The description adds extra semantics: that the first entity is treated as the 'subject' for narrative and the rest as competitors, and that the context parameter is a shared context applied to every probe. This goes beyond the schema.

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

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

The description clearly states the tool compares AI visibility across multiple entities, uses ai_visibility_check as the underlying probe, and ranks them. It explicitly distinguishes from a single-entity check (ai_visibility_check sibling) and gives a concrete use case, making the purpose immediately understandable.

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 that the tool is for competitive AI-marketing audits and mentions it probes each entity with ai_visibility_check, implying when to use it. It does not explicitly state when not to use or list alternatives, but the context is clear enough for an agent to differentiate from single-entity checks.

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 details the composite behavior, the services used (deps.dev, bundlephobia), the return fields (summary block with is_latest, license, etc.), and potential latency ('first measurement on a new version can take 5-30s'). No contradiction with annotations.

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

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

The description is a single paragraph of about 150 words. It front-loads the main purpose and includes dense, useful details. While every sentence adds value, it could be broken into multiple sentences for improved readability.

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

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

Given the tool's complexity (two-service composite, partial failures, multiple return fields) and lack of output schema, the description fully covers return values (summary block, per-advisory detail, links, alternative versions), ecosystem scope, and error handling. An agent has sufficient context to invoke the tool correctly.

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

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

The input schema covers both parameters with descriptions (package name, version defaults to latest). The description adds minimal extra meaning (e.g., scoped packages accepted) but schema coverage is 100%, so 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 it is a composite check for npm packages, combining deps.dev and bundlephobia data. It distinguishes from sibling tools by specifying NPM ecosystem only and noting alternative tools for other ecosystems.

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

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

The description explicitly says 'Use whenever an agent asks "is X safe / popular / small" or "what does adding lodash cost me".' It also clarifies ecosystem scope (npm only in v1) and handles partial failures, providing clear when-to-use and when-not-to-use guidance.

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

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

Annotations already declare read-only, idempotent, non-destructive behavior. The description adds that it returns media URLs and metadata, and supports pagination, but does not disclose rate limits, authentication needs, or detailed pagination behavior. With annotations present, the description provides adequate but not rich 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?

A single sentence that is front-loaded with the verb and resource, then lists features. Every part adds value; there is no redundancy. Ideal conciseness for the amount of information conveyed.

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 9 parameters and the existence of an output schema, the description covers the main return type (media URLs and metadata) and explains key parameters. It could mention that only q is required, but is otherwise complete for a high-level description.

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 only 11% (description for contentfilter). The description adds meaning for q (keyword), locale, contentfilter, ar_range, random, and pagination (pos/limit), mapping to several parameters. It compensates for low schema coverage by explaining the purpose of most parameters, though client_key and media_filter are not explicitly mentioned.

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 searches Tenor's GIF and sticker library by keyword, and lists supported features. It distinguishes from sibling tools like 'trending_terms' or 'search_suggestions' by specifying the media type and library.

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 searching GIFs/stickers but does not explicitly provide when-to-use or when-not-to-use guidance, nor does it mention alternatives among sibling tools. Usage is inferred but not prescribed.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint as false, so the description doesn't need to repeat those. The description adds behavioral context (returns suggestions for partial query, Tenor-specific) beyond annotations. No contradictions.

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

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

The description is a single sentence that is clear, front-loaded, and concise. Every word 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 complexity (4 parameters, output schema exists), the description provides sufficient context for usage. The output schema likely details return format, so the description doesn't need to explain that. It could hint at the return type but is complete enough.

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

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

Schema description coverage is 0%, so the description must compensate. It explains 'q' as a partial query string, but does not mention 'limit', 'locale', or 'client_key'. The examples in the schema provide some context but not in the description. Baseline is 3 due to low coverage, and the description only partially improves it.

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

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

The description clearly states the tool returns Tenor search query suggestions for partial query strings, specifically for building GIF autocomplete UIs. It uses a specific verb and resource, distinguishing it from sibling tools like 'search' and 'autocomplete'.

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 mentions the use case (building autocomplete UIs), providing clear context for when to use. However, it does not explicitly state when not to use it or name alternatives, though the sibling list includes 'autocomplete' and 'trending_terms' which are related.

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

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

Beyond the annotations (readOnlyHint, idempotentHint, etc.), the description discloses internal behavior: 'BGE-base-en embeddings + cosine over 500-char overlapping windows; cap is 200K chars (longer inputs are truncated and flagged).' This fully informs the agent about how the tool works and its limitations, with no contradictions to annotations.

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

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

The description is a single dense paragraph that covers purpose, usage, internal mechanics, limits, and pairing. Every sentence adds value, and the core idea is front-loaded. No fluff.

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

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

Given the tool has 3 parameters, no output schema, and sibling tools to differentiate from, the description is complete. It explains behavior, limits, how results are structured (passages with offsets and scores), and how to combine with other tools. No gaps.

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

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

Schema coverage is 100%, so baseline is 3. The description adds minimal extra meaning: it gives examples for the 'query' parameter and restates the character limit for 'text', but the schema already provides good descriptions. No additional nuance 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: 'Semantic search INSIDE a fetched record.' It specifies the action (search), the resource (a fetched record), and the scope (inside a record, not across multiple). This distinguishes it from sibling tools like 'search' which likely searches across documents, and it pairs with 'ask_pipeworx_grounded' for grounding over passages.

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 this tool: 'Use when the record is too big to cram into the prompt — search_within saves context.' It also mentions pairing with 'ask_pipeworx_grounded'. However, it does not explicitly state when not to use it (e.g., if the record is small enough to fit in the prompt), which would have earned 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?

Adds significant detail beyond annotations: describes creation of persistent subscription, return of ID, delivery details (webhook signing, auto-disable after failures), and account requirements. 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?

Well-structured and front-loaded, but somewhat lengthy due to detailed delivery and type explanations. Every sentence is informative, but could be slightly more concise without losing value.

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

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

Completely covers all aspects given the tool's complexity: types, parameters, delivery channels, constraints, and authentication. No output schema exists, but the description suffices to guide correct invocation.

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

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

The description adds concrete examples for each subscription type and delivery channel, greatly enriching the schema's definitions. Even though schema coverage is 100%, the description provides crucial context for correct parameter usage.

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

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

The description clearly states it creates a subscription to a live-data event stream and returns an ID, using specific verbs and resources. It distinguishes from siblings like list_subscriptions and unsubscribe by focusing on creation.

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?

Includes explicit requirements (OAuth account), supported types, delivery channels, and constraints (phone verification, daily caps). Provides comprehensive context for when 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds that it returns live catalog example questions with exact tool+argument shape, no contradictions.

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

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

Description is fairly long but well-structured with examples and a list of categories. Could be slightly more concise but still effective.

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

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

With no output schema, description explains return format (category-bucketed examples with tool+argument shapes). Covers all needed context for a simple 0-param tool.

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

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

Schema coverage is 100% with one optional parameter. Description adds examples of focus areas and that omitting as topic gives full spread, beyond the schema's enum 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 returns category-bucketed example questions with tool+argument shapes, serving as an onboarding entry point. It distinguishes from siblings like ask_pipeworx by noting it teaches how to call meta-tools.

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

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

Explicitly instructs use when you don't know what Pipeworx can do, and to learn how to call meta-tools. While it doesn't state when not to use, the context is clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds context about the content (reaction, meme, pop-culture phrases) but does not disclose any additional behavioral traits like pagination or rate limits. 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?

Two sentences, front-loaded with the key information, and no wasted words. It earns its place by explaining both the domain context and the return type.

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

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

For a simple read-only list tool with a rich output schema and good annotations, the description is mostly sufficient. However, it lacks explicit usage guidance and fails to explain the 'limit' parameter, leaving some contextual gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions 'for a locale' which clarifies the locale parameter, but the 'limit' parameter is not explained at all. With only two optional parameters, this is a noticeable gap.

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

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

The description uses a specific verb ('Returns') and names the exact resource: Tenor's current trending GIF keyword list. It clearly distinguishes itself from siblings like 'featured' or 'categories' by focusing on trending search terms.

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

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

The description implies when to use this tool (when you need trending Tenor keyword lists) but does not explicitly discuss alternatives or when not to use it. Sibling tools like 'featured' or 'categories' exist, but no exclusion criteria are given.

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

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

Beyond annotations (idempotent, non-destructive), the description adds that ownership is enforced and that the row is deactivated not deleted, making historical events available via recent_alerts. This provides valuable behavioral context.

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

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

Two sentences with no wasted words. First sentence states action, second provides key constraints and effect. Front-loaded and efficient.

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

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

Covers action, ownership constraint, and the deactivation vs deletion effect with reference to recent_alerts. For a simple tool with one parameter and no output schema, this is sufficient. Lacks error handling details but that's acceptable.

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

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

Schema coverage is 100% and the parameter 'id' is well-described in the schema as a UUID from subscribe. The description adds no additional semantic meaning for the parameter beyond ownership enforcement, which is global behavior.

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

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

The description clearly states the action ('Cancel a subscription by id') and the resource ('subscription'). It distinguishes from sibling tools like 'subscribe' and 'list_subscriptions' by specifying the cancel operation.

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

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

Provides explicit context on ownership enforcement ('you can only cancel your own subscriptions') and the effect of deactivation. Does not explicitly state when not to use or compare to alternatives, but the ownership constraint effectively guides usage.

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

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

Annotations already declare read-only, open-world, idempotent, and non-destructive behavior. The description adds crucial interpretive context: the distinction between 'unsupported' (we looked, found nothing) and 'could_not_verify' (the check did not happen) and the requirement not to treat could_not_verify as evidence. This significantly enhances the agent's ability to reason about results.

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?

Although lengthy, the description is tightly packed with high-value information. Each sentence serves a purpose: intent examples, routing logic, return values, crucial caller caveats, and efficiency rationale. The structure flows logically from what the tool does, to when to use it, to what it returns, to special-case warnings.

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

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

For a complex verification tool with no output schema, the description fully covers return values (verdict values, actual value, citation, reasoning) and edge cases (could_not_verify with verification_error, unsupported). It also explains the internal routing and replaces 4-6 sequential calls, giving the agent complete situational awareness.

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

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

Schema coverage is 100% and both parameters are documented. The description goes beyond the schema by explaining that tolerance_pct overrides the tolerance implied by the claim wording, gives a recommended range (1-2) for hallucination detection, and notes the default is capped at 5. This added semantics directly informs invocation decisions.

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 the verb 'verify' and the resource 'natural-language factual claims' with concrete intent examples ('Is it true that…', 'fact check'). It clearly distinguishes itself from sibling research/search tools by describing its integrated, single-call nature that replaces 4-6 sequential operations, making its purpose unmistakable.

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

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

Explicit guidance states 'Use whenever the agent needs to check whether something a user said is factually correct.' It further differentiates the fast path for company-financial claims versus the grounded pipeline for other claims, and clarifies when to use tolerance_pct for hallucination detection. No ambiguity remains about when this tool is appropriate.

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