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 carry readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context beyond those annotations: it routes across 5,724 verified sources, returns structured answers with citation URIs, works on every tier, and is described as 'one fast call'. There is 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 long but every sentence earns its place: it front-loads the core preference, names the source categories, gives concrete examples, states when to start, and explicitly routes to alternatives. The structure is dense without being redundant, and important guidance like 'START HERE' and 'Step up only when needed' is clearly visible.

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 natural-language routing tool with only one required parameter and no output schema, the description is complete: it explains the input style, the routing behavior, the output format with citation URIs, and the alternatives for other query shapes. It also covers edge cases like breaking news and multi-part research queries. No critical invocation detail 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 description coverage is 100%, and the single required parameter is well documented as a natural-language question with multiple accepted aliases. The description reinforces that the tool takes free-form factual questions, and examples are already present in the schema, so the description does not need to add more. Baseline 3 applies because the schema carries the parameter-semantics burden.

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

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

The description states a clear verb-resource pair: it 'routes the question to the right one of 5,724 tools' and 'returns the structured answer with stable pipeworx:// citation URIs.' It explicitly distinguishes itself from siblings like ask_pipeworx_grounded and deep_research, and gives concrete examples of questions it handles. An agent can immediately tell what this tool does and why it exists.

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

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

The description gives explicit when-to-use guidance: 'PREFER OVER WEB SEARCH', 'START HERE for most questions', and 'Use whenever the user asks...'. It also provides when-not-to-use guidance by naming ask_pipeworx_grounded for hallucination-resistant single answers and deep_research for broad/multi-part fan-out. This leaves little ambiguity about tool selection.

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

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

Annotations already establish readOnly/openWorld/idempotent/non-destructive behavior. Beyond that, the description adds valuable dynamic context: candidate routing changes are enabled live only when under test, none is currently active, and it matches ask_pipeworx exactly at present. This clarifies the experimental edge 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?

Four sentences, each carrying meaningful information: beta status, identity with ask_pipeworx, current experimental state, usage guidance, and the 'full working router' caveat. It is slightly dense and could be tightened, but no sentence is wasted.

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 natural-language router, the description covers identity, current state, usage, and relationship to the stable sibling. It references the same response shape rather than detailing it, which is reasonable given no output schema and the shared route with ask_pipeworx. Minor gaps remain around examples or a pointer to ask_pipeworx_grounded, but overall it 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 coverage is 100% and the schema documents the question parameter and all five aliases. The description adds only that it uses the same arguments as ask_pipeworx, which is cross-tool context but not additional parameter meaning. 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?

Description clearly identifies this as the beta variant of ask_pipeworx, a universal router with the same tool set, arguments, and response shape. It explicitly differentiates from the stable sibling by describing the experimental 'candidate routing improvements' and states it is a full working router, not a fallback.

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?

States when to use it: 'Use it exactly like ask_pipeworx when you want the newest routing.' It also implies the alternative is the stable ask_pipeworx and clarifies results are compared against the stable router. It does not enumerate when not to use it or address ask_pipeworx_grounded, but the context is clear.

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

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

Beyond the annotations (readOnly, openWorld, idempotent, non-destructive), the description discloses the exact success and refusal return shapes, the specific refusal_reason enumerations, and the cost tradeoff. It also clarifies that the answer uses only the tool result, which directly supports the annotation profile.

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 densely informative without filler. It front-loads the core behavior, then covers routing, return payloads, refusal modes, use cases, and cost in a compact, logically ordered format.

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

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

Given the tool's complexity, the lack of an output schema, and the rich sibling context, the description is highly complete. It covers success and failure shapes, refusal reasons, cost implications, and usage boundaries, leaving no critical decision-making information 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?

The schema already documents 100% of parameters, including aliases, and the description adds only the general note that the parameter is a natural-language question. With full schema coverage, the baseline of 3 is appropriate.

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

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

The description states a specific outcome: a hallucination-resistant answer mode that extracts answers only from the tool result. It explicitly distinguishes itself from ask_pipeworx by calling out the grounded, evidence-backed behavior, so an agent can tell them apart without opening schemas.

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

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

The description gives explicit when-to-use guidance: high-stakes reads, quoted/cited/acted-on answers, and domains like financial verdicts, legal claims, medical lookups, and public statements. It also states when not to use it by recommending ask_pipeworx for casual lookups and notes the extra LLM call cost.

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?

