Gong

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

Beyond annotations (readOnlyHint, openWorldHint, idempotentHint), the description discloses that it calls external APIs (Workers AI free, Anthropic with user's key), explains `_apiKey` passes straight through to Anthropic, and details the return structure (`{score, confidence, signals, raw_response}` per model plus combined view). No contradictions with annotations.

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

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

The description is a single paragraph that front-loads the core purpose and is well-structured. While it is concise, it could be slightly tighter by removing redundant phrasing like 'per model' (already in schema). However, it is not verbose.

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 (per-model object and combined view). It covers all parameters and use cases. However, it lacks information about error handling or rate limits, which would improve completeness for a tool that calls external APIs.

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, but the description adds significant value: it notes the default model (Workers AI Llama-3.3-70b free), clarifies that `_apiKey` is optional and only required for Anthropic, and explains that `context` helps disambiguate common names. This goes beyond schema alone.

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

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

The description uses a specific verb 'probe' and resource 'LLMs', clearly stating it scores visibility (0-100) per model. It is distinct from sibling tools like 'ask_pipeworx' or 'deep_research' by focusing on multi-model visibility rather than single queries or 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 explicitly lists use cases: 'AI-marketing audits, pre-launch brand checks, competitive monitoring'. It also explains when to use optional parameters like `_apiKey` for Anthropic. However, it does not explicitly state when not to use this tool or provide alternatives, which would make it 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 readOnly/openWorld/idempotent safety, and the description adds meaningful behavioral detail: it 'routes the question to the right one of 5,798 tools across 1517 verified sources,' auto-fills arguments, and returns structured answers with stable citation URIs. It also discloses coverage of live news via news-feeds packs. The only minor gap is no mention of failure modes, latency, or account limits, but those are not required given the safety annotations.

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

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

The description is longer than average but every section earns its place: priority rule, domain list, routing behavior, example queries, and sibling routing. The main cost is some redundancy ('PREFER OVER WEB SEARCH' appears twice) and slightly awkward phrasing around ask_pipeworx_grounded, but the essential guidance is front-loaded and scannable.

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 broad routing tool with no output schema, it explains what the response looks like ('structured answer with stable pipeworx:// citation URIs'), enumerates supported domains, and handles sibling alternatives. It is complete enough for an agent to select and invoke the tool; only small edge-case details, such as what happens when no matching source is found, are absent.

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%: all six parameters are clearly documented as aliases for the natural-language 'question' field. The description adds example queries and trigger phrases, but does not add new parameter-level syntax or constraints; the baseline of 3 applies because the schema already carries the semantic weight.

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 clear directive verb and scope: 'PREFER OVER WEB SEARCH' for factual/current/historical data across a concrete list of domains, explicitly framing the tool as a universal question router that 'returns the structured answer with stable pipeworx:// citation URIs.' It differentiates itself from siblings by saying use ask_pipeworx_grounded for grounded/cited answers and deep_research for broad multi-part questions.

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

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

Provides explicit when-to-use guidance ('Use whenever the user asks...'), even stating to prefer it over web search, gives concrete example queries, and names specific alternative tools with the conditions that select them ('for grounded answer ... use ask_pipeworx_grounded; for a broad/multi-part question ... deep_research'). This leaves little room for an agent to mis-route.

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 a read-only, idempotent, non-destructive tool. The description adds useful behavioral context beyond annotations: candidate improvements are enabled live when under test, no candidate is currently active, and it is a full working router rather than a fallback stub. This appropriately warns about the experimental nature without contradicting the annotations.

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

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

The description is somewhat long but every sentence earns its place: it covers beta status, identical behavior, current candidate state, usage guidance, and the fact that it is a full router. It is front-loaded with the most important information and has no meaningless 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?

Given that this is an alias-like beta router with no output schema, the description adequately covers what the tool is, how to use it, and current behavior. It mentions the same response shape and the live candidate-testing context, which together give an agent enough to invoke it correctly.

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

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

The input schema has 100% coverage, describing all six parameters as aliases for the same question string. The description only says 'same arguments' and does not add meaning beyond the schema, so 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 purpose: a beta version of ask_pipeworx that is an identical universal router with the same tools, arguments, and response shape. It clearly distinguishes itself from the stable ask_pipeworx by noting candidate routing improvements and the experimental edge.

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 to use it exactly like ask_pipeworx when wanting the newest routing, and explains that results are compared against the stable router. It does not explicitly enumerate when not to use it or alternative tools like ask_pipeworx_grounded, but the intended 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 indicate read-only, idempotent, non-destructive behavior, and the description adds substantial behavioral detail beyond them: it will only answer from tool contents, returns verbatim evidence, and explicitly refusals with structured reasons when it cannot answer. This fully discloses the refusal behavior and output guarantees.

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

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

The description is dense but every sentence adds value: mode, routing, grounding behavior, refusal semantics, use cases, and cost trade-off. It is somewhat long, but the content is appropriately front-loaded with the core value proposition and refusal reasons.

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 explains the return shape for both success and refusal paths, including all refusal_reason values. It also covers when to use the tool, how it differs from sibling tools, and the single input parameter. Nothing needed to call it correctly 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 schema fully documents the single meaningful input ('Your question in natural language') including all aliases. The description does not need to repeat parameter details, 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 identifies this as a grounded, hallucination-resistant answer mode for high-stakes reads, with a specific verb and resource ('answers by extracting only from tool results'). It also distinguishes itself from the sibling ask_pipeworx by naming the same routing and the extra verification step.

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

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

Provides explicit when-to-use guidance: whenever an answer will be quoted, cited, or acted on, and facts must not be invented. It also gives a clear when-not-to-use directive ('prefer ask_pipeworx for casual lookups') and discloses 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?

Extensive disclosure beyond annotations: resolution process, fan-out specifics, response shapes, resolver contract, parent event extraction, news fallback, safety short-circuits, spread warnings, and cancellation rule parsing. 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?

While highly informative, the description is lengthy and dense, listing many edge cases and details. It could be more structured with subheadings or bullet points. However, the complexity justifies some verbosity.

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?

Comprehensive coverage of all aspects: input, processing, output shapes, edge cases (low confidence, closed markets, wide spreads), and cancellation rules. Without an output schema, the description fully explains return values and behaviors.

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

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

Schema coverage is 100%. Description adds meaning beyond schema by explaining input types for market, depth options with default, and include_raw with guidance on when to use true. Provides examples for market 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?

Clearly states the tool researches Polymarket bets by pulling Pipeworx data. Specifies input types (slug, URL, question text) and use cases ('should I bet on X', etc.). Distinct from sibling tools like polymarket_arbitrage or polymarket_edges by focusing on evidence gathering and market-model comparison.

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 scenarios for use and examples of fan-out. Describes when results are blocked (low-confidence match, closed markets). No explicit when-not-to-use, but the context and warnings adequately guide proper usage.

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

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

Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds substantial behavioral context: data sources (SEC EDGAR/XBRL for companies, FAERS for drugs), handling of off-calendar fiscal years, sorting by primary metric, and return of pipeworx:// citation URIs. This goes well beyond what annotations provide.

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

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

The description is a single paragraph but well-structured: first listing usage examples, then explaining data sources for each type, sorting, and return format. Every sentence adds value. Could be slightly more structured with bullet points, but is appropriately sized and front-loaded with examples.

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 return format (paired data + citation URIs). It covers two entity types with distinct data sources, fiscal-year handling, and sorting behavior. Minor gap: no mention of pagination or rate limits, but for a read-only comparison 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?

Schema coverage is 100% with both parameters described. The description adds meaning by specifying that type='company' pulls revenue, net income, cash, and debt from SEC EDGAR, while type='drug' pulls FAERS adverse-event counts, FDA approvals, and trial counts. It also explains values format (tickers/CIKs for company, names for drug) and constraints (2-5 items).

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 concrete query examples ('Compare X and Y', 'X vs Y', etc.) that immediately clarify the tool's purpose. It specifies side-by-side comparison of 2-5 entities in one call, clearly distinguishing it from sequential lookups. The verb 'compare' and resource 'entities' are explicit.

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

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

The description explicitly states 'ALWAYS PREFER over sequential single-pack lookups when comparing entities.' It provides clear context for when to use this tool (comparison queries) and quantifies the benefit ('Replaces 8-15 sequential lookups'). While there is no explicit 'when not to use', the positive guidance is strong.

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

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

Beyond the readOnly/openWorld/idempotent annotations, the description discloses concrete behavior: parallel routing to 5,798 tools, a findings packet with verbatim evidence plus confidence/source/fetched_at, explicit gaps[] for unanswered facets, 'never invented' grounding, contradictions[] in deeper modes, semantic excerpting, and latency expectations. 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 it is front-loaded with the critical account gate and the core 'structured multi-source research' message first. It remains dense and purposeful; the only cost is some redundancy around the two ask_pipeworx fallback mentions.

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?

There is no output schema, so the description carries the burden of explaining the return value, and it does: findings packet, citation_uri, hop field, gaps[], contradictions[], excerpting, and expected latency. Combined with full parameter schema coverage and clear auth notes, an agent has what it needs 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?

Schema coverage is 100% and the enums already describe what quick/standard/thorough do. The description adds some behavioral detail about depth tiers in running text, but most of that repeats the schema's depth descriptions, so it does not substantially raise the baseline.

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

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

The description states a specific verb and resource: 'Grounded multi-source research across Pipeworx's 1517 STRUCTURED data sources' in ONE call. It clearly differentiates from siblings by saying this is NOT open-web search, is best for broad/multi-part questions, and explicitly names ask_pipeworx as the alternative for single 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?

It gives explicit when-to-use conditions ('best for broad/multi-part questions over structured data'), when-not-to-use conditions ('For a single lookup use ask_pipeworx instead'), and an auth-gated alternative ('If you are not signed in, use ask_pipeworx instead'). It also clarifies that depth:'thorough' requires a paid plan, so the agent can make an access-aware call.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value by explaining the return format (full schemas, curated examples, ready to call) 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?

Description is front-loaded with purpose and use cases, then explains return format and usage advice. Slightly lengthy but well-structured and each 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?

Even without an output schema, the description fully explains what is returned (names, descriptions, full schemas with examples, ready to call). It also covers when to use it.

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

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

Schema coverage is 100% with descriptions for all parameters. The description adds context with examples and emphasizes natural language usage, going beyond schema details.

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

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

The description clearly states the tool finds tools by describing data or task, lists many domains, and distinguishes itself by being the first call to see options. It is specific and actionable.

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 need to browse, search, look up, or discover what tools exist' and 'Call this FIRST when you have many tools'. Does not explicitly exclude other scenarios but provides strong context.

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

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

Annotations already provide readOnly/idempotent/openWorld/destructive context, and the description adds substantial behavioral detail: fan-out across specific sources, patent source sunset with soft-fail, GDELT→GNews fallback, expected-empty fda_products for non-biologics companies, and sources_used/sources_failed semantics. This goes well beyond the structured annotations.

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

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

The description is dense and long, but the complexity of the tool justifies the length. It is front-loaded with trigger examples and the preference rule, and every subsequent clause adds necessary behavioral or return-format detail. It could be better organized with line breaks, 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 tool with no output schema and many data sources, the description enumerates all return sections, edge cases, fallbacks, and failure semantics. It tells the agent what to expect when a company has no patents, no biologics, or is private, making it essentially self-sufficient for correct invocation and interpretation.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds concrete examples ("AAPL", "0000320193", "Moderna"), clarifies that type 'company' and 'ticker' are interchangeable, and explains name resolution via SEC EDGAR—small but genuinely useful additions beyond the schema's dry enum and value 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 opens with concrete trigger phrases and states a specific verb-resource pair: a 'full cross-source profile of a US public company in ONE parallel call.' It clearly distinguishes itself from single-pack SEC/XBRL/news lookups and from siblings like resolve_entity or compare_entities by emphasizing holistic, parallel coverage.

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

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

The description explicitly says 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view,' giving a clear when-to-use rule and naming the alternative pattern it replaces. It also sets expectations for private companies (resolved:false with notes) and clarifies that empty sections are legitimate outcomes, not failures.

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 destructiveHint true; description confirms deletion by key. Adds context like pairing with remember/recall but doesn't detail error handling or idempotency behavior beyond annotations.

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

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

Two sentences, no fluff, front-loaded with purpose and usage guidelines.

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

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

Complete for the tool's simplicity: single parameter, no output schema. Description covers purpose, usage, and related tools.

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

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

Schema coverage is 100% and the parameter description is clear; the tool description adds no additional meaning beyond the schema.

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

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

The description clearly states the action ('Delete a previously stored memory by key') with a specific verb and resource, and distinguishes itself from sibling tools like '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 the tool (context stale, task done, clear sensitive data) and mentions paired tools, guiding proper 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 (readOnlyHint, destructiveHint false, idempotentHint) are fully consistent with description's 'Fetches the page, extracts...' and non-destructive nature. Description adds details about output format and placement 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?

Single, well-organized paragraph: purpose first, then process, output details, use cases. Every sentence adds value with no redundancy.

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

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

Adequately covers purpose, process, output format, and use cases for a tool with only two parameters. Could mention error handling or redirect behavior, but sufficient for typical usage.

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

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

Schema description coverage is 100%. Description adds example values for url and clarifies default/max for max_links, enriching the schema's descriptions slightly.

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

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

Description clearly states the tool generates an llms.txt file, details the process (fetch, extract, emit), and specifies the output format and location. Distinguishes from siblings through unique functionality.

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

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

Explicitly lists three use cases (indexing client sites, drafting own, auditing competitors), providing clear context for when to use. No exclusion criteria but sufficient for the tool's simplicity.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds context by specifying the returned data (participants, duration, metadata, metrics, moments), which helps the agent understand the tool's output 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?

Single sentence, front-loaded with the action and resource, then lists returns. No extraneous content. Highly 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 one parameter and an output schema, the description covers key return fields. It does not address error cases or edge conditions, but the context signals indicate output schema exists, reducing the burden. Slight gap in completeness, but adequate.

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

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

Schema coverage is 100% with a clear description for callId ('The Gong call ID'). The description adds no additional parameter semantics beyond what the schema already provides, so baseline score of 3 is appropriate.

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

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

Description uses specific verb 'Get' and resource 'full details for a specific call by ID'. It lists what is returned (participants, duration, metadata, metrics, moments), clearly distinguishing it from siblings like gong_get_transcript (transcript only) and gong_search_calls (list/search).

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

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

The description implies use when needing comprehensive call details, but does not explicitly state when not to use or mention alternatives. It lacks guidance on differentiating from gong_get_transcript or gong_list_calls, leaving the agent to infer.

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 as true, and destructiveHint as false, indicating a safe, idempotent read operation. The description adds value by specifying the content of the transcript (speaker names, timestamps, dialogue), which complements the 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 consists of two sentences: one defining the function and result, the other providing usage guidance. No extraneous information. Every sentence is purposeful and 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 simplicity (one required parameter, full schema coverage, rich annotations, and presence of an output schema), the description sufficiently covers what an agent needs: what the tool does, what it returns, and when to use it. The mention of using after gong_get_call provides workflow 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%; the single parameter callId has a schema description 'The Gong call ID'. The tool description does not add any additional semantic meaning to the parameter beyond what is already in the schema, so baseline score of 3 is appropriate.

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

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

The description clearly states the purpose: retrieve the full conversation transcript with speaker names, timestamps, and dialogue. It differentiates from sibling tools like gong_get_call and gong_list_calls by specifying the exact resource and the context of use after gong_get_call.

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

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

The description provides explicit usage context: 'Use after gong_get_call to analyze specific conversations.' This guides the agent on the step-by-step workflow. It doesn't explicitly state when not to use it or list alternatives, but the given context is sufficient for appropriate invocation.

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 safe, non-destructive, idempotent behavior. The description adds useful context about pagination and return fields, which goes 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?

Two concise sentences, front-loaded with the main action and key features. Every word adds value, with no unnecessary details.

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

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

Covers core functionality, optional filters, pagination, and return fields. Output schema exists, so return details are sufficient. Lacks potential limitations or default behavior, but overall complete for the tool's simplicity.

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

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

Schema coverage is 100%, so the schema fully documents parameters. The description reinforces optional date filtering and pagination but does not add new semantic details beyond the schema's descriptions.

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

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

The description clearly states the action (list), resource (recorded calls), scope (from workspace), and key features (date filtering, pagination, return fields). It is specific and helps distinguish from siblings like gong_get_call and gong_search_calls.

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

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

The description implies usage through its examples but provides no explicit guidance on when to use this tool versus alternatives like gong_search_calls. It lacks instructions on prerequisites or exclusions.

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

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

The description adds behavioral context beyond annotations by specifying returned fields and the 'all users' scope. Annotations already provide read-only and idempotent hints, so the description complements them well.

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

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

The description is extremely concise, using one sentence for the main action and a second brief sentence for return fields. No wasted words, and the core purpose is front-loaded.

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

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

For a simple tool with no parameters and an output schema, the description is sufficiently complete. It specifies scope and return fields; annotations cover safety behavior.

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

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

The tool has zero parameters, so the schema provides full coverage. Per rubric, 0 params yields a baseline of 4; the description does not add parameter semantics but none are needed.

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

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

The description clearly states the verb (List) and resource (users) with scope ('in your workspace'), and enumerates the returned fields. It distinguishes from sibling tools like gong_list_calls which deal with calls.

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

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

No explicit guidance is provided on when to use this tool versus alternatives, nor any exclusions or prerequisites. The context with sibling tools is implicit but not stated.

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

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

Annotations already declare readOnly, idempotent, and non-destructive. Description adds that results are ranked by relevance, but no further 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?

Single sentence that is front-loaded with the action and includes an example. No wasted words.

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

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

Simple tool with one parameter; description covers input and output (returns calls ranked by relevance). Output schema handles details.

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 high, but description adds examples of keywords ('pricing', 'objection', 'budget'), which aids understanding beyond the schema's parameter 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?

Clearly states the tool searches calls by keyword or phrase, with specific examples. Distinguishes from sibling Gong tools like 'gong_get_call' and 'gong_list_calls'.

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

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

Implies use for keyword search but provides no explicit guidance on when to use versus alternatives or when not 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety profile is clear. Description adds that only active subscriptions are returned by default, and lists the returned fields. 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?

Two short sentences. First covers purpose and output fields, second gives usage context. No superfluous words.

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

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

For a simple list tool with one optional parameter and no output schema, the description adequately covers purpose and return fields. Missing mention of pagination or limits, but acceptable given low 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 describes the only parameter 'include_inactive' with full detail. Description does not add new information beyond what the schema provides (baseline 3 for 100% schema coverage).

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

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

Clearly states 'List the caller's active subscriptions' with specific verb and resource. Identifies return fields and distinguishes from sibling tools like subscribe and unsubscribe by mentioning reviewing before adding or finding id to cancel.

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

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

Provides explicit guidance: 'Use this to review what you're monitoring before adding more or to find an id to cancel.' This ties to siblings and indicates when to use. Does not specify when not to use, but the context is sufficient for a simple list 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?

With all annotations set to false, the description carries the full burden and delivers richly. It discloses rate limits ('Rate-limited to 5 per identifier per day'), the claim_token workflow for follow-ups, the fact that it's free and doesn't count against quota, and that the team reads digests daily. It also explains what happens when filing without an account. 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 somewhat long but well-organized: purpose first, then usage conditions, exclusions, workflow, and practical caveats. Every sentence contributes meaningful information (rate limits, token flow, quota impact), though a couple of phrases like 'The team reads digests daily' could be trimmed without losing core guidance. It earns a 4 for efficiency relative to the amount of necessary context.

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

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

Given the tool's complexity (4 parameters, nested object, enum, no output schema), the description covers all essential aspects: purpose, usage boundaries, alternative modes (claim_token vs. new feedback), rate limits, and expected outcomes. It even specifies what the response will contain (status and what changed). The lack of an output schema is compensated by the description's explicit mention of return values.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining the claim_token alternative usage ('Filing without an account returns a claim_token; pass it back later...'), giving guidance for the message field ('don't paste the end-user's prompt'), and clarifying that context is optional. This elevates it above the baseline.

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

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

The description clearly states the tool's purpose: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It uses a specific verb (tell/send) and resource (Pipeworx team), and differentiates itself from siblings by focusing on feedback about the tools themselves rather than using the tools. The explicit categories (bug, feature/data_gap, praise) further clarify scope.

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

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

Provides explicit when-to-use guidance: '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 clear exclusion: 'ONLY for tools served by this Pipeworx connection — if the tool came from a different MCP server... file it with that server instead.' The 'Not sure?' fallback adds practical decision support.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable behavioral context: self-aggregating signal, derived from CF analytics-engine, no PII, caching behavior (5min-1h). 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 concise and well-structured, with a clear opening sentence followed by bullet-pointed use cases. Every sentence adds value; no fluff.

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

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

Given the tool's low complexity (one optional parameter, no output schema), the description covers return values, caching, and use cases adequately. It provides sufficient detail for an agent to decide when to invoke this 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?

The only parameter 'window' has an enum in the schema, and the description adds semantic value by explaining that shorter windows highlight current trends while longer windows show steady-state demand. Schema coverage is 100%, but description enhances meaning.

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

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

The description clearly states the tool's purpose: returning top tools, top packs, and total call volume over a recent window. It uses specific verbs and resources, and distinguishes from siblings like 'discover_tools' by focusing on what other AI agents are calling.

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 three explicit use cases (e.g., discovering hot data sources, confirming canonical choice). While it doesn't explicitly state when not to use, the context and sibling tool list (e.g., 'discover_tools') offer 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, non-destructive behavior. The description adds extensive behavioral context: semantic anchor with Jaccard similarity, partition filter, fill check against live CLOB depth, and response structure. No contradictions with annotations.

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

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

The description is well-structured with clear sections and front-loaded purpose. While somewhat verbose with details like 'SEMANTIC ANCHOR:' and 'FILL CHECK:', every sentence adds value given the tool's complexity. Could be slightly more concise but 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?

Given no output schema, the description thoroughly explains return values, including fields like gap_pp, suggested_trade, reasoning, and partition_check details. It also covers edge cases (skipped_low_similarity, placeholder filter) and provides actionable warnings. Complete for a complex tool.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds significant value beyond schema by explaining the operational details of each parameter (e.g., what 'event' does: walks child markets, checks ordering, partition_check) and the output format. Slightly above baseline.

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

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

The description clearly states the tool's purpose: finding arbitrage opportunities on Polymarket via monotonicity violations and partition-sum checks. It differentiates three modes (no args, event, topic) with specific use cases, distinguishing it from sibling tools.

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

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

The description explicitly tells when to use each mode: 'Call with NO args for a trending_scan', 'pass event for the strongest per-event partition_check', 'topic for a themed cross-event scan'. It also gives recommendations and warnings, such as not trading when realizable_edge_pp <= 0 and mentions an alternative tool (polymarket_fill_risk).

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 extensively details the three model families, response structure, caching behavior (1h KV keyed on knobs), and diagnostics for empty results. This far exceeds the annotations which only indicate read-only, idempotent, and non-destructive 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 very long and dense, but is structured with clear sections (model families, knobs, response top-level). Every sentence adds value, though brevity could be improved.

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

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

Given no output schema, the description fully explains the response structure (by_segment, fed_candidates, diagnostics) and all parameters are well-documented in the schema. Annotations cover safety. The tool is adequately specified for an agent to use 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?

All 9 parameters have thorough descriptions in the schema, so the baseline is 3. The description adds context about 'TRADEABLE-EDGE KNOBS' but does not significantly enhance parameter meaning beyond the schema.

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

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

The description clearly states the tool scans Polymarket markets for opportunities where Pipeworx data disagrees with market price. It specifies the use case 'what should I bet on today' and distinguishes from sibling tools that focus on specific aspects like arbitrage or fill risk.

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 context that this tool discovers opportunities without paging through hundreds of markets, implying it's for initial discovery. It lists knobs for filtering, but does not explicitly contrast with sibling tools or state when not to use it.

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 non-destructive. The description adds significant behavioral detail: explains the returned structure (tracked with time-series, trend, decay; expired with lifespan; snapshot dates), notes that gaps indicate no scan, and discloses limits (60-day TTL, decay from daily closes). 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 front-loaded with purpose, then details in a structured format: a question-answer, args, response fields (tracked, expired, snapshot_dates), and limitations. It is somewhat lengthy but every sentence adds information. Minor room for tightening, but overall well-organized.

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 only two parameters and no output schema, yet the description thoroughly explains the output structure (tracked objects with time-series, trends, decay; expired objects with lifespan; snapshot dates) and limitations (TTL, daily vs. intraday). It leaves no major gaps for an agent to understand tool usage and expected results.

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

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

Schema description coverage is 100%, so the schema already documents both parameters well (lookback days with clamp, window family with options). The description adds defaults and some context (e.g., window as 'snapshot family'), but this mostly duplicates the schema. Hence, the description does not add substantial value beyond what the schema provides.

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: 'Edge persistence and decay telemetry built from daily polymarket_edges snapshots.' It answers the specific question 'how long has this edge existed and is it shrinking?', uses a specific verb (tracks, answers), and distinguishes itself from sibling tools like 'polymarket_edges' by focusing on persistence and decay rather than just edge data.

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

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

The description implies when to use: when needing to understand edge persistence (fresh vs. old wide edges). It provides context about decay numbers being from daily closes (not intraday), which helps set expectations. However, it does not explicitly state when not to use or list alternative tools, though siblings are available in the context.

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

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

Annotations (readOnlyHint, idempotentHint, destructiveHint false) are consistent with description, which confirms a read-only check. Description adds context about partial fill risks ('unhedged directional position') and return metrics, providing rich behavioral detail 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?

Description is long but well-structured with clear sections (single-market vs basket) and each sentence provides critical guidance. Slightly verbose due to detailed enumeration of return fields, but efficient given complexity.

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

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

Despite no output schema, description comprehensively lists all return fields for both modes, explains risks (thin books, forced directional legs), and provides context for interpreting results. Covers all aspects needed for an agent to correctly use this 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 has 100% coverage, but description adds significant value: defaults (size_usd=1000), interpretation differences between modes (size interpreted as spend vs target proceeds for single-market; settlement notional for basket), side auto-detection logic for basket. This clarifies parameter usage beyond 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?

Description clearly states it is a 'Realizable-vs-theoretical edge check against live CLOB order-book depth' and distinguishes two modes (single-market and basket). It lists specific return fields, making the purpose highly specific and distinct from siblings like polymarket_arbitrage and polymarket_edges.

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

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

Explicitly states when to use ('before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500') and provides rationale (theoretical overround not capturable, partial fills create directional risk). No ambiguity about 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?

The description goes well beyond the annotations, which only declare readOnly, openWorld, idempotent, and non-destructive behavior. It discloses the matching methodology, compatibility codes, the fact that unknown metric types are never paired, the fee modeling gap, the gross-versus-net spread distinction, and the meaning of null temporal_alignment. This richly supplements the annotations without contradicting 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 long but well-structured and information-dense; the core definition is front-loaded, followed by modes, response shape, safety fields, and limitations. Some repetition exists around compatibility warnings and matching behavior, but nearly every sentence carries operational value, so the length is justified by the tool's complexity.

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

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

With no output schema, the description carries the full burden of explaining return values, and it does so comprehensively: response fields, compatibility codes, per-pair flags, skipped-leg counters, temporal alignment semantics, and the fees disclosure. An agent calling this tool has enough information to interpret results correctly and to notice when returned pairs are unreliable.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful parameter semantics: topic is a pre-mapped shortcut list, the explicit parameters override the topic-mapped sides, both modes run the same matcher, and the explicit mode is for custom pairings. This is genuinely useful context beyond the schema's field-level 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 identifies the tool as computing the cross-venue spread between Kalshi and Polymarket for the same resolving question, and it distinguishes this from sibling tools by emphasizing the cross-venue comparison. It specifies a concrete deliverable — leg-by-leg prices and matched spreads in percentage points — and explains the two modes, so an agent can recognize what the tool does and when it differs from other polymarket tools.

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

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

The description gives explicit guidance on the two usage modes: pre-mapped topic shortcuts versus explicit kalshi_event_ticker plus polymarket_event_slug. It also warns that most pre-mapped topics currently return compatibility warnings and that pre-mapped does not mean tradeable, which is exactly the kind of contextual guidance an agent needs to select the right mode and set expectations.

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

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

Annotations already mark readOnlyHint, idempotentHint, and destructiveHint, so the description carries a low burden. It adds valuable behavioral context: listing keys when omitted, scoping to an identifier, and pairing with remember/forget. 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?

Two sentences packed with essential information: main action, usage guidance, scope, and pairing. No fluff; every sentence earns its place. The most critical action is front-loaded.

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

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

Given the tool's simplicity (one optional parameter, strong annotations, no output schema needed), the description covers all necessary aspects: what it does, when to use it, parameter behavior, and implications (scope). 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%, but the description adds meaning beyond the schema: it explains that omitting the key lists all saved keys. This directly aids the agent in understanding the parameter's optionality and effect.

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 specific verbs ('Retrieve', 'list') and resources ('value previously saved via remember', 'all saved keys'). It clearly distinguishes itself from sibling tools like 'remember' and 'forget' by stating its retrieval function and the option to list keys.

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

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

The description explicitly states when to use the tool: 'Use to look up context the agent stored earlier...without re-deriving it from scratch.' It also mentions pairing with 'remember' and 'forget', providing context for its place among siblings. However, it does not explicitly state when not to use or provide 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 readOnly, idempotent, and non-destructive. Description adds detail: mark_read side-effect (flags events read), and that polling works fine. No contradictions.

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

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

Four concise sentences, each serving a purpose: action, return fields, filter arguments, mark_read behavior, and alternative access. No wasted words.

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

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

No output schema, but description lists returned fields (source, citation_uri, raw payload). Parameters fully covered. Annotations cover safety. Adequate for agent to use correctly.

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

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

Schema coverage is 100% (5 params described). Description adds context: explains 'type' filters subscription type, 'since' uses ISO timestamp, 'mark_read' flag and effect, 'limit' default and range. Adds value beyond schema.

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

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

Description begins with 'Pull fired events from your subscription feed,' clearly stating the action and resource. It distinguishes from siblings like list_subscriptions by focusing on alert content and providing specific return fields.

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 polling works fine and mentions an external endpoint for scripts/dashboards, but does not explicitly exclude cases where other tools (e.g., search_within) might be preferable. Clear context for when to use, but lacks when-not guidance.

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

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

Beyond annotations (readOnlyHint, idempotentHint, openWorldHint), the description details fan-out behavior to multiple sources, fallback from GDELT to GNews, soft-fail for USPTO, and return structure (changes grouped by source, total_changes, citation URIs). 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?

Though a single long paragraph (~100 words), every sentence adds necessary detail. Front-loaded with user-facing example queries, then operational details. Could be more concise with bullet points, but not wasteful.

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

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

For a complex tool with no output schema, the description covers multiple data sources, fallback logic, soft-fail status, return structure, and parameter formats. It fully informs an agent about what to expect and how to use the tool correctly.

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

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

Schema coverage is 100%, so schema already documents parameters. The description adds practical value: example formats for 'since' and a typical monitoring suggestion ('30d' or '1m'), plus clarifying 'value' accepts ticker or CIK. This extra context raises it above baseline 3.

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

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

The description clearly defines the tool as a change feed for a company over a time window, with explicit query examples ('What's new with X') and a list of data sources (SEC, GDELT, USPTO). It distinguishes itself from the sibling 'entity_profile' 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?

Provides explicit guidance: 'Use entity_profile instead when you want the static profile... regardless of window.' This tells the agent when to use this tool versus the alternative, along with implied usage for recent changes.

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 idempotent and non-destructive. Description adds scoping by identifier, persistence for authenticated users, 24-hour retention for anonymous. No contradictions. Could mention overwrite behavior but still strong.

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 efficiently packed: purpose, usage scenario, scoping/persistence, pairing. No fluff, front-loaded.

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

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

For a simple write-only tool with two params, description covers all necessary context: purpose, when, scoping, retention, and companion tools. No output schema needed.

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

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

Schema covers both params with descriptions (100% coverage). Description adds naming conventions and examples (e.g., 'subject_property'). Adds value beyond schema. Baseline 3, plus 1 for context.

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 uses clear verb 'Save' and resource 'data as key-value pairs'. Distinguishes from siblings recall and forget, and specifies scope across sessions.

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: when discovering something worth carrying forward to avoid repeated lookups. Notes pairing with recall/forget. No alternative tools given but sufficient for single-purpose 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 readOnly/openWorld/idempotent/non-destructive, and the description adds substantial behavioral detail beyond those: cascade through multiple lookup endpoints, graceful degradation when GLEIF/OpenFIGI is unavailable, explicit `unresolved` reporting, `figi_candidates` when ambiguous, and source-labeled identifiers. This is rich, non-redundant transparency.

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

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

The description is long but organized into a lead example block, uppercase SUPPORTED TYPES section, and enrichment note. Some sentences are dense and parenthetical-heavy, but each segment earns its place by conveying behavior or caveats.

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 multi-source complexity and absence of an output schema, the description thoroughly covers likely inputs, ambiguity handling, unresolved identifiers, source labeling, and failure degradation. An agent has enough to invoke the tool correctly and interpret results without further guessing.

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 goes far beyond it by detailing exact input formats (ticker, CIK, ISIN, name), ISIN-to-LEI behavior, drug brand/generic examples, and the critical 'ENTITY NAME ONLY' instruction with a bond-issuer example. It prevents a realistic class of caller errors.

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

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

The description clearly states the tool resolves user-spoken names into canonical identifiers (CIK, LEI, RxCUI, FIGI) required by other tools, with concrete example phrasings. It distinguishes itself from entity_profile and compare_entities by positioning resolve_entity as the first-step lookup for names-needing-IDs.

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

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

The description explicitly says 'Use FIRST whenever you have a name but need an ID' and gives many natural-language triggers. It does not explicitly name sibling tools it should not be used for, but the first-step rule and supported-type list provide adequate selection guidance.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds critical behavioral context: it 'probes each entity with ai_visibility_check', 'ranks by score, surfaces which is most/least recognized', and returns 'ranked list with score, confidence, signal density per entity'. This goes beyond annotations without contradicting 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 two sentences long plus a brief parenthetical example. It is front-loaded with the core purpose, then specifies the method (probes + ranks), output structure, and usage context. Every sentence adds value with no redundancy.

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

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

Given the tool's complexity (multi-entity comparison, sub-calls to ai_visibility_check) and no output schema, the description provides complete information: what it does, how it works (probes each entity), output shape (ranked list with score, confidence, signal density), and use case. Annotations cover safety and idempotency. No gaps for effective agent use.

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

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

Schema coverage is 100% with 4 parameters. The description adds meaning by explaining that the first entity in 'entities' is treated as the 'subject for narrative', and clarifies that 'models' supports 'workers-ai (free default)' and 'anthropic (requires _apiKey)'. This supplements the schema's descriptions effectively.

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 'Compare AI visibility across multiple entities side-by-side' and uses a specific verb ('Compare', 'Probes') and resource ('AI visibility'). It distinguishes from sibling tools like ai_visibility_check (single entity) and compare_entities (generic comparison) by specifying the method (probes each with ai_visibility_check, ranks by score).

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

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

The description explicitly frames the tool as 'Useful for competitive AI-marketing audits' and gives a concrete example ('does Claude know about us as well as our competitors?'). It implies when to use this over ai_visibility_check (comparing multiple entities vs. single entity), though it does not explicitly list exclusions or alternatives.

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

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

Beyond annotations (readOnly, openWorld, idempotent), the description discloses that bundlephobia's first measurement can take 5-30s and that sources_failed will list timeouts, with graceful degradation. 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, front-loading the core purpose and then providing details. Slightly long but 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?

Despite lacking an output schema, the description thoroughly lists return fields, explains partial failures, and covers scope and usage. Fully adequate for the tool's complexity.

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

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

Schema coverage is 100% with clear descriptions. The tool description adds no additional info beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: a composite check for deciding whether to add an npm package, combining deps.dev and bundlephobia data. It distinguishes itself from siblings by specifying npm ecosystem and the one-call aggregation.

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

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

Explicitly tells when to use (agent asks 'is X safe/popular/small') and when not (PyPI/Maven/Cargo/Go fall under deps.dev:version directly). Also mentions partial failure behavior.

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

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

Annotations indicate read-only, open-world, idempotent, and non-destructive behavior; the description adds substantial detail: uses BGE-base-en embeddings, cosine similarity over 500-char overlapping windows, 200K char cap with truncation flag, and character offsets in results. No contradictions; transparency is high.

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

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

The description is well-structured with a clear, front-loaded first sentence. It covers purpose, usage, and technical details in about 6 sentences without redundancy. Slightly verbose in some areas (e.g., repeating the pairing advice), but overall 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's complexity (3 parameters, no output schema) and rich annotations, the description fully covers what the tool does, how it works (embedding details, truncation, offsets), and when it should be used. It also addresses integration with a sibling tool. No gaps detected.

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 significantly beyond the schema: it reiterates the max chars for text, default and range for limit, and the nature of the query. No additional depth or nuance is provided.

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

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

The description clearly states the tool performs semantic search inside a fetched record. It specifies the resource (the text parameter) and action (return top-N passages with character offsets and similarity scores). It distinguishes itself from sibling tools by mentioning pairing with ask_pipeworx_grounded and contrasting with fetching the whole document.

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

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

The description explicitly advises using the tool when the record is too large for the prompt and highlights the context-saving benefit. It also mentions a complementary tool (ask_pipeworx_grounded). Lacks explicit when-not-to-use guidance, but context is clear enough.

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

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

Annotations declare readOnlyHint=false, idempotentHint=true, destructiveHint=false. The description adds significant behavioral context: OAuth requirement, delivery channel specifics (email, SMS with 10/day cap, webhook HMAC signing and auto-disable after 10 failures). It also lists type-specific parameter examples, all of which go 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 front-loaded with the core purpose and prerequisites. It is dense but well-organized: purpose, requirement, type examples, delivery channels. Some details (e.g., exact HMAC formula) could be abbreviated, but the structure is logical and 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?

Given the complexity (3 parameters, nested objects, enums, no output schema), the description covers all aspects: purpose, prerequisites, all subscription types with concrete examples, delivery channel options and constraints (verification, caps, webhook auto-disable). The return value ('new subscription id') is stated. No gaps remain for an agent to call the tool incorrectly.

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 schema descriptions are minimal ('Subscription type.', 'Type-specific filter.'). The tool description provides detailed examples for each enum type (sec_8k with items, fred_series with series_id) and explains delivery sub-parameters (SMS must match verified phone, webhook signing secret returned once). This adds substantial meaning beyond the schema.

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

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

The description clearly states 'Create a proactive monitoring subscription to a live-data event stream. Returns the new subscription id.' This is a specific verb-resource pair (create subscription) and distinguishes the tool from siblings like list_subscriptions 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?

Description notes prerequisite (Pipeworx OAuth account) and lists supported types and delivery channels, implying when to use. However, it does not explicitly contrast with alternative tools (e.g., use list_subscriptions to view existing ones, unsubscribe to remove). The context is clear but lacks explicit 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, non-mutating query. The description adds valuable detail about the output structure: it returns category-bucketed example questions with exactly how to call other tools. 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 moderately long but well-structured. It begins with example user queries, then defines the output, the parameter usage, and finally the recommended use case. Every sentence adds essential information, though a minor trim could improve flow. It earns a 4 for efficiency and clarity.

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

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

Given the tool's simplicity (one optional parameter, no output schema), the description thoroughly covers what the tool returns, how to use it, and when to use it. It explains the nine categories and the fact that results are drawn from a live catalog of thousands of tools. No additional information is needed for effective use.

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

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

Schema coverage is 100% for the single optional parameter 'topic', with a description of allowed values. The description adds context by explaining that omitting the parameter gives a full cross-category spread, while passing a topic focuses on that category. It also lists example topic values, reinforcing 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 starts with concrete user intents ('What can I ask Pipeworx?', 'give me ideas') and immediately positions the tool as 'the onboarding entry point'. It specifies the unique output: 'category-bucketed example questions ... each with the exact tool + argument shape'. This clearly distinguishes it from sibling tools like 'discover_tools' or 'ask_pipeworx'.

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

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

The description explicitly states when to use: 'Use this FIRST when you do not yet know what Pipeworx can do for you'. It also explains how to narrow results with the optional 'topic' parameter. While it doesn't list explicit alternatives, the context implies that after using this tool, users should move to specific tools like 'ask_pipeworx' or 'entity_profile'.

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 idempotentHint=true and destructiveHint=false; description adds that rows are 'deactivated (not deleted)' and historical events remain available. This explains the soft-delete behavior beyond annotations, with 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?

Two sentences: one for action, one for side-effect and constraint. No redundant phrasing, front-loaded with the primary purpose.

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

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

For a simple mutation with one parameter and no output schema, the description covers the essential: what it does, who can use it, and the effect (soft delete). References to 'recent_alerts' provide helpful linkage.

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% (single 'id' parameter with description 'Subscription id (uuid) returned by subscribe'). Description merely references 'id' without adding new semantic detail, meeting baseline but not exceeding.

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 action ('Cancel a subscription by id') and resource ('subscription'). Explicitly distinguishes from sibling tools like 'subscribe' (which creates) and 'list_subscriptions' (which lists).

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 ownership enforcement ('only cancel your own subscriptions'), providing clear context. Does not explicitly contrast with siblings for when-not-to-use, but the restriction is clear and the purpose is well-defined.

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

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

Annotations already mark this as read-only, open-world, and idempotent, but the description adds significant behavioral context beyond that: it details the two routing paths, returns a verdict enumeration, explains the nuanced difference between could_not_verify and unsupported (with verification_error extension), and clarifies that could_not_verify is not evidence for or against the claim. This is rich, actionable transparency that the annotations alone don't provide.

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

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

The description is longer than typical but every sentence carries load: examples, use-case, routing, return contract, and an explicit caller warning. It is front-loaded with the most important info (what it does and when to use) and well-structured with the IMPORTANT caveat separated. Minor redundancy (e.g., 'grounded pipeline' vs 'grounded or structured') but overall 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?

Despite having no output schema, the description fully specifies the return contract (verdict enum, actual value with citation, reasoning) and the error semantics. It also anticipates a critical caller mistake (treating could_not_verify as evidence) and defines unsupported. Given the tool's complexity, this description is remarkably complete without being bloated.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds extra meaning: it provides realistic examples for claim and explains that tolerance_pct overrides the wording-implied tolerance and suggests 1–2 for hallucination detection. This goes beyond the schema descriptions and helps the agent choose appropriate values.

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

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

The description clearly identifies the tool as a fact-checker for natural-language claims, provides explicit example phrasings, and distinguishes it from sibling tools by specifying the two distinct verification paths (SEC EDGAR for financial claims, grounded pipeline for others). The verb "validate" and the resource "claim" are specific, and the description clearly differentiates this from general Q&A 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?

It explicitly states "Use whenever the agent needs to check whether something a user said is factually correct," which gives clear intent. It also explains that it replaces 4–6 sequential calls, implying when to use it instead of manual pipeline composition. However, it doesn't explicitly mention when NOT to use it or name alternative sibling tools for non-claim queries, so it falls short of the top score.

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