Connecticut DMV

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

Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, and no destructiveness. The description adds behavioral detail: the return format (per-model score, confidence, signals, raw_response), the fact that Workers AI is free, and that the API key is passed directly to Anthropic (privacy). This provides useful context beyond annotations.

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

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

The description is three sentences with no fluff. It front-loads the core purpose ('Probe one or more LLMs...score visibility') and efficiently covers details like defaults and return format. Every sentence serves a purpose.

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

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

Despite lacking an output schema, the description explains the return structure (per-model and combined view). Given 4 parameters (all described), no nested objects, and reasonable complexity, the description covers input, output, and use cases sufficiently. It could be slightly richer on edge cases (e.g., what if model is unsupported), but overall it is complete.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters clearly. The description adds little beyond the schema—it mentions the default model and the API key purpose, but these are already in the schema descriptions. Baseline 3 is appropriate as the description does not significantly augment 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 uses a specific verb ('probe', 'score') and resource ('LLMs', 'visibility'), clearly stating it scores visibility (0-100) per model for a given entity. It also contextualizes the use case ('AI-marketing audits', 'pre-launch brand checks', 'competitive monitoring'), effectively distinguishing it from sibling tools like scan_competitor_ai_presence or compare_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?

The description mentions default model (Workers AI) and optional Anthropic with BYO key, giving practical usage context. It identifies relevant applications (audits, brand checks, monitoring) but does not explicitly state when not to use the tool or compare with siblings, leaving some gap in exclusion guidance.

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

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

With annotations already declaring readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, the description adds meaningful behavior context: it fills arguments automatically, returns stable pipeworx:// citation URIs, works on every tier, and is a single fast call. It also implies a trade-off by pointing to ask_pipeworx_grounded for hallucination-resistant answers, which informs the agent of this tool's likely limitations.

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 priority instruction and is composed of several sentences that each carry useful information. While longer than a minimal description, the length is justified by the tool's broad scope. It is structured logically from preference to examples to alternatives, with no wasted words.

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

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

