Sports

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds valuable behavioral context: the free default model, the requirement of an API key for Anthropic and that the user pays Anthropic directly, and the structured return format. It goes beyond 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?

Three sentences, front-loaded with the core action, and no wasted words. It packs all key information (purpose, default behavior, cost implication, return format, use cases) into a compact, scannable description.

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 explicitly lists the per-model return fields and combined view. It covers the tool's functionality, parameter behavior, cost boundaries, and practical use cases, making it complete for a read-only probing tool with well-defined schema.

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 already explains all parameters. The description reinforces the relationship between 'models' and '_apiKey' (key only needed if anthropic is in models), but adds no new semantic meaning beyond what the schema provides. This matches the baseline for fully documented schemas.

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 ('Probe') and resource ('LLMs') for a defined goal: scoring visibility (0-100) per model. It distinguishes itself from sibling tools by focusing on general business/brand/topic visibility scoring across multiple LLMs, and includes the exact output shape (per-model score, confidence, signals, raw_response).

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

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

Provides explicit use cases ('AI-marketing audits, pre-launch brand checks, competitive monitoring') and explains the default model vs. opt-in Anthropic with BYO key. However, it doesn't name alternative sibling tools or explicitly say when not to use this tool, so it lacks a direct exclusion.

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

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

Annotations already indicate read-only, open-world, idempotent, and non-destructive behavior. The description adds substantial context: it routes to 5,529 tools across 1,455 sources, fills arguments, returns structured answers with stable pipeworx:// citation URIs, and works on every tier in one fast call. This goes beyond annotations by describing internal routing and output format, and it does not contradict the safety hints.

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, starting with a clear directive and using examples to illustrate usage. It front-loads the most important information and compresses details into lists. While slightly verbose and with minor redundancy ('START HERE' echoes 'PREFER OVER WEB SEARCH'), every section adds value, so it earns a 4.

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

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

For a tool without an output schema, the description explains the return value ('structured answer with stable pipeworx:// citation URIs') and performance characteristics ('one fast call'). It covers the full decision space with alternatives, examples, and entry-point guidance, making it self-sufficient for an agent to decide when and how to use it.

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

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

The input schema describes all parameters (question plus five aliases) with 100% coverage, so the schema already provides the necessary meaning. The description does not add parameter-level detail beyond the schema. With high schema coverage, a baseline score of 3 is appropriate; the description neither helps nor hinders parameter understanding.

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 ask_pipeworx as a general-purpose factual question-answering tool that routes to 5,529 verified sources and returns structured answers with citations. It explicitly distinguishes itself from sibling tools like ask_pipeworx_grounded and deep_research, and states 'START HERE for most questions.' The verb 'routes' and 'returns' makes the core function specific and unambiguous.

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

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

The description provides explicit when-to-use guidance: 'PREFER OVER WEB SEARCH' and lists trigger phrases ('what is', 'look up', 'find', etc.) along with a wide range of data categories. It also names alternatives: 'for a hallucination-resistant single answer... use ask_pipeworx_grounded; for a broad/multi-part question... use deep_research.' This is exemplary usage guidance with clear 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?

Beyond the annotations (readOnly, openWorld, idempotent, non-destructive), the description explains the live experimental nature, the fact that no candidate is currently active, and that results are compared against the stable router. This adds meaningful context that annotations alone do not 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 about 5 sentences but each sentence carries useful information: beta identity, state, usage, and fallback behavior. It is front-loaded with the key 'Beta version of ask_pipeworx' phrase and avoids fluff, though the exact date may become stale.

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

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

The description covers purpose, current status, usage instructions, and explicitly says 'this IS a full working router' to counter fallback misconceptions. It references 'same response shape' to cover return values, but does not elaborate on the response format or fully differentiate from the grounded sibling, leaving small gaps.

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

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

Schema coverage is 100% with all aliases documented, so the description does not need to re-explain parameters. It only says 'same arguments' which adds minimal semantic value 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 identifies this as a beta version of ask_pipeworx and explicitly states it is an identical universal router with the same tools, arguments, and response shape. It distinguishes itself from the stable ask_pipeworx sibling by highlighting the experimental routing improvements and current inactive state.

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 it exactly like ask_pipeworx when you want the newest routing', which tells the agent when to use it. It also notes that it currently matches ask_pipeworx exactly, but it does not explicitly mention when not to use it or compare with ask_pipeworx_grounded.

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: true, openWorldHint: true, idempotentHint: true) establish safety and idempotency, but the description adds critical behavioral details: it uses ONLY tool result content, returns explicit refusal reasons (not_in_source, no_tool_match, etc.), provides evidence verbatim, and incurs an extra LLM call. These traits inform the agent about error handling, cost, and fidelity beyond what annotations convey.

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

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

The description is three dense sentences, front-loaded with the primary purpose ('Hallucination-resistant answer mode for high-stakes reads'). Each sentence contributes unique information: mode behavior, return/refusal format, and usage guidance. No filler or redundant wording.

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 compensates by spelling out the exact success response fields and the refusal reason enum. It also covers cost implications and when to use it, making the tool's behavior and limitations fully specified for an agent.

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

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

The schema already documents a single 'question' parameter with six aliases, giving 100% coverage. The description does not add parameter-level detail beyond referencing natural language questions; it focuses on the tool's behavior. With full schema coverage, a baseline of 3 is appropriate.

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

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

The description clearly identifies the tool as a 'hallucination-resistant answer mode' that routes through the same pipeline as ask_pipeworx but extracts answers using only tool results. It explicitly distinguishes itself from sibling ask_pipeworx by emphasizing grounded, high-stakes usage, covering the specific verb (answer) and resource (grounded answers from tool lookup).

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

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