Annotations already provide readOnly/openWorld/idempotent/non-destructive hints, but the description adds substantial behavioral context: auth and paid-tier requirements, parallel routing, verbatim evidence with confidence/source/fetched_at, gaps[] never-invented behavior, contradictions[] for standard/thorough, semantic excerpting, and latency expectations. This goes well beyond what the structured annotations express.

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 the tool is complex and has no output schema, so the length is largely earned. It is front-loaded with the most critical operational facts: account requirement, the alternative to use when unsigned-in, and the NOT open-web-search caveat. It could be tightened slightly, but it is dense with distinct facts rather than padded.

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

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

With no output schema, the description fully carries the burden of explaining return behavior, and it does: findings packet, verbatim evidence, confidence, source, fetched_at, citation_uri, hop, gaps[], contradictions[], and excerpting. Combined with rich parameter descriptions and annotations, an agent has everything needed to select and invoke this 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 schema already documents both parameters at 100% coverage, so the description is not required to compensate. It adds meaningful context by tying depth levels to hop behavior, paid plans, latency, and contradiction scans, and by giving example question forms. This exceeds the baseline but does not provide field-level syntax 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 names a specific action ('research'), a specific resource ('Pipeworx's 1497 STRUCTURED data sources'), and clearly distinguishes itself from open-web search and from ask_pipeworx. It moves beyond tautology by explaining what makes this tool unique: parallel decomposition across many tools into a findings packet.

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

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

The description gives explicit when-to-use guidance: broad/multi-part structured-data questions are the intended use, single lookups should use ask_pipeworx, breaking/current-news queries should prefer ask_pipeworx, and unsigned-in users are routed to ask_pipeworx. This is model-friendly selection criteria, not just a vague hint.

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 goes far beyond the readOnly/idempotent annotations by revealing compatibility_codes, pairing_unverified status in both modes, fee treatment, null semantics for temporal_alignment, and the fact that unclassified legs are never paired. This is rich, candid behavioral disclosure about a complex matcher.

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

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

The description is front-loaded with the core purpose and organized with clear section labels like TWO MODES, RESPONSE, and SAFETY FIELDS. It is long, but the density is largely justified by the number of safety caveats; a little redundancy around temporal_alignment semantics keeps it from a 5.

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

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

With no output schema, the description fully carries the return-value burden: it covers leg-by-leg prices, top_spreads_pp flags, compatibility fields, skipped counters, low-confidence pairs, fees disclosure, and alignment semantics. An agent has enough information to call the tool and interpret its results safely.

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

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

The schema already documents all three parameters at 100% coverage, so the baseline is 3; the description adds meaningful relational meaning by explaining that explicit ticker/slug overrides replace the topic-mapped side and that both modes run the identical matcher. That is useful context beyond the field descriptions, though per-param syntax is still left mostly to 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 leads with a specific resource and task: computing the cross-venue spread between Kalshi and Polymarket for the same resolving question, and explains when the delta is a real signal. It also clearly distinguishes itself from single-venue tools by emphasizing cross-venue comparison and the same-outcome matching requirement.

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

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

The description clearly lays out two invocation modes, which parameters apply to each, and warns that pre-mapped topics are not automatically tradeable because most return compatibility warnings. It does not explicitly name alternative sibling tools or give an explicit when-not-to-use list, so it falls just short of 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, 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 far beyond the readOnly/idempotent annotations by disclosing cascading internal lookups, graceful degradation when LEI/FIGI sources fail, explicit `unresolved` reporting, ambiguous-match behavior returning `figi_candidates`, and support for non-equity instruments. This gives the agent an accurate model of edge-case 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 dense and front-loaded: the trigger phrase appears early, followed by structured type-specific detail. Some parenthetical asides are heavy, yet they carry unique behavioral information, so the length is mostly justified.

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 thoroughly covers inputs, outputs, ambiguous cases, fallback behavior, and source labels. An agent has enough context to call it correctly and interpret its results without additional lookups.

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 input schema already covers both parameters, the description adds crucial semantics: company accepts ticker, CIK, ISIN, or name; drug accepts brand or generic; and it warns to pass the entity name only, never the full noun phrase, with a concrete example. This materially reduces parameter misuse.

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 user utterances and a crisp verb+resource pair: resolve a name to canonical/official identifiers. It clearly distinguishes itself from siblings by emphasizing that other tools require these identifiers as input, and enumerates supported entity types and identifier sources.

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 'Use FIRST whenever you have a name but need an ID,' giving a clear trigger condition. It does not explicitly list sibling tools to avoid or contrast with, but the 'other tools require as input' framing implicitly routes the agent toward this tool for ID lookup.

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.