Given the tool's complexity (5,566 underlying tools) and lack of output schema, the description is remarkably complete. It specifies the return format (structured answer with citation URIs), covers the full range of supported topics, provides concrete examples, names alternatives for different use cases, and indicates performance characteristics ('one fast call', 'works on every tier').

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 the question parameter and its aliases with 100% coverage, establishing a baseline of 3. The description adds value through contextual examples ('current US unemployment rate', 'Apple's latest 10-K') and by clarifying that the question is routed to the appropriate underlying tools, which helps an agent understand what kind of input is expected beyond the schema's dry definition.

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 the tool's purpose as a general-purpose question answering over authoritative structured data, routing to 5,566 tools across 1,462 sources and returning structured answers with stable citation URIs. It explicitly distinguishes from siblings by naming ask_pipeworx_grounded and deep_research as alternatives for different needs.

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

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

The description gives explicit when-to-use guidance: 'PREFER OVER WEB SEARCH' and 'START HERE for most questions', along with a list of triggers ('what is', 'look up', 'find', etc.) and exact alternatives with conditions (hallucination-resistant -> ask_pipeworx_grounded; broad/multi-part -> deep_research). It also clarifies edge cases like breaking news.

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 safety hints, and the description adds valuable dynamic context: no candidate routing is currently active, the tool currently matches ask_pipeworx exactly, and it does not fall back to a safer stub—it is a full working router. No contradiction with annotations exists.

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

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

The description is front-loaded with the core beta identity and each sentence adds useful context about current state and usage. It is slightly verbose, repeating the ask_pipeworx relationship and response shape multiple times, but the structure remains logical.

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

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

For a natural-language routing tool with strong annotations and full schema coverage, the description explains the experimental nature, current state, and lack of fallback behavior. It relies on the sibling tool ask_pipeworx for some completeness, and only says the response shape is the same instead of describing the response format, but this is acceptable.

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

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

Schema description coverage is 100%, and the schema already documents the question parameter and its aliases clearly. The description only repeats that arguments are the same as ask_pipeworx, which does not materially deepen 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 the tool as a beta universal router with the same 5,566 tools, arguments, and response shape as ask_pipeworx. It distinguishes the tool as the experimental routing edge, though it relies somewhat on prior knowledge of ask_pipeworx rather than using a direct verb like 'ask'.

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 says to use it exactly like ask_pipeworx when you want the newest routing and explains that results are compared against the stable router to decide merges. It provides clear usage context but does not explicitly state when not to use it or name alternatives like 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 are already strong (readOnly, openWorld, idempotent, non-destructive), but description adds substantial behavioral context: refusal_reason enum values, success shape with evidence quote, and the 'ONLY what the tool result contains' extraction policy. This exceeds annotation coverage without contradiction.

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

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

Every sentence delivers high-value information: function, routing behavior, output structure, refusal reasons, usage context, and cost trade-off. Despite being longer than average, it is dense and well-structured 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?

This is a complex tool with 5,566 backing tools, routing logic, and a rich response contract. The description covers the full decision context: when to use, what the answer looks like, what refusal reasons exist, and cost implications. With no output schema, it fully compensates by describing return values.

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

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

Schema coverage is 100% (all 6 parameters are aliases for question, each described). The description adds no new parameter-level semantics but also doesn't need to. Baseline 3 is appropriate since schema handles the heavy lifting.

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

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

The description clearly states the tool's function: a hallucination-resistant answer mode that extracts answers solely from tool results. It explicitly differentiates from ask_pipeworx by emphasizing groundedness and the structured success/refusal response format, making its 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?

Provides explicit when-to-use guidance: 'Use whenever an answer will be quoted, cited, or acted on, and the agent must not invent facts' (e.g., financial, legal, medical). Also explicitly contrasts with ask_pipeworx, stating it costs an extra LLM call and should be preferred for casual lookups, giving agents a clear decision rule.

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

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

Discloses many behavioral traits beyond annotations: fan-out to category-specific data packs, market resolution, classifier usage, response shapes (market, analysis, evidence), resolver contract, parent event extraction, news fallback handling, safety short-circuits for low-confidence/closed/illiquid markets, and resolution-rule risk. No contradiction with annotations; all safe, read-only behavior confirmed.

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?

Long but structured with clear section labels (CLASSIFIERS, FAN-OUT EXAMPLES, etc.). Every sentence adds value. Some redundancy could be trimmed, but overall concise for the complexity. Front-loaded with main purpose and usage.

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

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

For a complex tool with no output schema, the description is remarkably complete. Covers all important aspects: input formats, behavior, response shapes (including edge cases like low-confidence, closed markets, wide spreads), safety considerations, and resolution risk. Agent has sufficient information to use correctly.

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

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

Schema coverage is 100% with basic descriptions, but the description adds significant context: explains that 'market' can be slug, URL, or question text; 'depth' options 'quick' and 'thorough' with behavior; 'include_raw' trade-offs (response size, use cases). This exceeds schema info, warranting 4.

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

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

The description clearly states the tool researches a Polymarket bet by pulling Pipeworx data in one call. It specifies the resource (Polymarket bet), action (research), and scope. Examples of usage ('should I bet on X', 'what does the data say about Y') further clarify purpose. Distinguished from siblings by its specialized focus on betting edge.

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

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

Explicit use cases are given: 'should I bet on X', 'what does the data say about Y', 'is there edge in Z'. While it does not list specific sibling alternatives or when not to use, the examples and detailed description make intended usage clear. Missing explicit exclusions or comparisons to similar tools.

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

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

Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds valuable behavioral context: correct handling of off-calendar fiscal years, sorting by primary metric, and return of paired data with citation URIs. This goes beyond what annotations provide.

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

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

The description is front-loaded with trigger phrases and each sentence adds value. However, it is somewhat lengthy and could be slightly more concise without losing information.

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

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

Despite no output schema, the description explains the return format (paired data + URIs) and covers type-specific behavior, data sources, and efficiency gains (replacing 8-15 lookups).

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

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

With 100% schema coverage, baseline is 3. The description adds significant meaning: explains data sources for each type (SEC EDGAR/XBRL for company, FAERS for drug), clarifies parameter formats (tickers/CIKs vs names), and discusses limits and sorting behavior.

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

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

The description clearly states the tool's function: side-by-side comparison of 2-5 companies or drugs in one parallel call. It uses specific verbs like 'compare' and provides example queries, distinguishing it from sequential lookups (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?

Explicitly states to 'ALWAYS PREFER over sequential single-pack lookups' and provides example queries. The description gives clear context on when to use this tool vs alternatives, such as entity_profile.

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

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

Annotations already indicate the tool is read-only and non-destructive. The description adds valuable context about the data source (60,489 records, snapshot as of February 2025), ensuring the agent understands the temporal scope. No contradictions.

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

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

The description is concise, with no redundant information. It front-loads the main purpose and includes examples, data source context, and sibling distinction. A slight improvement could be clearer sentence breaks, but overall efficient.

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

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

For a read-only counting tool with no output schema, the description adequately covers purpose, parameters, data vintage, and alternatives. It could mention behavior for no results or empty filters, but not essential.

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

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

Schema description coverage is 100%, so baseline is 3. The description does not add significant new parameter semantics but provides context about the grouping dimension and example usage. It meets the minimum for a well-described 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 counts electric vehicles registered in Connecticut, broken down by various dimensions. It provides specific example questions and distinguishes from the sibling tool for California vehicles.

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

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

The description explicitly states when to use this tool (for Connecticut EV registrations) and when not to (for California or full fleet), naming the alternative tool ca_dmv_vehicle_registrations.

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

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

The description discloses account/tier requirements, output packet composition (verbatim evidence, confidence, source, fetched_at, citations), gaps[] behavior (never invented), contradictions[] for standard/thorough, semantic excerpting, citation resolvability, and latency expectations. This far exceeds the annotations' readOnly/openWorld/idempotent hints, and there is no contradiction.

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

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

The description is dense and front-loaded with the critical account requirement and fallback tool. Every sentence provides unique information, but the single-block structure is verbose, though justified by the tool's complexity. It is not minimal but earns its 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?

With no output schema, the description fully describes the return packet, gaps, contradictions, hop, citation_uri, and latency. It also covers account requirements, tier differences, alternative tool usage, and non-open-web scope, making it extremely complete for a tool of this 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?

Input schema already covers both parameters at 100%. The description adds behavioral meaning for depth values: 'standard' re-angles unanswered gaps, 'thorough' chases leads, and it clarifies multi-step resolution and timing per depth. This adds value beyond the schema's plain 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 provides a precise purpose: 'Grounded multi-source research across Pipeworx's 1462 STRUCTURED data sources' with explicit decomposition and parallel routing. It clearly distinguishes itself from siblings by stating 'this is NOT open-web search' and naming ask_pipeworx as an alternative.

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

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

The description gives explicit when/when-not guidance: 'If you are not signed in, use ask_pipeworx instead', 'For a single lookup use ask_pipeworx', and 'For BREAKING or colloquial CURRENT-NEWS ... prefer ask_pipeworx'. It also states 'Best for broad/multi-part questions over structured data', covering both usage and exclusions with named alternatives.

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

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

Annotations indicate read-only, idempotent, non-destructive. Description adds behavioral details: returns top-N tools with full schemas ready to call, no second lookup needed. No contradictions.

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

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

Description is well-structured, front-loaded with purpose and usage, then lists examples and return details. Slightly verbose but every sentence adds value.

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

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

Given multiple parameters, no output schema, and many sibling tools, description is highly complete: it explains purpose, when to use, what output contains, and that it's a first-step 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 covers all parameters (100% coverage) with descriptions. Description adds minimal extra detail beyond what schema provides, mainly restating aliases and limit behavior. Baseline 3 due to high schema coverage.

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

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

Description clearly states the tool finds tools by describing data or task, with explicit examples of domains. It distinguishes itself from siblings by advising to call it first when many tools are available.

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

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

Provides explicit when-to-use scenarios (browse, search, look up) and recommends calling it first. However, it does not explicitly state when not to use or list alternatives beyond the sibling context.

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

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

Annotations indicate read-only, open-world, idempotent, non-destructive. Description adds details: fans out across multiple sources, returns specific fields, notes patents API sunset and soft-fail, and unsupported name parameter. No contradiction.

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

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

Description is a single paragraph but includes numerous examples and details. While comprehensive, it could be more structured (e.g., bullet points) for quicker scanning.

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

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

No output schema, so description compensates by listing all returned fields (cik, company_name, recent_filings with URIs, fundamentals, patents with caveat, news, LEI). Covers fallbacks and caveats fully.

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 with descriptions (100% coverage). Description adds examples ('AAPL', '0000320193'), clarifies type is only 'company', and explains value format. Adds meaningful context beyond schema.

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

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

Description clearly states the tool returns a 'full cross-source profile of a US public company in ONE parallel call.' It enumerates data sources and returned fields, distinguishing it from siblings like compare_entities and resolve_entity.

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

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

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

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

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

Annotations already declare destructiveHint=true and idempotentHint=true. The description adds 'Delete' which is consistent, but does not disclose additional behavioral traits like permanence or side effects beyond what annotations provide.

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

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

Two concise sentences with no extraneous information. The core action is front-loaded, making it easy to parse.

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

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

For a simple tool with one parameter, no output schema, and clear annotations, the description covers purpose and usage adequately. No additional detail needed.

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

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

Schema coverage is 100% with the 'key' parameter described as 'Memory key to delete.' The description does not add meaning beyond the schema, resulting in a baseline score of 3.

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

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

The description clearly states the action: 'Delete a previously stored memory by key.' It uses a specific verb ('Delete') and resource ('memory'), and distinguishes from siblings like 'remember' and 'recall' by mentioning them.

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

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

Provides explicit when-to-use scenarios: 'when context is stale, the task is done, or you want to clear sensitive data.' Also instructs to pair with 'remember' and 'recall,' giving clear context and alternatives.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that it fetches the page, extracts title/description/key links, and emits standard markdown format, confirming read-only and idempotent behavior without 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 two sentences, front-loaded with purpose, and every sentence adds value. No wasted words.

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

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

Given the simplicity of the tool (2 params, no output schema) and full schema coverage with good annotations, the description is complete enough. It explains output format, use cases, and behavior adequately.

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

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

Schema coverage is 100% with both parameters documented. The description adds minimal new meaning beyond the schema (e.g., 'default 25, max 50' for max_links is already in schema). Baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: generating a production-ready llms.txt file for any URL to aid AI crawlers. It specifies the verb (generate), resource (llms.txt file), and outcome (site indexing), and distinguishes from siblings by mentioning specific use cases.

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 scenarios such as getting a client's site indexed, drafting for own project, or auditing a competitor. While it doesn't explicitly state when not to use, the context of sibling tools shows it's unique, and the description is clear enough for agent decision.

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

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

Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds value by listing the returned fields (id, type, params, etc.) and noting the default behavior (active only). No contradiction with annotations.

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

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

Two concise sentences with no unnecessary words. The most important information (what it does and returned fields) comes first, followed by usage guidance.

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

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

Given the tool's simplicity (one optional param, no output schema), the description fully covers purpose, usage, and return fields. It provides complete context for an agent to use the tool correctly.

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

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

The only parameter, include_inactive, is fully described in the schema with 100% coverage. The description mentions 'active' and 'id to cancel' but does not add meaning beyond the schema. Baseline score of 3 is appropriate.

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

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

The description explicitly states what the tool does: 'List the caller's active subscriptions.' It clearly identifies the verb (list) and resource (subscriptions). The tool name and title are directly reflected, and it distinguishes from siblings like subscribe and unsubscribe.

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

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

Provides explicit guidance: 'Use this to review what you're monitoring before adding more or to find an id to cancel.' This tells the agent when to use it (before subscribe/unsubscribe) and what to get (id for cancellation).

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

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

With all annotation hints false, the description carries the full behavioral burden. It discloses rate limiting ("Rate-limited to 5 per identifier per day"), the claim_token flow ("Filing without an account returns a `claim_token`; pass it back later..."), and notes that the tool does not count against quota. It also explains what happens to feedback and how it is used by the team. 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 well-organized, front-loading the core purpose and then systematically covering use cases, exclusions, the claim_token mechanism, rate limits, and quota impact. Every sentence adds essential information, and the length is justified by the tool's multi-mode behavior and claim workflow. 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?

Given the tool's complexity (4 params, nested context object, claim_token flow, rate limiting) and the absence of an output schema, the description is remarkably complete. It explains return behavior (claim_token, later status), quota implications, and the exact scenario boundaries. An agent has enough information to use the tool correctly and know what to expect.

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

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

Although schema coverage is 100%, the description adds crucial usage nuances beyond the schema: it instructs users to "Describe the issue in terms of Pipeworx tools/packs — don't paste the end-user's prompt," which clarifies the message parameter's intended content. It also explains the interdependent workflow for claim_token, which is not fully captured by the schema alone. This adds real semantic 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?

The description opens with a specific verb+resource: "Tell the Pipeworx team something is broken, missing, or needs to exist." It clearly distinguishes from sibling tools by stating it's for reporting issues with Pipeworx tools only, and contrasts with other MCP servers. The purpose is unambiguous and well differentiated.

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: for bugs (wrong/stale data), feature requests, data gaps, and praise. It also provides clear exclusions: do not report issues from other MCP servers, and directs users to file those elsewhere. It even offers guidance for uncertainty ("Not sure? Pipeworx tool names are the ones this connection lists").

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

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

Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds value by revealing the data source (CF analytics), stating no PII is collected, and specifying caching behavior (5min-1h). This extends beyond the annotation 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 concise at three sentences, each earning its place. It front-loads the core purpose, then lists use cases, then adds technical caveats. No wasted words.

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

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

Given the simple single-parameter schema and the absence of an output schema, the description adequately covers what the tool returns (top tools, packs, call volume). It does not detail the output structure but the context signals indicate no nested objects, so it's sufficient.

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

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

The sole parameter 'window' is fully described in the schema with enum values and a description. The tool description adds context about the trade-off between short and long windows (hot vs. steady-state). This adds semantic value beyond the schema.

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

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

The description clearly states the tool's purpose: returning top tools, packs, and call volume over time windows. It uses a specific verb-noun structure and distinguishes itself from sibling tools like discover_tools and ask_pipeworx by focusing on trending/aggregate data.

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

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

The description explicitly lists three use cases (discovering hot data, confirming canonical tools, aligning use cases). While it doesn't explicitly state when not to use or name alternatives, the context is clear and practical for an AI agent to decide when to invoke 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 provide readOnlyHint, openWorldHint, etc. Description adds rich behavioral context: scanning scope (top 200 markets), similarity threshold (0.30 Jaccard), placeholder filtering, fill-check with depth (realizable vs theoretical edge), and conditions for not trading. No contradictions.

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

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

Description is long but well-organized, front-loaded with purpose and modes. Every sentence adds unique information (thresholds, fill-check, return fields). Minor verbosity in explaining fill details could be streamlined, but structure is logical.

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

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

Given the tool's complexity (multiple modes, arbitrage detection, fill-check, similarity filter, placeholder handling) and no output schema, the description is nearly comprehensive. Covers return format, edge cases, and enough for an agent to understand behavior and limitations.

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 with descriptions (100% coverage). Description adds significant value: explains mode behavior, gives concrete examples for event (slug/URL) and topic (seed question), and details what each mode does. Far exceeds baseline 3.

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

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

Clearly states the tool finds arbitrage opportunities via monotonicity violations and partition-sum checks. Describes three modes (no args, event, topic) with distinct behaviors. Implicitly distinguishes from sibling tools like polymarket_edges and polymarket_fill_risk by focusing on arbitrage detection.

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 recommends when to use each mode: event for a specific market, topic for cross-event scanning, and references polymarket_fill_risk for custom sizing. Provides concrete examples. Lacks explicit when-not-to-use guidance but covers key usage decisions.

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

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

Annotations declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds extensive behavioral details: caching at KV level for 1h, tradeable-edge knobs, per-leg Kelly handling, diagnostics for empty segments, and the exclusion of Fed bets due to unreliable data. 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 very long and includes highly technical details (e.g., sports-specific α values, funnel counters). While it is well-structured with bold labels and sectioning, it contains more detail than necessary for an agent to select and invoke the tool effectively.

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 clearly defines the response structure (by_segment, fed_candidates, _diagnostics) and explains all filters and knobs. It covers caching, edge cases (Fed bets, empty segments), and model assumptions comprehensively for such 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% for all 9 parameters, each with detailed descriptions. The tool description adds context about parameter interactions (e.g., why min_kelly uses half-Kelly) and overall filtering logic, which provides added meaning beyond the schema.

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

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

The description explicitly states the tool scans top Polymarket markets to find opportunities where Pipeworx data disagrees with market price, targeting 'what should I bet on today'. It distinguishes itself from siblings like polymarket_arbitrage by focusing on Pipeworx-derived edges and providing three distinct model families.

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 usage context (daily bet research) and details knobs like min_liquidity and max_spread_pp for filtering tradeable edges. It notes caching, Fed bets exclusion, and diagnostics for empty segments. However, it does not explicitly instruct when not to use this tool versus specific siblings.

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

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

The description adds significant behavioral detail beyond annotations: it explains the data source (daily snapshots), limits (60-day TTL, no intraday data), and response structure (tracked, expired, snapshot_dates with field meanings). No contradiction with annotations that indicate read-only, idempotent, non-destructive behavior.

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

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

The description is moderately long but well-structured, with clear sections for purpose, args, response, and limits. It is informative without being overly verbose, though some sentences could be shortened without losing meaning.

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

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

Given the lack of an output schema and the tool's complexity (time-series, decay analysis, multiple response arrays), the description thoroughly explains the response format, field meanings, and limitations. It enables an agent to understand and use the tool correctly.

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

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

Schema coverage is 100%, so the schema already documents both parameters. The description restates them with defaults and adds context (e.g., window as 'snapshot family' and days clamp), but this adds marginal value over the schema. Baseline 3 applies.

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

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

The title 'Edge Tracker' and description clearly state the tool's purpose: tracking edge persistence and decay telemetry from daily snapshots. It answers the specific question 'how long has this edge existed and is it shrinking?', distinguishing it from a simple edge list by focusing on time-series and decay.

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 usage context by contrasting fresh vs. old edges ('a fresh wide edge and a 3-week-old wide edge are different trades'), implying when to use the tool. However, it does not explicitly state when not to use it or mention alternative tools like 'polymarket_edges' or other 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?

Annotations already mark the tool as read-only, idempotent, and non-destructive. The description goes beyond by detailing the check process (walks the ladder, returns top-of-book, VWAP, slippage, verdict) and warning about partial basket fills converting arbitrage into directional risk. This adds significant value 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 well-structured with sections (REQUIRES, SINGLE-MARKET, BASKET, USE THIS). Every sentence provides useful information without redundancy. Slightly verbose but not excessive given the complexity.

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

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

Given the complexity (two modes, multiple return values, edge-case warnings), the description thoroughly covers all aspects. It lists all return fields (top_of_book, vwap_fill_price, slippage_pp, etc.) and explains the meaning of each. No output schema exists, so the description fully compensates.

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?

Input schema has 100% description coverage. The description adds value by explaining default values, the distinction between USD spend vs target proceeds for single-market, and the interpretation of size_usd as settlement notional for baskets. It also clarifies default behavior for side in basket mode.

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: 'Realizable-vs-theoretical edge check against live CLOB order-book depth.' It distinguishes between single-market and basket modes, and explicitly differentiates from sibling tools by stating when to use this tool over polymarket_arbitrage or polymarket_edges.

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

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

The description provides explicit guidance on when to use the tool: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500.' It also explains the two modes (single-market vs basket) and required parameters, making it clear when each applies.

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. The description adds substantial behavioral context: it explains how compatibility_warning flags non-equivalent bet shapes, temporal alignment checks, and skipped cross-type/subtype counters. This fully discloses the tool's behavior 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 well-structured with clear sections for modes, response format, and safety fields. The core purpose is front-loaded. Every sentence adds unique value, explaining functionality, edge cases, and limitations without redundancy.

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

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

Given no output schema, the description thoroughly explains the response structure: leg prices, spreads, compatibility warnings, temporal alignment, and counters. It covers error cases and semantic mismatches, making the tool fully understandable without additional documentation.

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

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

The input schema covers 100% of parameters with descriptions, but the description adds rich context: it lists all 10 topic keywords, explains the override behavior for explicit tickers, and clarifies the relationship between parameters. It goes beyond the schema to ensure correct parameter selection.

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

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

The description clearly states the tool computes cross-venue spreads between Kalshi and Polymarket for identical resolving questions. It distinguishes from sibling tools like 'polymarket_arbitrage' by focusing on cross-venue comparison, and it specifies the two operational modes. The first sentence summarizes the core function.

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 describes two modes (topic shortcuts and explicit tickers) and explains when each is appropriate. It warns that most pre-mapped topics may not yield tradeable spreads, guiding the agent away from false expectations. It also details the compatibility_warning conditions, helping decide when the output is meaningful.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, establishing the tool as safe and idempotent. The description adds value by explaining the dual behavior (retrieve by key or list all when key is omitted) and the scoping mechanism. While it doesn't contradict annotations, it could provide more detail about error cases or return format.

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

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

The description is concise at three sentences. It is front-loaded with the primary action and efficiently covers purpose, usage, and scoping without unnecessary words. Every sentence contributes meaningful information.

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

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

For a simple tool with one optional parameter and no output schema, the description is largely complete. It explains the two modes (retrieve/list), scoping, and typical use cases. However, it does not explicitly state that the return value is the saved value or a list of keys, nor does it mention error behavior (e.g., key not found). Given the simplicity, this 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?

Schema coverage is 100% and the schema description for 'key' already explains its behavior ('omit to list all keys'). The description adds semantic context by providing examples of keys ('user's target ticker, an address, prior research notes'), which helps the agent understand what kind of data is retrievable. This goes beyond the schema's structural definition.

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: 'Retrieve a value previously saved via remember, or list all saved keys (omit the key argument).' It uses specific verbs (retrieve/list) and identifies the resource (saved memory values). It also distinguishes itself from sibling tools like 'remember' and 'forget' by naming them explicitly.

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 excellent usage guidance. It tells the agent when to use this tool: 'to look up context the agent stored earlier — the user's target ticker, an address, prior research notes — without re-deriving it from scratch.' It also mentions scoping ('anonymous IP, BYO key hash, or account ID') and explicitly pairs it with 'remember' and 'forget' for a complete workflow.

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 and idempotentHint, but the description adds valuable context about the mark_read side effect (flagging events as read) and the alternative access via GET endpoint. It also mentions that polls work fine, which is not captured by 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 four sentences, each contributing unique information. It starts with the core purpose, then details return fields, filtering, and finally alternative access. No fluff or repetition.

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

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

Despite lacking an output schema, the description covers all parameters, return fields (source, citation_uri, payload), and behavioral notes (polling, read marking). It is complete for a tool of moderate complexity with no nested objects.

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

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

With 100% schema coverage, the baseline is 3. The description adds concrete examples like 'sec_8k' for type and explains the effect of mark_read=true, enhancing understanding beyond the schema's parameter descriptions.

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

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

The description clearly states it pulls fired events from a subscription feed, listing return fields and filtering options. While it doesn't explicitly differentiate from sibling tools like list_subscriptions, the specific mention of alert payloads and mark_read behavior makes the purpose distinct enough.

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

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

The description explains when to use filtering parameters and suggests polling works fine, but it does not provide guidance on when to avoid this tool or compare it to alternatives such as list_subscriptions or the direct endpoint. The usage context is clear but lacks exclusion 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?

The description details the fan-out to multiple sources, fallback mechanism, and return structure, adding significant context beyond the annotations which already mark it as read-only and idempotent.

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 examples and guidance, though slightly long; every sentence is valuable, but could be tightened slightly.

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

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

Covers purpose, usage, behavior, parameters, and return structure despite no output schema; explains fallback logic and soft-fail, and references sibling tool.

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

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

Schema coverage is 100%, but the description adds extra context for 'since' (format and typical usage), 'value' (ticker or CIK), and 'type' (only company supported).

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

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

The description clearly states the tool provides a change feed for a company, with example queries. It distinguishes from the sibling tool entity_profile, which is 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?

Explicit guidance on when to use (what's new queries) and when not to (static profile needs), with a direct reference to entity_profile as the alternative.

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 idempotentHint=true and non-destructive, but description adds key behavioral details: scoped by identifier, persistence differences for authenticated vs anonymous users, and 24-hour retention for anonymous sessions. No contradiction.

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

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

Four well-structured sentences conveying purpose, usage, storage behavior, and pairing with sibling tools. No redundant or extraneous 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?

Covers purpose, usage, and behavior sufficiently. No output schema, but the tool is straightforward; description does not need to detail return values. Lacks mention of edge cases like overwriting existing keys, but overall complete.

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

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

Schema coverage is 100% with clear descriptions for both parameters. The description adds example values but no additional semantic meaning beyond what the schema provides.

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

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

The description clearly states what the tool does ('Save data the agent will need to reuse later'), uses specific verbs and resources, and distinguishes from sibling tools like recall and forget by mentioning them.

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

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

Explicitly states when to use the tool ('when you discover something worth carrying forward') and provides alternatives by pairing with recall and forget. Also contrasts with anonymous and authenticated users.

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 reveals important behavioral traits: it internally cascades through multiple lookup endpoints, degrades gracefully when LEI/FIGI sources are unavailable (falling back to EDGAR identifiers), and explicitly reports unresolved identifiers under 'unresolved' rather than omitting them. This provides valuable context about failure modes and output behavior.

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

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

The description is front-loaded with example queries and gets to the core purpose immediately. It is relatively long but each clause adds essential information about supported types, sources, and fallback behavior. The structure is organized but could be tightened by splitting into shorter paragraphs or bullet points for easier scanning.

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

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

Given the tool's complexity (multiple entity types, multiple data sources, cascading lookups) and the absence of an output schema, the description is remarkably complete. It covers input formats, resolution logic, source attribution, fallback behavior, and the explicit handling of unresolved identifiers. This leaves little ambiguity about what the tool does and what it returns.

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, but the description adds substantial semantic value beyond the schema. It explains the meaning of 'type' values (company vs. drug), provides examples for 'value' (ticker, CIK, ISIN, name, brand/generic), and explains the ISIN-to-LEI resolution process. This is richer than a baseline 3, though not exhaustive enough to warrant a 5.

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

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

The description clearly states the tool resolves user-spoken names to canonical/official identifiers, with a specific verb ('resolve') and resource (identifiers). It distinguishes itself from siblings by explicitly saying 'Use FIRST whenever you have a name but need an ID' and provides concrete example queries, 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?

The description provides explicit 'when to use' guidance ('Use FIRST whenever you have a name but need an ID') and clarifies that it replaces multiple manual lookups. However, it does not explicitly state when not to use the tool or name alternative tools for cases where an ID is already known, so it falls short of a 5.

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

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

Beyond annotations (readOnly, idempotent, non-destructive), description details that it probes each entity with 'ai_visibility_check', ranks by score, and surfaces most/least recognized. No contradictions.

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

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

Two sentences, front-loaded with purpose, no unnecessary words. Efficiently conveys core behavior.

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

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

No output schema, but description explains returns ranked list with score, confidence, signal density. Parameters fully covered, and internal behavior (probing with ai_visibility_check) disclosed, making it complete for decision-making.

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%, baseline 3. Description adds meaning by stating first entity is treated as 'subject' and that context disambiguates common names, adding value beyond schema.

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

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

Description clearly states 'Compare AI visibility across multiple entities side-by-side', specifying verb and resource. Distinguishes from sibling 'ai_visibility_check' which checks a single entity.

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 usefulness for 'competitive AI-marketing audits' with an example query. Provides context for use but does not explicitly mention when not to use or alternatives beyond implied difference from single-entity check.

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

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

Annotations declare read-only and non-destructive. The description adds behavioral details: fans out to two services, bundlephobia first measurement can take 5-30s, and partial failures degrade gracefully with sources_failed listed. 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 information-dense but well-structured: overview, usage, output, ecosystem scope, error handling. Every sentence adds value with no repetition 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?

No output schema, but the description fully lists return fields, including per-advisory detail, links, and alternative versions. Also covers error handling and timeout behavior, making it complete for a multi-service tool.

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

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

Schema coverage is 100%, baseline 3. The description adds that scoped packages (like @types/node) are accepted for the 'package' parameter, and version defaults to latest when omitted. This clarifies usage beyond the schema.

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

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

The description clearly identifies the tool as a 'composite check' for npm packages, specifying it queries deps.dev and bundlephobia for license, advisories, bundle size, etc. It distinguishes itself from other tools (deps.dev:version) by stating NPM-only in v1.

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

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

Explicitly instructs when to use: when an agent asks 'is X safe/popular/small' or 'what does adding lodash cost me'. Also clarifies non-npm ecosystems are handled elsewhere and mentions graceful degradation on partial failures.

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

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

Annotations indicate read-only and idempotent behavior; the description adds detailed behavioral traits: BGE-base-en embeddings, cosine similarity over 500-char overlapping windows, and a 200K char cap with truncation flagging. No contradictions.

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

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

Description is extremely concise: a clear first sentence stating the purpose, followed by a use case, benefits, and technical details. Every sentence adds value with no redundancy.

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

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

Despite lacking an output schema, the description fully explains the return format (top-N passages with character offsets and similarity scores), the embedding method, windowing strategy, and input limitations. Complete for a tool of this 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 descriptions; the description adds meaningful context to the 'text' parameter (max ~200K chars) and provides natural-language examples for the 'query' parameter (e.g., 'supply-chain risk'), enhancing understanding beyond the schema.

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

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

The description clearly states it performs semantic search inside a fetched record, specifies the use case (when a record is too large for the prompt), and distinguishes itself by mentioning character offsets and pairing with a sibling tool (ask_pipeworx_grounded).

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 when the record is too big to cram into the prompt') and provides an alternative workflow ('Pairs 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=false, destructiveHint=false, idempotentHint=true, openWorldHint=true) are not contradicted. Description adds valuable context: OAuth requirement, delivery limitations, webhook signing secret returned once, auto-disable after 10 failures. This is beyond what annotations provide.

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

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

Description is fairly long but well-structured: front-loaded with purpose and then details. Every sentence adds value, though some detail (e.g., exact webhook signature formula) could be in a separate doc. Still effective and not overly verbose given complexity.

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

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

Given the tool's complexity (multiple subscription types, delivery channels, authentication requirements), the description covers usage, constraints, and return value. No output schema exists, but the description notes 'Returns the new subscription id'. Complete 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?

Schema coverage is 100%, but description adds significant meaning: explains each subscription type's parameters with examples (e.g., sec_8k with items codes, polymarket_edge with topic and min_spread_bps), delivery channel specifics (e.g., webhook JSON body HMAC signing). This goes well beyond schema descriptions.

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

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

The description clearly states the tool creates a proactive monitoring subscription, returns the new subscription ID, and lists supported types and delivery channels. It differentiates from siblings like unsubscribe and list_subscriptions.

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

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

Provides explicit context: requires a Pipeworx OAuth account (anonymous/BYO cannot persist), supported subscription types with detailed parameters, delivery channel options and constraints (e.g., SMS must be verified, 10/day cap). No alternatives explicitly named but context is comprehensive.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds behavioral context about returning structured example questions with tool+argument shapes, complementing annotations.

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

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

The description is front-loaded with example queries and structured as a coherent paragraph. Somewhat lengthy but every sentence contributes substantial information. Minor verbosity could be trimmed.

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

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

Given no output schema, the description fully explains the return format (category-bucketed examples with tool+argument shapes). It covers the tool's input, behavior, and purpose comprehensively.

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%, but the description adds significant value by listing exact allowed values for the topic parameter (finance, pharma, etc.) and explaining the effect of omitting vs. specifying it.

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

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

The description clearly states the tool's purpose as an onboarding entry point, providing example questions and categories. It uses specific verbs like 'returns category-bucketed example questions' and distinguishes itself from siblings.

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 advises using this tool first when unsure of Pipeworx's capabilities, and provides guidance on when to use the topic parameter. Also mentions learning how to call meta-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?

Beyond annotations (mutation, not destructive), description adds that the row is deactivated rather than deleted, keeping historical events available via recent_alerts, and enforces ownership.

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 focused sentences: first states purpose, second adds behavioral detail. No fluff, front-loaded, every sentence earns its place.

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

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

Covers cancellation, ownership, side effects (deactivation), and link to recent_alerts. Lacks output description but tool is simple; adequately complete given 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 already documents the single 'id' parameter with description (uuid from subscribe). Description adds ownership context but no additional parameter detail beyond schema.

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

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

Description states 'Cancel a subscription by id' with a specific verb and resource, and distinguishes from siblings like 'subscribe' (create) and 'list_subscriptions'.

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

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

Clearly states ownership enforcement ('only cancel your own subscriptions'), providing correct usage context, but does not explicitly mention when not to use or alternatives.

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

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

Beyond the annotations (readOnly, openWorld, idempotent), the description discloses substantial behavioral nuance: it explains the distinction between confirmed/refuted and inconclusive, explicitly warns that could_not_verify means the check did not happen and is not evidence, and details the fallback routing. This adds critical context about failure modes and verdict semantics that annotations alone do not 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 dense and front-loaded with user-phrase triggers, then quickly moves to the core use, behavior, return values, and edge-case warnings. Every sentence conveys essential information—no filler. Although lengthy, it earns its length given 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?

Given no output schema, the description provides a remarkably complete picture: it enumerates all possible verdicts, describes the actual value with citation and reasoning, defines the error object for could_not_verify, and explains the 'unsupported' outcome. It also positions the tool as a replacement for multi-step pipelines, making it clear when and how the tool behaves.

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 fully describes both parameters (claim and tolerance_pct) with examples and defaults (coverage 100%). The description reinforces that claims are natural-language and mentions percent-delta math and tolerance caps, but adds no new parameter-level meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

The description clearly identifies the tool as a natural-language claim verification tool with specific action verbs like 'verify', 'fact check', 'confirm or refute'. It distinguishes itself from likely siblings by explicitly stating it handles any factual claim and replaces 4–6 sequential calls, positioning it as the specialized claim-verification tool rather than a general research 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 gives an explicit when-to-use directive: 'Use whenever the agent needs to check whether something a user said is factually correct.' It also clarifies routing (company-financial vs any other claim) and warns about misinterpreting could_not_verify. However, it does not name alternative tools or state when not to use it, stopping short of the highest tier.

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