The description provides explicit when-to-use guidance: 'Use whenever an answer will be quoted, cited, or acted on...' and contrasts with the alternative by stating 'prefer ask_pipeworx for casual lookups' due to an extra LLM call cost. This gives clear decision criteria and names the sibling tool ask_pipeworx.

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?

Despite having annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false), the description adds substantial behavioral detail: the resolver contract (market_match_confidence, match_score, alternatives), safety short-circuit (status:'low_confidence_match'), market closed handling (status:'market_closed_or_inactive'), wide-spread illiquidity warning, and resolution-rule risk (cancellation_rule parsing, refund_50_50). These go well beyond the annotations and disclose edge cases the agent needs to know.

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

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

The description is long but front-loaded with the core purpose in the first sentence. It uses all-caps section headers (RESOLVER CONTRACT, PARENT_EVENT EXTRACTOR, NEWS FIELDS, SAFETY, RESOLUTION-RULE RISK) to structure dense information. However, some content like detailed fan-out examples (NVDA-vs-AAPL, Yankees WS) is illustrative but not essential, making it somewhat longer than strictly necessary.

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

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

With no output schema, the description takes full responsibility for explaining return values. It does so comprehensively: result.market fields (best_bid, best_ask, spread_pp, etc.), result.analysis fields (model_probability, edge_pp, kelly_fraction_half, 24h-move warning), result.evidence keyed by source, resolver match statuses, parent_event partition data, news fallback flags, and resolution-rule risk. This is a complete contract 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 parameters are already well documented (market, depth, include_raw). The tool description does not add parameter-level semantics beyond giving an example of market input (slug/URL/question) which is also in the schema. It does mention fan-out and data pack sizes, but not directly tied to parameters. 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 opens with a specific action: 'Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call.' It clearly identifies the resource (Polymarket bet), the method (fan-out to Pipeworx data packs), and the output (evidence packet + comparison). It further distinguishes scope with classifiers and fan-out examples, differentiating it from sibling tools like polymarket_edges or validate_claim.

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 usage contexts: 'Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z".' This gives clear contexts but does not mention when not to use the tool or point to alternatives among siblings, such as polymarket_edges for simpler edge calculations or validate_claim for fact-checking. So it has context but no 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 readOnly, idempotent, and non-destructive behavior. The description adds substantial context: data sources (SEC EDGAR/XBRL for company, FAERS/FDA for drug), correct handling of off-calendar fiscal years, sorting by primary metric, and return of paired data with pipeworx:// citation URIs. No contradiction with annotations.

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

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

The description is dense and front-loaded with trigger phrases and clear purpose. Although longer than typical, every sentence adds useful detail for a dual-type comparison tool. A slight reduction in trigger phrase enumeration would improve conciseness, but the structure remains 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?

Even with no output schema, the description explains return format ('paired data + pipeworx:// citation URIs') and sorts results by primary metric. It covers both entity types, their data sources, and edge cases like off-calendar fiscal years, making the tool's behavior fully predictable for an agent.

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

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

Schema coverage is 100% with basic descriptions, but the tool description significantly enriches parameter meaning. For company type, it specifies 'pulls LATEST 10-K revenue + net income + cash + long-term debt' and gives ticker examples. For drug type, it lists FAERS adverse-event counts, FDA approval counts, and active trial counts. Examples like 'AAPL' and 'ozempic' clarify expected value formats.

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 function: 'side-by-side comparison of 2–5 companies or drugs in ONE parallel call.' It uses a specific verb ('compare') and resource ('entities'), and differentiates from sibling single-entity tools by noting it 'Replaces 8–15 sequential lookups' and 'ALWAYS PREFER over sequential single-pack lookups when comparing entities.'

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

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

Explicit trigger phrases are provided ('Compare X and Y', 'X vs Y', 'which is bigger') along with clear guidance to prefer this tool over sequential lookups. It also distinguishes use cases for type='company' vs type='drug', giving context on when each mode is appropriate.

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

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

Beyond the annotations, the description discloses many behavioral traits: decomposition into facets, parallel routing across 5,529 tools, the findings packet structure (verbatim evidence, confidence, source, fetched_at, pipeworx:// citation), gaps[] for unanswered questions, contradictions[] for certain depths, hop field, citation_uri resolvability, semantic excerpting, expected latency, and account/paid-tier requirements. This is rich context well 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 long but front-loaded with critical prerequisites (account required) and a key distinction from ask_pipeworx. Every sentence adds value for a complex tool, though there is minor redundancy (e.g., contradictions[] mentioned twice). It is structured with clear topic segments and concrete examples, making it densely informative rather than 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?

With no output schema, the description fully carries the burden of explaining return values (findings packet with evidence, confidence, source, fetched_at, citations), edge cases (empty gaps for breaking news), prerequisites (account/paid plan), latency, and iteration semantics. For a tool of this complexity, the description is remarkably complete.

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

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

Though the schema covers both parameters, the description adds significant operational meaning: it explains depth levels in concrete terms (quick=3 facets, standard=5 with gap recovery + contradictions, thorough=8 paid with iterative hop), clarifies that the question parameter supports broad/multi-part natural language, and notes the paid restriction for 'thorough' which is absent from 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 performs 'grounded multi-source research across Pipeworx's 1455 STRUCTURED data sources in ONE call', decomposes questions, routes to tools in parallel, and returns a findings packet. It also explicitly distinguishes itself from ask_pipeworx and clarifies it is NOT open-web search, differentiating 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 provides explicit when-to-use and when-not-to-use guidance: 'Best for broad/multi-part questions over structured data', 'For a single lookup use ask_pipeworx', and 'For BREAKING or colloquial CURRENT-NEWS... prefer ask_pipeworx.' It also mentions account requirements and the caveat that deep_research returns mostly empty gaps for topics not in the structured catalog.

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 cover readOnly, idempotent, and destructive hints. The description adds valuable behavioral context: it returns top-N tools with full input schemas and curated examples, and emphasizes that results are 'ready to call directly, no second schema lookup needed.' This goes beyond the annotations but does not mention rate limits or relevance criteria, so not a 5.

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

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

The description is three sentences with strong front-loading ('Find tools by describing the data or task'). The middle sentence is long with many domain examples, but it is informative and directly supports the purpose. Each sentence earns its place, though it could be tightened.

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 is a simple query-based discoverer with no output schema, the description sufficiently explains what it returns (names, descriptions, schemas), when to use it, and that results are directly callable. It lacks details on how relevance/top-N works, but this is not critical for a discovery 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% and the schema already explains that 'query' accepts natural language and lists aliases. The description's phrase 'describing the data or task' mirrors the schema but adds no new semantic detail. Baseline 3 is appropriate since the schema carries the burden.

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

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

The description opens with a specific verb-resource pair: 'Find tools by describing the data or task,' and clearly enumerates the domains (SEC filings, FDA drugs, etc.). It distinguishes itself from sibling tools by explicitly stating its output (tool names, descriptions, schemas), making it clear this is the discovery tool, not a task-execution 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?

The description explicitly says 'Use when you need to browse, search, look up, or discover what tools exist' and closes with 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' This gives strong when-to-use guidance and implicitly contrasts with tools that provide direct answers, satisfying the dimension fully.

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 richly discloses behavior beyond annotations: it lists data sources (SEC EDGAR, XBRL, USPTO, news, GLEIF), notes the patents API sunset with soft-fail behavior, describes fallback (GDELT→GNews), and specifies return fields. This aligns with annotations and adds significant context.

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

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

The description is dense but well-structured, starting with user examples, then the core function, then return details. It is longer than necessary, but each part adds useful guidance for intent matching and expected output.

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 multi-source profile tool with no output schema, the description is comprehensive: it covers inputs, sources, output fields, limitations, fallback behavior, and alternatives. The agent has sufficient context to invoke correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description echoes schema details (ticker/CIK format, no names) but does not add new semantic meaning beyond what the schema already 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 function: 'full cross-source profile of a US public company in ONE parallel call.' It provides concrete example queries and distinguishes itself from sibling tools by explicitly preferring it over chaining single-pack 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?

Explicit guidance is given: 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view.' It also directs users to resolve_entity when only a name is available, clarifying when not to use this tool.

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

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

Annotations already mark destructiveHint=true and idempotentHint=true. Description adds some context that deletion targets 'sensitive data the agent saved earlier', but mostly restates the delete semantics without new behavioral details like permanence or missing-key handling.

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

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

Two sentences, front-loaded with the action, no filler. Every sentence earns its place: action, use cases, complementary tools.

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 single-parameter tool with strong annotations, the description covers purpose, usage conditions, and related tools. Leaves out behavior for missing keys, but idempotentHint mitigates that gap.

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 'key' parameter is described as 'Memory key to delete' in the schema. Description adds no additional meaning beyond saying 'by key', so baseline 3 applies.

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

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

Description opens with 'Delete a previously stored memory by key' – a specific verb and resource. It clearly distinguishes from siblings like remember and recall, which store and retrieve respectively.

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 context is stale, the task is done, or you want to clear sensitive data the agent saved earlier.' Also mentions complementary tools: 'Pair with remember and recall.'

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, and destructiveHint=false. The description adds useful context by describing the fetch-and-extract process and the output format as a text blob, which goes beyond the annotations. No contradictions were found.

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

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

The description is three sentences, front-loaded with the main purpose, then the process, then use cases. Every sentence contributes meaning without redundancy. It is concise and well-structured for quick comprehension.

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

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

For a tool with two parameters, rich annotations, and no output schema, the description explains the output as a single text blob and provides usage context. It does not detail potential edge cases or failures, but given the tool's simplicity and annotation coverage, it is adequately complete. It could clarify why this differs from sibling scan tools, but that is a minor gap.

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 provides complete descriptions for both parameters (url and max_links), covering 100% of the schema. The description itself does not add much parameter-specific detail, but it does mention 'key links' which relates to the output. Baseline 3 is appropriate since the schema already carries the load.

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

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

The description clearly states the tool's purpose: generating a production-ready llms.txt file for any URL. It uses a specific verb (generate) and resource (llms.txt file), and explains the process (fetches, extracts, emits). The output format is distinct from sibling tools like scan_competitor_ai_presence, even though there is overlap in the audit use case.

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

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

The description provides clear use cases (client indexing, drafting for own project, auditing competitors), which gives a strong sense of when to use it. However, it does not explicitly state when not to use it or mention alternative tools, so it falls short of the full explicit 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 and destructiveHint=false, so the description's safety profile is covered. The description adds value by disclosing the exact return fields (id, type, params, etc.) and clarifying the 'caller's' scope, which is useful behavioral context not present in annotations.

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

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

Two concise sentences. The first states the core purpose, the second lists return fields and provides the primary use case. Every sentence adds value, and the most important information 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 list tool with one optional parameter, the description covers what it does, what it returns, and when to use it. Annotations handle the safety profile, so no further behavioral detail is needed. The description is complete for this 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 a clear description for include_inactive, and the description does not need to repeat it. The description adds a subtle hint about 'active subscriptions' aligning with the default false, but does not elaborate further. 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 action ('List') and the resource ('the caller's active subscriptions'). It goes beyond a simple label by specifying the exact scope and what is returned, and it distinguishes itself from sibling tools like subscribe/unsubscribe by focusing on review and cancellation preparation.

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 adding more or to find an id to cancel.' This gives clear context for using this tool as part of a larger workflow, and implicitly contrasts with subscribe/unsubscribe tools for mutation actions.

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 rich behavioral context beyond the annotations: filing returns a claim_token for later status checks, rate limits apply (5/day/identifier), it's free with no tool-call quota, and the team reads digests daily. This sets accurate expectations about side effects and the two-phase workflow.

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 long, every sentence earns its place: it front-loads the core purpose, then covers use cases, exclusions, token workflow, and rate limits without redundancy. The length is proportionate to the tool's complexity and the density of important 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?

The description fully covers the usage workflow, including the two-phase claim_token flow, rate limiting, and quota behavior. Since there is no output schema, the description sufficiently explains what the agent can expect (a token now, a status later) and when to use each parameter.

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 genuinely useful parameter guidance: claim_token should be passed alone, message should be specific and avoid pasting end-user prompts, and type values are mapped to concrete scenarios. This goes beyond just restating 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 uses a specific verb+resource ('Tell the Pipeworx team something is broken, missing, or needs to exist') and immediately distinguishes itself from sibling tools by limiting scope to tools served by this Pipeworx connection. It clearly answers 'what does this do' without ambiguity.

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

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

The description provides explicit when-to-use guidance for each feedback type (bug, feature, data_gap, praise) and a clear exclusion: tools from other MCP servers should be filed there. It also gives a practical heuristic ('Pipeworx tool names are the ones this connection lists') for identifying the intended subject.

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

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

Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds meaningful context: self-aggregating from an analytics engine, no PII, just (pack, tool, count), and caching for 5min-1h. This goes beyond 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 well-structured: a front-loaded first sentence stating the core function, a bulleted 'Useful for' section for scanning, and a concise closing on data source, PII, and caching. Every sentence earns its place with no redundancy or 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?

With no output schema, the description adequately explains the return shape ('just (pack, tool, count)') along with caching and privacy. It covers use cases and the nature of the data. It could mention pagination or response limits, but for a trending/top-list tool the description is sufficiently complete.

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

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

Schema coverage is 100% and the schema description fully explains the window parameter ('Shorter windows surface what's hot right now; longer windows show steady-state demand'). The main description only lists the enum values without adding further semantic 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 opens with a clear, specific statement: 'What other AI agents are calling on Pipeworx right now' and lists the exact outputs (top tools, top packs, total call volume). This distinguishes it from siblings like discover_tools by focusing on aggregate popularity rather than search-based discovery.

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

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

The 'Useful for' section provides three concrete use cases: discovering hot data sources, confirming canonical tool choice, and checking alignment with agent needs. It implies when to use it but doesn't explicitly name alternative tools or 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 indicate a read-only, idempotent, non-destructive operation. The description goes further with rich behavioral context: the Jaccard similarity threshold (≥0.30), the skipped_low_similarity counter, the >20% placeholder fraction returning null, and the fill check using live CLOB depth (realizable_edge_pp ≤ 0 meaning do not trade).

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 with bold section labels and a front-loaded core purpose. Every section covers a necessary aspect (modes, thresholds, output, fill check), though it could be slightly trimmed without losing value.

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

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

With no output schema, the description appropriately spells out the response shape (opportunities[], partition_check with fields) and covers edge cases (null signal when placeholder fraction >20%, fill-check behavior). It is 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?

Although schema descriptions for 'event' and 'topic' provide baseline semantics, the description adds concrete examples (slugs like 'fed-decision-may-2026', seed questions), notes that full URLs are accepted, and explains the deeper mode differences (walking child markets, flattening related events, computing partition_check). This goes well beyond the schema.

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

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

The description opens with a clear verb+resource: 'Find arbitrage opportunities on Polymarket', and specifies the method ('monotonicity violations + partition-sum checks'). It distinguishes from sibling tools like polymarket_edges by focusing on arbitrage and by outlining three distinct modes (trending_scan, event, topic).

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

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

Explicit guidance is given for each scenario: call with no args for trending_scan, pass 'event' for a specific marked event, pass 'topic' for cross-event scanning. It also directs to polymarket_fill_risk for custom sizing, naming an alternative 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 only say read-only/idempotent. The description adds substantial behavioral detail: 1h KV caching, three response segments, five model families with specific formulas, per-sport bias correction, placeholder filters, 24h-move warnings, and diagnostics. This goes far beyond the annotation safety profile.

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

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

The first two sentences are front-loaded with purpose, and every sentence carries technical content. However, the description is extremely long and dense, including exact alpha values and run-8 gate comparisons that could be moved to supporting docs. Appropriate for a complex tool, but slightly over-stuffed.

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 documents the response top-level (by_segment, fed_candidates, _diagnostics), the edge fields carried on opportunities, the 24h-move warning, and the caching behavior. It even explains why segments may be empty and how knobs affect output, making it effectively complete.

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

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

Schema coverage is 100%, but the description meaningfully enriches the parameters: slippage_pp explains fee context, min_partition_leg_kelly clarifies why min_kelly doesn't apply to baskets, and the tradeable-edge knobs are grouped with intent. It explains cross-parameter behavior not obvious from individual schema descriptions.

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

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

The description opens with a specific verb ('scan') and resource ('top Polymarket markets') and clearly states the output: opportunities where Pipeworx data disagrees with market price. It also frames the use case ('what should I bet on today') and distinguishes itself from sibling edge/arbitrage tools by focusing on model-driven discovery.

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

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

It gives strong contextual guidance: built for daily bet discovery, explains segments, Fed bets excluded, and diagnostic reasons for empty output. However, it does not explicitly name sibling alternatives or state when to prefer one of the other Polymarket tools, so it misses the 'when-not' criterion.

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

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

Beyond the annotations (read-only, idempotent, non-destructive), the description discloses critical behavioral details: data depends on daily snapshots written on cache-miss (so gaps mean no scan), history is limited by a 60-day TTL, decay is computed from daily closes of |edge_pp_net|, and negative values indicate SELL YES. This gives the agent a robust understanding of data quirks and semantics.

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

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

The description is lengthy but well-structured with 'Args', 'RESPONSE', and 'LIMITS' sections. Each part provides necessary operational details for a complex tool. Some explanatory flourishes, like 'the latter is wide for a reason nobody is willing to take,' are engaging but could be trimmed without losing meaning, preventing a 5.

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

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

With no output schema, the description fully explains the return value structure: tracked[] with time-series, trend, decay; expired[] with lifespan; and snapshot_dates[]. It also covers important limitations (TTL, data gaps, decay basis), making the tool self-sufficient 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?

The input schema already describes both 'days' and 'window' with clear meaning, defaults, and allowed values (100% coverage). The description repeats the defaults and adds the phrase 'snapshot family,' but does not materially enrich parameter understanding beyond what the schema provides. Baseline of 3 applies.

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

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

The description clearly identifies the tool as edge persistence and decay telemetry built from daily polymarket_edges snapshots, and explicitly states the question it answers ('how long has this edge existed and is it shrinking?'). This distinguishes it from siblings like polymarket_edges, which likely provides current edge data, and polymarket_arbitrage, which focuses on arbitrage opportunities.

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

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

The description implies usage context by contrasting a fresh wide edge with a 3-week-old wide edge, indicating when an agent would need historical edge persistence information. However, it does not explicitly mention alternatives or exclusion criteria, though the specificity of the tool's purpose makes its use case clear.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, but the description adds significant behavioral context: it walks the order book, returns specific verdicts (clean|degraded|cannot_fill), identifies thin legs and forced directional risk, and warns that partial basket fills convert an arb into unhedged directional exposure. 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 well-structured with clear mode breakouts and front-loaded purpose. Every sentence carries information, but it is dense enough that parsing requires careful reading. Could be slightly trimmed without losing value, but the organization compensates for the length.

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 enumerates return fields for both modes, explains the interpretation of key outputs (vwap_fill_price, capture_ratio, thin_legs), and provides the business context for why this matters (partial fills → unhedged risk). It is complete for a complex tool with two distinct modes.

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 critical semantics beyond field labels: it explains size_usd's differing interpretation in single vs basket mode, the default side behavior, and the requirement that exactly one of market or event be provided. This goes well beyond the schema descriptions.

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

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

The description opens with a specific verb+resource ('Realizable-vs-theoretical edge check against live CLOB order-book depth') and clearly distinguishes itself from siblings by naming polymarket_arbitrage and polymarket_edges as the signals this tool should precede. It also enumerates the two modes (single-market and basket), making its scope unmistakable.

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

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

Explicitly states when to use: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500'. It also provides mode-specific prerequisites (pass market or event) and explains the logic for side selection, giving the agent clear decision criteria.

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

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

Beyond the annotations (read-only, idempotent, open-world), the description thoroughly discloses behavioral traits: it flags non-equivalent bet shapes, exposes skipped comparisons, and explains that temporal misalignment makes spreads meaningless. It also clarifies that pre-mapped ≠ tradeable. This far exceeds the safety profile already conveyed by 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?

The description is dense but well-organized, covering purpose, modes, response fields, safety warnings, and caveats in one flowing paragraph. It packs a lot of information, but every sentence earns its place. A slight reduction in repetitive detail about skipped_cross types would make it more succinct, but overall it is appropriately sized for the tool's complexity.

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

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

With no output schema, the description carries the full burden of explaining return behavior. It names the key response fields (leg-by-leg prices, matched spread, top_spreads_pp), and thoroughly explains safety fields and their meanings. It also sets expectations about real-world viability ('most pre-mapped topics return compatibility_warning today'). This is a complete picture for a complex cross-venue 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 input schema already covers 100% of parameters with descriptions, but the tool description adds substantial meaning: it defines the two modes, lists the exact topic shortcuts, explains how explicit ticker/slug overrides work, and notes that the topic shortcuts auto-fetch matching events. This enriches the schema's dry list with actionable usage semantics.

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

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

The description opens with a specific verb+resource: 'Cross-venue spread between Kalshi and Polymarket for the same resolving question.' It clearly distinguishes this from sibling tools by its cross-venue focus, and further clarifies two operational modes (topic vs explicit ticker/slug). The purpose is immediately understandable and unique.

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

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

The description explains when the tool is useful (when bet shapes are equivalent) and when it will warn the user (compatibility_warning, temporal_alignment). It also cautions that pre-mapped shortcuts often return warnings, so users know what to expect. However, it does not explicitly contrast with alternatives like 'polymarket_arbitrage' or say 'use this instead of X', so it stops short of full usage guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so safety profile is covered. Description adds that the tool is scoped to the caller's identifier (anonymous IP, BYO key hash, or account ID) and explains the list-all behavior when omitting the key, which goes beyond annotations.

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

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

Three sentences, front-loaded with the core action, then usage context, then scoping and related tools. No filler, though the third sentence could be split or trimmed slightly without loss.

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

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

For a simple tool with one optional parameter, safe annotations, and no output schema, the description covers main functionality, scoping, and sibling relationships. It does not describe return format or missing-key behavior, but those are not critical for such a 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 with a clear description of the 'key' parameter. The tool description essentially repeats the omit-key-to-list behavior but adds context about what keys may represent (ticker, address, notes), adding marginal value.

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

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

Description uses specific verbs 'Retrieve' and 'list all saved keys', clearly defines the resource (memory saved via remember), and distinguishes from sibling tools like remember and forget by stating its read-only lookup role.

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

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

Explicitly states when to use the tool: 'Use to look up context the agent stored earlier' with concrete examples (ticker, address, research notes). Also names alternatives (remember to save, forget to delete) and advises against re-deriving from scratch.

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 explicitly describes a state-changing behavior: 'Set mark_read:true to flag returned events read so the next call only shows newer ones.' This contradicts the annotation readOnlyHint: true, which indicates the tool is read-only. This is a clear annotation contradiction, so transparency score is 1.

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 opening purpose, followed by return fields, filtering options, mark_read behavior, and a note about polling/alternative access. It is somewhat dense but every sentence adds relevant information. It earns a 4 for being efficient and front-loaded, though not as ultra-concise as the TDQS 4.3 example.

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

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

Despite no output schema, the description covers what the returned events carry (source, citation_uri, raw event payload) and explains the mark_read side effect and polling suitability. For a read tool with 5 parameters, this is fairly complete. However, the contradiction with annotations and the lack of explicit return format details keep it from a 5.

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

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

The schema already covers 100% of parameters with descriptions, so baseline is 3. The description adds value by providing a concrete example for type ('sec_8k'), explaining the effect of mark_read (flags events read and affects subsequent calls), and clarifying the 'since' parameter as ISO timestamp. This goes beyond the schema, earning a 4.

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

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

The description opens with 'Pull fired events from your subscription feed,' which clearly states the action (pull) and resource (fired events from subscription feed). It distinguishes itself from sibling tools like list_subscriptions and recent_changes by focusing on alerts/events and mentioning the evaluator's persisted feed, making its purpose unmistakable.

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

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

The description provides implicit usage guidance by explaining filtering (by type and since) and the mark_read flag, but it does not explicitly contrast this tool with alternatives like recent_changes or ask_pipeworx. It does mention the same feed is available via a GET URL for scripts, which is alternative access but not a tool alternative. Overall, usage context is present but not explicit about when to prefer this tool over siblings.

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

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

Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint false), the description discloses internal fan-out to SEC EDGAR, GDELT→GNews fallback behavior (rate-limited or 5xx), USPTO PatentsView sunset causing soft-fail, and return structure (changes[] grouped by source, total_changes, pipeworx:// citation URIs). This is rich additional context.

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

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

The description is a dense single paragraph that front-loads user intents and the core definition before detailing sources and fallbacks. It is fairly long but every clause adds value; there is no padding or redundant content.

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

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

The tool is complex (multiple data sources, fallbacks, date formats), and the description covers all essentials: source fan-out, fallback logic, `since` format, return shape, and the distinction from entity_profile. Since there is no output schema, the explicit description of the structured changes[] response is particularly valuable.

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 all 3 parameters, so baseline is 3. The description adds meaningful syntax for `since` (ISO date or relative shorthand with examples like '30d' and '3m'), which exceeds schema detail. However, `type` and `value` are already well-described in 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 opens with natural-language intents ('What's new with X', 'latest on Y') and then defines a 'change feed for a company in the last N days/weeks/months in ONE parallel call'. It explicitly distinguishes itself from sibling entity_profile by describing the alternative for static profiles.

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

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

The description clearly states when to use this tool (for change feeds, updates, news) and names the alternative: 'Use entity_profile instead when you want the static profile (filings + fundamentals + LEI + patents) regardless of window.' This gives explicit guidance and contrasts with a sibling.

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 idempotentHint=true and destructiveHint=false, but the description adds context beyond that: storage as a key-value pair scoped by identifier, persistent memory for authenticated users, and 24-hour retention for anonymous sessions. This enriches the agent's understanding of side effects and lifecycle.

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 main purpose, then provides usage context, storage behavior, and companion tool notes. It is slightly longer than the ideal 2-3 sentences but every sentence earns its place without redundancy.

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

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

For a simple key-value store tool with 2 parameters and no output schema, the description covers all essential aspects: purpose, usage triggers, storage scope, persistence duration, and related tools. No critical information is missing for an agent 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?

Schema description coverage is 100% (both key and value have clear descriptions), so the baseline is 3. The description adds minimal parameter-specific semantics beyond the schema, only referring to 'key-value pair' generically, which does not exceed what the schema already 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 function with a specific verb and resource: 'Save data the agent will need to reuse later.' It also differentiates from siblings by mentioning recall and forget ('Pair with recall to retrieve later, forget to delete'), and provides concrete examples like 'a resolved ticker, a target address, a user preference.'

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

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

The description explicitly tells when to use the tool: 'Use when you discover something worth carrying forward...' and provides alternatives: 'Pair with recall to retrieve later, forget to delete.' This gives clear guidance on when to choose this tool over its sibling tools.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: identifiers are source-labelled, unresolved identifiers are explicitly listed under 'unresolved' rather than omitted, and GLEIF/OpenFIGI enrichment degrades gracefully with EDGAR identifiers still returning. The mention of internal cascading lookups also helps the agent understand why the tool may behave like multiple calls.

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

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

The description is long but every sentence adds substantive value. It opens with realistic example queries that instantly convey usage, then systematically covers supported types, return identifiers, failure behavior, and performance characteristics. There is no redundancy or filler; the structure with SUPPORTED TYPES and explicit notes on degradation and source-labelling makes it dense yet easy to parse.

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

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

For a tool with no output schema, this description is exceptionally complete. It explains what identifiers are returned for each type, how they are labelled, how unresolved identifiers are handled, and what happens in partial failure scenarios. It also frames the tool as a multi-endpoint aggregator, giving the agent a mental model of the tool's behavior. Given the complexity of entity resolution, this level of detail is necessary and fully supplied.

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

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

While the input schema already documents both parameters with 100% coverage, the description enriches them with concrete examples and format details: for 'value' it specifies 'ticker (AAPL), CIK (0000320193), or name' and 'brand or generic name (e.g., ozempic, metformin)'. It also explains what each 'type' returns, providing semantic context beyond the bare enum. This helps the agent choose the correct input format even without inspecting the schema.

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

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

The description explicitly states the action ('resolve a user-spoken NAME to the canonical/official identifiers other tools require as input') and clearly distinguishes this tool as the ID-lookup prerequisite for other tools. It enumerates supported types (company, drug) and provides example queries that make the purpose unmistakable. This goes well beyond a generic statement and differentiates it from sibling tools by establishing that it converts names to 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 gives explicit usage guidance: 'Use FIRST whenever you have a name but need an ID.' It also notes that using resolve_entity replaces 2-3 manual lookups, implying it is the efficient first step. It does not explicitly state when NOT to use it (e.g., when the ID is already known), but the positive guidance is strong and the context is clear.

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

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

The description adds substantial behavioral detail beyond the annotations: it states that it 'Probes each entity... with ai_visibility_check, ranks by score, surfaces which is most/least recognized' and describes the output as a 'ranked list with score, confidence, signal density per entity.' This gives the agent a clear model of the tool's execution and output without contradicting the readOnlyHint or other annotations.

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

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

The description is three sentences, front-loaded with the core purpose, then process, then use case and output. Every sentence earns its place: action, execution details, and value/result. There is no fluff or 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 moderate complexity, the description is fully self-sufficient. It covers what the tool does (side-by-side comparison), how it works (probes via ai_visibility_check), why you'd use it (competitive audits), and what it returns (ranked list with score, confidence, signal density). No output schema exists, but the description adequately fills that gap.

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 with detailed descriptions for every parameter (entities, models, _apiKey, context), so the baseline is 3. The description does not add parameter-specific semantics beyond what the schema already provides; it only mentions the general process of probing entities, which is not additional parameter 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 verb and resource: 'Compare AI visibility across multiple entities side-by-side.' It distinguishes from the sibling tool ai_visibility_check by focusing on multi-entity comparison and explicitly mentions it probes each entity with ai_visibility_check, establishing a clear relationship and differentiation.

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 a specific use case ('competitive AI-marketing audits') and an example question ('does Claude know about us as well as our competitors?'), which clearly situates when to use it. However, it does not explicitly mention alternatives or exclusions, like when to use compare_entities instead, so it lacks the full explicitness of a 5.

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

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

The description goes beyond the annotations by disclosing important behavioral traits: it fans out across multiple services, partial failures degrade gracefully, bundlephobia's first measurement can take 5-30 seconds, and the `sources_failed` field lists timeouts. This adds valuable operational context not captured in 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 well-structured and front-loaded, with each sentence providing unique information: overview, use case, output fields, ecosystem scope, and failure behavior. It is concise enough given the tool's complexity, with no filler or redundancy.

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

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

The description is complete for a composite tool with no output schema. It lists all return fields (summary block, per-advisory detail, links, alternative versions), explains limitations (NPM-only in v1), and details error handling. An agent would have sufficient context to invoke the tool and interpret results.

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

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

The input schema already has 100% coverage with descriptions for both `package` and `version`. The description mentions example values ('lodash', '18.3.1') and notes the default behavior of version, but adds no new semantic meaning beyond what the schema provides. Thus, 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 clearly defines the tool's purpose: a composite check for deciding whether to add an npm package, covering license, advisories, version history, bundle size, and more. It uses specific verbs and resources ('fans out across deps.dev and bundlephobia') and distinguishes itself from any existing sibling tools by its unique 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?

The description explicitly states when to use the tool: 'Use whenever an agent asks "is X safe / popular / small" or "what does adding lodash cost me".' It also provides an alternative for non-npm ecosystems ('PyPI / Maven / Cargo / Go fall under deps.dev:version directly'), giving clear guidance on tool selection.

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

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, but the description adds substantial behavioral detail beyond annotations: exact embedding model (BGE-base-en), similarity metric (cosine), chunking strategy (500-char overlapping windows), character cap (200K with truncation and flagging), and that every passage carries offset and score. 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 dense but every sentence earns its place: purpose, usage trigger, output details, pairing with another tool, and technical parameters. It front-loads the core function and then expands efficiently. No fluff or repetition of schema content.

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

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

Given the tool's complexity (3 params, no output schema, many sibling tools), the description covers everything an agent needs: inputs, outputs, return values, size limits, technical behavior, and usage context. It fully compensates for the absence of an output schema by specifying the result shape (passages with offsets and scores).

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

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

Schema coverage is 100%, so the baseline is 3. The description does not add significant new semantics beyond the schema's own parameter descriptions; it mentions 'text you already pulled' and gives query examples, but these are illustrative rather than essential. The cap/truncation behavior is more behavioral transparency than parameter semantics, so a 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 does semantic search inside a fetched record, returning top-N passages with offsets and similarity scores. It distinguishes itself from siblings by explicitly focusing on searching within already-pulled text, and pairs with ask_pipeworx_grounded for grounding. The verb 'search' plus the resource and output specifics make the purpose unmistakable.

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

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

The description gives concrete when-to-use guidance: 'Use when the record is too big to cram into the prompt' and explains the benefit of saving context. It also names an alternative/complementary tool (ask_pipeworx_grounded) and how the two fit together, making the selection criteria explicit.

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 the tool is a write operation (readOnlyHint=false) and open world, but the description adds critical behavioral details not covered by annotations: OAuth account requirement, phone verification for SMS, 10/day SMS cap, and webhook auto-disable after 10 consecutive failures. No contradiction exists between the description and annotations.

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

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

The description is a single dense paragraph of about 150 words, but every sentence serves a purpose—covering the main action, prerequisites, types, and delivery channels. While bullet points could improve scannability, the information is efficiently packed without redundancy or 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 complexity (5 subscription types, 3 delivery channels, no output schema), the description sufficiently explains the return value (subscription id), prerequisites, and per-channel behavior. It also mentions the always-on feed for pulling alerts. It does not cover every edge case, but it provides enough context for successful invocation without need to consult sibling 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?

The schema provides 100% coverage with detailed descriptions of all parameters, so the baseline is 3. However, the tool description adds meaningful interpretation beyond the schema, such as clarifying that items:["5.02"] means an officer change, and emphasizing the phone verification requirement for SMS delivery. This enriches the schema's raw definitions.

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

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

The description clearly states the tool's function: 'Create a proactive monitoring subscription to a live-data event stream.' It uses a specific verb and resource, and distinguishes itself from sibling tools like list_subscriptions and unsubscribe by focusing on creation. The inclusion of supported subscription types and delivery channels further reinforces its unique role.

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

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

The description provides clear context for when to use the tool, including a prerequisite (requires a Pipeworx OAuth account; anonymous/BYO cannot persist subscriptions) and an alternative to pulling alerts ('feed (always on — pull via recent_alerts or GET registry.pipeworx.io/alerts.json)'). However, it does not explicitly state 'use this instead of X' for all alternatives, though the context is sufficient.

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 readOnlyHint and idempotentHint annotations, the description discloses that the output is category-bucketed example questions with exact tool and argument shape, drawn from the live catalog of thousands of tools. It also clarifies behavior with and without the topic parameter, adding substantive behavioral context not present in annotations.

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

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

The description is longer than strictly necessary but every sentence contributes value: context, return format, usage modes, and meta-tool guidance. It is front-loaded with example queries, making it easy to grasp quickly. Slightly verbose but not bloated, earning a 4.

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

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

With no output schema, the description must explain what the tool returns and how to use it effectively. It does so thoroughly: return format (category-bucketed example questions with exact tool + argument shape), the two invocation modes, and the meta-tool learning purpose. This is complete for an onboarding 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 input schema already provides a complete description of the optional 'topic' parameter, listing all nine valid values and guidance to omit for a cross-category spread. The description adds a few extra examples (e.g., 'betting') but does not introduce meaning beyond the schema. With 100% schema coverage, 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 is the onboarding entry point for an AI agent, returning category-bucketed example questions with exact tool and argument shapes. It distinguishes from sibling tools by explicitly positioning itself as the 'FIRST' tool to use when unfamiliar with Pipeworx, and by referencing meta-tools like ask_pipeworx and entity_profile.

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

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

Usage guidance is explicit: 'Use this FIRST when you do not yet know what Pipeworx can do for you, or to learn how to call the meta-tools.' It also explains the two calling modes (no arguments for full spread, topic for focused) and lists example topics. This provides clear when-to-use and how-to-use context.

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

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

The description goes beyond annotations by disclosing ownership enforcement and the deactivation (rather than deletion) behavior. It explains that historical events remain available via recent_alerts, which adds meaningful context not covered by the annotations.

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

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

The description is two sentences, front-loaded with the primary action, and every clause adds useful information without redundancy. It is appropriately concise for a simple tool.

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

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

For a single-parameter, non-destructive subscription cancellation tool, the description is complete. It covers the action, ownership, deactivation semantics, and the availability of historical events via a sibling tool, leaving no significant 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% and the schema describes the id as a subscription uuid. The description adds value by clarifying that the id must be an owned subscription, which is a parameter-specific constraint not present in the schema.

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

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

The description clearly states the action: 'Cancel a subscription by id.' It distinguishes from subscribe by being the inverse operation, and adds specifics about ownership and deactivation behavior, making the purpose unambiguous.

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

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

It explicitly states that only your own subscriptions can be cancelled, which is a clear usage constraint. It also references recent_alerts as an alternative for viewing historical events, providing cross-tool guidance.

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

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

Annotations already indicate read-only, idempotent, open-world, and non-destructive. The description adds critical behavioral context: the two processing paths (SEC EDGAR fast path vs grounded pipeline), the semantics of each verdict, and especially the distinction between could_not_verify (with verification_error) and unsupported, ensuring callers don't misinterpret failures as evidence.

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

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

The description is appropriately sized for a complex tool, front-loaded with triggers and purpose, and every sentence adds unique value (paths, verdicts, failure modes, composite nature).

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

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

Given the tool's complexity and lack of output schema, the description fully explains return values, verdicts, failure semantics, and scope. It is complete for an agent to invoke correctly.

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

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

Schema covers both parameters fully (100% coverage). The description adds no additional parameter-specific details beyond mentioning exact percent-delta math, 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 defines the tool as natural-language claim verification against authoritative sources, with specific trigger phrases and a distinct scope (company-financial vs other claims). It differentiates itself as a composite replacing multiple sequential calls, making its purpose unmistakable.

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

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

It explicitly states 'Use whenever the agent needs to check whether something a user said is factually correct' and provides trigger phrases. It distinguishes two sub-paths but does not name sibling alternatives or exclusions, so it's clear but not fully explicit about when-not.

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