North Carolina DMV

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

Annotations already declare readOnly, idempotent, non-destructive. The description adds that it makes external API calls and that Anthropic calls incur cost paid directly to Anthropic, which is above and beyond annotations. It also describes the return structure.

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 with no fluff. It opens with the core action and return format, then covers model options, cost details, and use cases. Perfectly concise and well-structured.

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

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

Given no output schema, the description explains the return format well (per-model {score, confidence, signals, raw_response} + combined view). It covers parameters and use cases sufficiently, though details on 'signals' or 'confidence' are missing but not critical.

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

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

Schema coverage is 100%, so baseline is 3. The description adds context that Workers AI is free and Anthropic requires BYO key, which provides value beyond schema. However, the schema already describes parameter purposes sufficiently.

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 probes LLMs about a business/product/topic and scores visibility (0-100). The verb 'probe' and resource 'LLMs' are specific, and the tool is distinct from siblings like 'ask_pipeworx' or 'deep_research' which serve different purposes.

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 (AI-marketing audits, pre-launch brand checks, competitive monitoring) and provides details on default model vs. Anthropic (BYO key). However, it does not explicitly state when not to use or compare to alternatives, so it misses some guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds value by stating it routes to 5,305 tools, fills arguments, returns structured answers with pipeworx:// citation URIs, works on every tier, and is a single fast call. 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 front-loaded with the most important guidance, has clear sections, and uses examples. Though it is fairly long, every sentence adds value. Minor trimming possible but not necessary.

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

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

Despite no output schema, the description explains return format (structured answer with citations) and covers sources, alternatives, and use cases. It provides a complete picture for a complex tool with many sibling tools.

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

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

Schema coverage is 100% (6 parameters well-described with descriptions). The description adds 'natural language' and lists aliases, but the schema already handles parameter semantics. Baseline score 3 is appropriate.

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

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

The description opens with a strong directive to prefer this tool over web search for factual questions, then lists specific domains (SEC filings, FDA data, etc.). It clearly differentiates from siblings by naming ask_pipeworx_grounded and deep_research with usage conditions. The verb 'ask' plus resource 'Pipeworx' is specific.

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

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

Explicit when-to-use: 'PREFER OVER WEB SEARCH', 'START HERE for most questions'. Clear when-not: 'Step up only when needed'. Provides alternatives: ask_pipeworx_grounded for hallucination-resistant answers, deep_research for broad queries. Examples reinforce usage.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, indicating safe read-only behavior. The description adds behavioral context beyond annotations: it explains that this is a beta router with experimental routing improvements, currently identical to the stable version, and that it is a full working router. This provides the agent with a clear understanding of its experimental nature and current state.

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 relatively long but every sentence serves a purpose: it identifies the tool as a beta version, explains its identity with ask_pipeworx, notes the current state of no active candidate, and gives usage instructions. The information is front-loaded with the most critical details. A slight reduction could be made without losing meaning, but overall it is efficient.

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

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

Given the tool's complexity as a router with thousands of tools, and the availability of a rich input schema and annotations, the description sufficiently covers the purpose, current behavior, and usage context. It does not explain the internal routing improvement mechanism or how results are compared, but that is acceptable as it is internal. No output schema exists, but the description mentions the same response shape as ask_pipeworx, which is adequate.

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

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

Schema description coverage is 100%, with each parameter clearly documented. The description does not add any additional meaning to the parameters beyond what the schema already provides, as it only mentions that the tool uses the same arguments as ask_pipeworx. Therefore, the description meets the baseline expectation but does not exceed 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 it is a beta version of ask_pipeworx, an identical universal router with the same tools and arguments but with candidate routing improvements. It explicitly distinguishes itself from siblings by noting it is the experimental edge, and explains that currently it matches ask_pipeworx exactly because no candidate is active.

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 it exactly like ask_pipeworx when you want the newest routing'. It also implies that for stable routing one should use ask_pipeworx instead. However, it does not mention other alternatives or explicitly state when not to use it, leaving some room for interpretation.

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 internal process: routes to the right tool, fills arguments, fetches data, extracts answer using only tool result. Describes return format with evidence, confidence, and explicit refusal reasons. No contradiction with annotations (readOnlyHint, etc.).

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

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

Description is information-dense but slightly long (multiple sentences). Key phrase 'Hallucination-resistant answer mode' is front-loaded. Each sentence contributes value, but could be trimmed slightly without loss.

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

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

Given the complexity of the tool and absence of an output schema, the description thoroughly covers purpose, usage, behavioral details, return format, and refusal reasons. No gaps remain.

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

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

Schema coverage is 100% with descriptions for all parameters. The description does not add new semantic meaning beyond what the schema already provides; it merely reiterates the 'question' parameter and aliases.

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 explicitly states the tool's purpose: hallucination-resistant answer mode for high-stakes reads. It contrasts with sibling ask_pipeworx, specifying it costs one extra LLM call and is for when answers must be quoted or acted on.

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 clear when-to-use guidance: 'whenever an answer will be quoted, cited, or acted on, and the agent must not invent facts.' Lists specific domains (financial verdicts, legal claims, medical lookups, public statements) and advises to prefer ask_pipeworx for casual lookups.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds rich behavioral details: classification, fan-out logic, response shapes, resolver contract, parent event extraction, news fallbacks, safety low-confidence handling, closed market handling, liquidity warnings, and cancellation rule parsing. 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 long but well-structured, starting with the core purpose and then expanding into details. Every section (classifiers, fan-out examples, response shapes, safety, etc.) is justified. Some redundancy (e.g., repeating 'low_confidence_match' mechanism) could be trimmed, but overall it is efficient for the complexity.

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

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

For a complex tool with 3 parameters, no output schema, and many edge cases, the description covers all important aspects: behavioral traits (fan-out, classification), return structure (result.market, result.analysis, result.evidence), error/safety paths (low-confidence, closed markets, wide spreads), and resolution risk. It even gives concrete fan-out examples for multiple bet types, ensuring the agent can anticipate behavior in various scenarios.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning beyond schema by explaining the three input types for market (slug, URL, question text), the depth parameter's two settings (quick vs thorough with implications), and include_raw's default and use case. This adds clear value for agent 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 states the tool researches a Polymarket bet by pulling Pipeworx data in one call, with specific verbs like 'resolve', 'classify', 'fan out', and 'return'. It gives concrete use cases ('should I bet on X') and distinguishes from siblings by being a comprehensive research tool for Polymarket bets, not just edge detection or simple queries.

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 when to use the tool ('Use for ...') and provides multiple examples. However, it does not directly compare to sibling tools like polymarket_edges or validate_claim, leaving some implicit guidance. Despite this, the usage context is very clear and the extensive examples cover many scenarios.

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

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

The description adds behavioral context beyond annotations: off-calendar fiscal year handling, sorting by primary metric, and citation URIs. It does not contradict any annotation; all provided hints (readOnly, openWorld, idempotent) are consistent with the description.

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

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

The description is well-structured, front-loading example queries and the core purpose. While it is slightly lengthy due to detailed data source explanations, each sentence adds value. Could be tightened slightly without losing clarity.

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

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

Given the lack of output schema, the description covers input requirements, data sources, sorting, citations, and efficiency gains. It does not explicitly describe the output structure beyond 'paired data + citation URIs', which is a minor gap. Overall, it is fairly complete for a complex tool.

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

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

Schema coverage is 100%, and the description enriches both parameters: it explains the enum values for 'type' (company/drug) with data sources, and specifies the format and size constraints for 'values' (tickers/CIKs for company, drug names, min 2 max 5). This adds significant meaning beyond the schema.

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

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

The description clearly states the tool performs side-by-side comparisons of 2-5 companies or drugs, with specific data sources for each type. It distinguishes itself from sequential lookups and includes example queries, making its purpose unmistakable.

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

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

The description explicitly advises preferring this tool over sequential single-pack lookups and provides example queries that trigger it. It details when to use company vs drug type, but lacks explicit exclusion criteria for single-entity lookups or alternative tools like 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 declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint false. Description adds significant behavioral context: performance timings, depth level behaviors (gap recovery, contradictions), account plan requirement, citation format (pipeworx://), semantic excerpting of large records. 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?

Description is long but well-structured with key info front-loaded (account requirement, core functionality). Each sentence adds value, but some details (e.g., hop field, citation_uri) add verbosity. Could be slightly trimmed without losing clarity.

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

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

No output schema, so description explains return format: findings packet with evidence, confidence, source, fetched_at, citation, gaps[], contradictions[], hop field, citation_uri. Also mentions handling of large records (semantic excerpting). Lacks exact JSON structure, but given complexity, it's fairly 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 has 100% coverage but description adds meaning: depth enum values are explained with specific facet counts (quick=3, standard=5, thorough=8) and their behaviors (gap recovery, contradictions). Question parameter is clarified as natural language, broad/multi-part fine. Adds value beyond schema.

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

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

Clearly states it performs grounded multi-source research across 1391 structured data sources, decomposing questions into facets and routing to tools in parallel. Distinguishes from siblings like ask_pipeworx (single lookup) and specifies when not to use (breaking news). Verb+resource is specific and distinct.

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

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

Explicitly says when to use deep_research (broad/multi-part structured data questions) and when to use alternatives (ask_pipeworx for single lookup or breaking/news). Also notes account requirement and fallback tool if not signed in. Provides clear context with exclusions.

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

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

Annotations already declare readOnlyHint and idempotentHint. Description adds valuable behavioral context: returns top-N tools with full schemas and curated examples, and notes results are ready to call directly without second lookup.

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 concise yet informative, front-loaded with purpose, then listing domains, return details, and usage advice. Every sentence contributes meaning, though slightly verbose with the domain list.

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 what the tool returns (top-N tools with names, descriptions, schemas, examples). For a discovery tool with a simple input, this 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 coverage is 100% with all parameters described. Description adds value by listing aliases (task, q, description, search) and clarifying that query accepts natural language, going 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?

Description explicitly states 'Find tools by describing the data or task' and lists specific domains (SEC filings, FDA drugs, etc.), clearly distinguishing this from sibling tools that perform specific tasks rather than discovering 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 instructs 'Call this FIRST when you have many tools available and want to see the option set (not just one answer)', providing clear when-to-use guidance. Lacks explicit when-not-to-use or alternative tool names, but context is sufficient.

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

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

Annotations already indicate read-only, open-world, idempotent, non-destructive behavior. The description adds rich behavioral context: fans out across multiple sources, returns specific data fields, notes a patent API sunset with soft-fail, and describes fallback mechanisms. No contradiction with annotations.

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

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

The description is a single paragraph that is densely packed with information. It is structured with example queries first, then purpose, then detailed output. While efficient, it could be more concise by separating sections, but it earns its length due to high information density.

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

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

Given the tool's complexity (multiple data sources, fallbacks, limitations) and the absence of an output schema, the description provides a thorough overview of what the tool returns and its caveats. It covers inputs, outputs, limitations, and alternatives, making it complete for an agent.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by clarifying the expected formats (ticker or zero-padded CIK) and explicitly stating that names are not supported, which goes beyond the schema's enum and 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 uses specific verbs ('profile'), identifies the resource ('US public company'), and clearly distinguishes from siblings like 'resolve_entity'. It provides multiple example queries, making the tool's purpose unmistakable.

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

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

Explicitly states preference over chaining multiple single-purpose tools for holistic views, and clearly states when not to use ('names not supported — use resolve_entity first'). This provides excellent guidance on when and when not to use this tool.

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

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

Annotations already provide destructiveHint=true and idempotentHint=true. The description adds the context of deleting previously stored memories, which is consistent and slightly augments the annotations with the notion of prior storage.

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: first states core action, second provides usage context. No wasted words, front-loaded.

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

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

For a simple tool with one parameter, clear annotations, and no output schema, the description provides complete guidance on purpose and usage.

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

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

Schema coverage is 100% with a single parameter 'key' described as 'Memory key to delete'. The description does not add any further semantic value beyond what the schema provides.

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

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

The description clearly states the verb 'delete', the resource 'memory', and the method 'by key'. It distinguishes from siblings by mentioning pairing with 'remember' and 'recall'.

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

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

Explicitly states when to use: 'when context is stale, the task is done, or you want to clear sensitive data'. Also hints at alternatives by mentioning pairing with remember and recall.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. Description adds that it fetches the page, extracts info, and emits markdown, consistent with annotations. Could mention potential limitations like page size but overall strong.

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

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

Three sentences, front-loaded with purpose, concise process, and clear use cases. No wasted words.

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

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

No output schema, but description explains output format (standard llms.txt markdown, single text blob). Annotations cover safety. 2 parameters fully documented. Complete for a simple 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 both parameters with descriptions (100% coverage). Description adds an example for url and reinforces default/max for max_links, but no additional meaning 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 generates a production-ready llms.txt file for any URL, specifying the verb, resource, and outcome. It distinguishes from siblings like ai_visibility_check by focusing on file generation rather than visibility analysis.

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

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

Explicitly lists use cases (getting client's site indexed, drafting own project, auditing competitor) but does not mention when not to use or compare directly to sibling tools.

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

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

Annotations already declare readOnlyHint and idempotentHint; description adds value by detailing return fields and the optional parameter, with no contradictions.

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

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

Two sentences with zero waste, front-loaded purpose, and efficient structure.

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 complete, listing return fields and usage context.

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

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

Schema coverage is 100%, so description adds minimal meaning beyond the schema; baseline 3 is appropriate.

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

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

Description clearly states it lists the caller's active subscriptions and enumerates returned fields, differentiating it from siblings like subscribe/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?

Explicitly guides when to use: reviewing active subscriptions before adding more or finding an id to cancel.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds value by noting that NCDMV publishes no other machine-readable directory, establishing this tool as the definitive locator, and mentions that each office carries its district. This adds 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 very concise: two sentences plus example queries. It is front-loaded with the core purpose and every sentence adds necessary context. 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?

Despite no output schema, the description states what fields are returned (address, city, ZIP, phone, hours, district), which is sufficient for a read-only locator tool. It also explains the tool's unique role as the state's only machine-readable office directory.

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

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

The input schema has 6 parameters with full descriptions (100% coverage). The description adds real-world usage examples (e.g., 'DMV offices in Raleigh') and elaborates on search by office name, city, or ZIP, enriching but not duplicating the schema. It goes beyond baseline by providing context for parameter usage.

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

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

The description clearly states the tool finds NC DMV driver license offices and license plate agencies, providing address, city, ZIP, phone, and hours. It gives concrete examples of queries it answers, and distinguishes itself from the sibling tool nc_dmv_wait_times by specifying that for live queues that other tool should be used.

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

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

The description explicitly tells when to use this tool (for office location info), and when not (for live queues use nc_dmv_wait_times). It also lists search criteria: office name, city, or ZIP, providing clear guidance on usage scenarios.

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

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

Annotations already declare readOnlyHint, openWorldHint, etc. The description adds valuable behavioral details: data source ('published by NCDMV itself'), refresh rate ('refreshed continuously'), and special case outside business hours ('idle queue rather than a measurement'). This exceeds annotation coverage.

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

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

The description is a single paragraph but packs all essential information: purpose, data source, example queries, parameter notes, and edge case behavior. Slightly verbose on the 'only two states' fact, but still efficient overall.

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 5 parameters, no output schema, but rich annotations, the description covers all critical aspects: what it does, what data it returns, parameter semantics, edge cases (closed offices), and realistic usage scenarios. No gaps identified.

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

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

With 100% schema coverage, the description still adds value by explaining parameter usage, e.g., 'case-insensitive office-name substring' for 'office', 'wait ranks shortest average wait first' for 'sort', and default values for 'service' and 'limit'. This enriches 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 the tool provides 'live wait times at North Carolina DMV offices' with specific metrics (average wait, longest wait, open status). It distinguishes itself from sibling tool 'nc_dmv_offices' by focusing on live data and includes example queries, making the purpose unmistakable.

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

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

The description gives good context on when to use the tool (e.g., checking wait times, finding shortest line) and mentions behavior outside business hours. It does not explicitly compare to alternatives like 'nc_dmv_offices' but implies the distinction through its focus on live data.

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?

Disclosures beyond annotations: rate-limited to 5 per identifier per day, free, doesn't count against tool-call quota. 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?

Concise but packed with useful information: purpose, when to use, prohibitions, behavioral traits. No wasted words, front-loaded with the core function.

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 feedback tool with well-documented parameters and no output schema, this description covers everything an agent needs: type of feedback, context object, message format, and usage constraints.

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

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

Schema has 100% coverage with clear parameter descriptions. Description adds usage guidance like 'be specific' and '1-2 sentences typical' but doesn't repeat schema details extensively.

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 sends feedback to Pipeworx about bugs, missing features, data gaps, or praise. It distinguishes from sibling tools like ask_pipeworx by focusing on tools/packs feedback rather than general queries.

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 (bug, feature, data_gap, praise) and what not to include (don't paste user prompt). Also mentions rate limits and that it's free, providing clear context for when to invoke.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. The description adds value by explaining the data source (CF analytics-engine), privacy (no PII), and caching behavior (5min-1h depending on window). 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 two sentences plus a bullet list, front-loaded with the core output. Every sentence adds value, and the structure is clear and efficient.

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

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

For a simple tool with one optional parameter and no output schema, the description covers purpose, usage guidance, behavioral context, and parameter meaning comprehensively. Nothing missing.

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

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

Schema coverage is 100% with a detailed description for the single parameter 'window', including its enum and effect. The description only repeats the enum values without adding new information, so it meets the baseline but does not exceed.

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

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

The description clearly states the tool returns top tools, top packs, and total call volume over a recent window. It distinguishes itself from siblings like discover_tools by focusing on trending/current usage data, and provides 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 explicitly lists three use cases (discovering hot data sources, confirming canonical tool, aligning use case). It does not explicitly state when not to use, but the context is clear and no alternative sibling is named.

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=true and idempotentHint=true. The description adds substantial behavioral context: internal logic (monotonicity violations, partition-sum checks, similarity anchor, partition filter), response structure (opportunities array, fill check details), and a clear warning about not trading when edge is non-positive. 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 long but well-structured: starts with core purpose, then explains three modes in logical order. Each sentence adds value, but some technical details (e.g., Jaccard threshold, placeholder fraction) could be condensed. Front-loading is effective. Overall, slightly verbose but justified by complexity.

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

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

Despite no output schema, the description provides a thorough overview: all three modes, internal logic, response structure, and critical fill-check caveat. It references sibling tool for custom sizing. For a complex analysis tool, this description leaves no major gaps in understanding how to use and interpret results.

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

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

Schema coverage is 100% with descriptions for event and topic, but the description adds immense value beyond schema: explains no-args mode (trending_scan), provides example slugs/questions, describes how each mode works internally, and details the fill check. This far exceeds baseline for schema-covered parameters.

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: 'Find arbitrage opportunities on Polymarket via monotonicity violations + partition-sum checks.' It distinguishes itself from sibling tools (e.g., polymarket_edges, polymarket_fill_risk) by detailing its specific scanning modes (trending_scan, event, topic) and the underlying logic.

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

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

The description gives explicit guidance for each mode: 'Call with NO args for a `trending_scan`', '`event` (recommended for a specific market)', '`topic` (for cross-event scanning)'. It explains when to use cross-event mode and warns about fill check: 'realizable_edge_pp ≤ 0 means...do not trade it.' Also references sibling tool polymarket_fill_risk for custom sizing, indicating an 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 provide readOnlyHint, openWorldHint, and idempotentHint. The description adds significant behavioral context: caching (1h KV), diagnostic information in responses, Fed bets excluded from ranking, 24h-move warning, and details on how model families are computed. It fully discloses 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 long but well-structured, starting with the core purpose, then detailing model families, response structure, parameters, and caching. Each section adds value, though some details (e.g., exact model formulas) could be concise. The front-loaded purpose sentence is effective.

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

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

With no output schema, the description adequately describes the response structure (by_segment, diagnostics) and explains common scenarios like empty segments. It covers caching, filter knobs, and edge conditions. However, missing explicit output field types, but the textual description is sufficient for agent understanding.

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

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

Schema coverage is 100% with parameter descriptions. The description adds extra context, such as explaining that min_kelly applies only to single-leg opportunities (not partition arbs), how tradeable-edge knobs work, and the meaning of min_partition_leg_kelly. This enhances understanding beyond the schema alone.

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

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

The description clearly states the tool scans Polymarket markets and returns opportunities where Pipeworx data disagrees with market price. It uses specific verbs ('scan', 'return opportunities') and distinguishes from sibling tools like polymarket_arbitrage by focusing on Pipeworx disagreement and model-driven signals.

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

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

The description explicitly frames the tool for 'what should I bet on today' and notes that agents can discover opportunities without paging hundreds of markets. It implies use for daily betting research but does not explicitly contrast with sibling tools like polymarket_arbitrage or polymarket_edge_tracker, leaving some ambiguity about when to use alternatives.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds valuable behavioral context, such as the response structure (tracked[], expired[], snapshot_dates[]), field meanings (trend, decay_pp_per_day), and limitations (60-day snapshot TTL, snapshot gaps). No contradiction with annotations.

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

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

The description is well-structured and front-loaded with the purpose. It is dense but every sentence adds value, covering purpose, usage context, parameter details, response structure, and limitations. It is appropriately sized for the complexity, though could be slightly more concise.

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

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

Given the complexity of the tool (three return arrays with multiple fields), the lack of an output schema, and rich annotations, the description is remarkably complete. It explains every field in the response, the meaning of the data, and the limitations (TTL, snapshot gaps). It leaves minimal ambiguity for an AI 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?

Schema coverage is 100% with both parameters already described in the input schema. The description repeats the parameter explanations (e.g., days lookback, window family) but adds no significant new meaning beyond defaults and constraints already present in the schema. Hence baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: providing edge persistence and decay telemetry from daily polymarket_edges snapshots. It answers a specific question about edge duration and shrinkage, distinguishing between fresh and old wide edges. However, it does not explicitly differentiate from sibling tools like 'polymarket_edges', so it lacks explicit sibling differentiation.

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

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

The description implies usage for evaluating edge decay (e.g., a 3-week-old wide edge is different from a fresh one), but it does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternative tools like 'polymarket_edges'. The usage context is implied but not clearly delineated.

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 behavioral traits beyond annotations: it walks the order book ladder, returns metrics like top_of_book, vwap_fill_price, slippage_pp, shares_filled, verdict, and warns about forced directional risk—all consistent with readOnly/idempotent annotations.

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

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

Description is front-loaded with core purpose then structured into single-market and basket sections. While somewhat dense, every sentence adds value; minor redundancy in repeated warnings but justified by complexity.

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

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

Despite no output schema and complex dual-mode behavior, the description fully covers parameter semantics, return fields (top_of_book, vwap, slippage, shares_filled, verdict, capture_ratio, profit_usd, thin_legs, etc.), and critical warnings, making it self-sufficient.

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

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

Schema coverage is 100%, so baseline is 3. The description adds significant context: explains interaction between market/event, side defaults and auto-detection, and how size_usd is interpreted differently in single vs basket modes, exceeding schema detail.

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

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

The description clearly states it performs a 'realizable-vs-theoretical edge check against live CLOB order-book depth' and distinguishes between single-market and basket modes, effectively differentiating it from siblings like polymarket_arbitrage and polymarket_edges.

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

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

Explicitly states 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500' and warns against partial basket fills converting arb into directional risk, 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?

The description extensively discloses behavioral traits beyond annotations: compatibility warnings for non-equivalent bet shapes or unmatched events, temporal alignment checks, and skipped cross-type/subtype counters. Annotations already indicate read-only, idempotent, non-destructive behavior, and the description adds detailed context on when results are meaningful.

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 thorough but somewhat verbose, especially with the detailed explanation of compatibility warnings and counter fields. It is front-loaded with purpose and modes, but the extra detail could be condensed without losing clarity.

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

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

Given the complexity of the tool (dual venue, multiple modes, safety fields), the description covers all essential aspects: modes, parameters, response structure (leg-by-leg prices, top spreads, safety fields), and caveats. No output schema exists, but the description sufficiently explains the return format.

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

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

The input schema covers all 3 parameters with descriptions. The description adds meaning by explaining the two modes (topic vs explicit) and listing the 10 pre-mapped shortcuts. It also clarifies that explicit parameters override the topic-mapped side.

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

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

The description clearly states the tool computes cross-venue spread between Kalshi and Polymarket for the same resolving question. It distinguishes two modes (topic and explicit) and differentiates itself from similar sibling tools like polymarket_arbitrage by focusing on cross-venue comparison.

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

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

The description provides clear context on when to use the tool (to compare prices across venues for the same question). It notes that pre-mapped topics often return compatibility warnings, implying explicit mode is more reliable. However, it does not explicitly state when NOT to use it or mention specific alternatives.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds scoping context ('scoped to your identifier') and behavior for listing keys, which expands beyond annotations without contradiction.

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

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

Three sentences, front-loaded with core action, no fluff. Could be slightly more concise, but structure is clear and efficient.

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

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

Given the tool's simplicity (1 optional param, no output schema, strong annotations), the description covers usage, scope, and relationships 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 has 100% coverage for the single optional parameter. Description reinforces that omitting key lists all keys, and adds semantic context (scope, pairing with remember/forget), adding 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?

Describes specific verb+resource ('retrieve a value previously saved via remember, or list all saved keys'), provides concrete use cases (ticker, address, research notes), and distinguishes clearly from sibling tools remember and forget.

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

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

States when to use (look up stored context) and how to use (omit key for listing, pair with remember/forget). No explicit exclusions or alternative tools, but the context is clear and sufficient.

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

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

Annotations already indicate readOnly, idempotent, openWorld, and non-destructive. The description adds valuable context: the mark_read behavior that alters future calls, the return fields, and that polls work fine. 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 3-4 sentences, each serving a purpose: main action, return fields, filtering options, side-effect, and alternative access. No redundant words. Front-loaded with the primary purpose.

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

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

For a read-only list tool with no required params and no output schema, this description covers everything: what it returns, how to filter, side-effects, polling suitability, and an alternative endpoint. It equips an agent to select and invoke the tool correctly without gaps.

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

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

Schema coverage is 100% for 5 parameters. The description adds context beyond the schema: an example for type ('sec_8k'), explains the ISO timestamp requirement for 'since', and clarifies that mark_read flags events as read to affect subsequent calls. This enriches the schema definitions.

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

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

The opening sentence 'Pull fired events from your subscription feed' clearly states the verb and resource. It specifies the tool's output (source, citation_uri, raw payload) and distinguishes it from sibling tools like 'list_subscriptions' which would manage subscriptions rather than fetch events.

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 filtering by type and ISO timestamp, and the mark_read side-effect for polling. It mentions an alternative URL for scripts/dashboards. However, it does not explicitly state when NOT to use this tool vs other sibling tools, though the context is clear enough.

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

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

Annotations already declare readOnlyHint, idempotentHint, etc. The description adds significant behavioral context: fan-out to multiple sources, fallback logic, USPTO patent soft-fail, return structure (grouped by source, total_changes, citation URIs), and relative date format details.

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

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

The description is a single paragraph but is well-organized, beginning with common queries and then detailing sources, parameters, and return structure. Every sentence adds value; no fluff. Could benefit from slight structuring (e.g., bullet points) but remains efficient.

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

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

Given the tool's complexity (multiple sources, fallback, date parsing, soft-fails), the description covers all important aspects. No output schema exists, but the return structure is described adequately. The description fully informs an agent on how to invoke and what to expect.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaningful context beyond schema: for 'since' it explains relative shorthand and gives examples, for 'value' it mentions ticker or CIK, for 'type' it notes only company is supported. This enhances 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 states the tool provides a change feed for a company in the last N days/weeks/months via one parallel call, with specific data sources listed. It also distinguishes from the sibling tool 'entity_profile' by contrasting dynamic changes vs. static profile.

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

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

The description provides example queries and explicitly recommends 'entity_profile' when static profile is needed instead. It describes fallback behavior (GDELT→GNews) and soft-failures, giving clear context. Lacks explicit 'when not to use' beyond the alternative, but is strong overall.

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 useful behavioral context beyond annotations: memory scoping by identifier, persistence differences between authenticated (persistent) and anonymous (24-hour) sessions. No contradiction with annotations (idempotentHint=true implies safe re-save).

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 (three sentences) and well-structured: purpose first, then usage guidance, then behavioral notes. 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?

The description is complete for a store operation with no output schema. It covers purpose, when to use, memory scoping, and persistence. Could mention return confirmation 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 the schema already documents the two parameters. The description provides usage examples but no additional format or constraint details 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 verb 'save' and the resource 'data the agent will need to reuse later', with specific examples like 'resolved ticker', 'target address'. It distinguishes from sibling tools 'recall' and 'forget' by mentioning them directly.

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 ('when you discover something worth carrying forward') and provides examples. It mentions pairing with 'recall' and 'forget' as alternatives but does not explicitly state when not to use.

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

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

Annotations already declare readOnlyHint and idempotentHint. Description adds that it internally cascades through several lookups, replacing 2-3 manual steps, which provides useful latency expectations.

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

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

Well-structured with examples first, then purpose, then type details. Each sentence adds value, though slightly verbose; could be trimmed 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?

No output schema, but description fully explains return format for both company and drug types, including citation URIs. Covers inputs, outputs, internal process, and disambiguation.

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

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

Schema has 100% coverage baseline 3. Description adds concrete examples (e.g., 'AAPL', 'ozempic') and explains return values for each type, enhancing meaning 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 resolves names to official identifiers with specific examples ('What's the ticker for...'). Distinguishes from siblings like entity_profile by emphasizing 'use first when you need an ID'.

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

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

Explicitly says 'Use FIRST whenever you have a name but need an ID.' Does not explicitly list when not to use, but context is clear. Could improve by contrasting with tools like 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 declare readOnly, idempotent, openWorld, and non-destructive. Description adds that it returns a ranked list with score, confidence, signal density per entity, and that it probes each entity with ai_visibility_check. 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 plus a one-liner. Front-loaded with purpose. No extraneous information.

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

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

Given the tool complexity and lack of output schema, the description adequately covers return format (ranked list with score, confidence, signal density) and internal behavior (probing each entity with ai_visibility_check).

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

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

Schema coverage is 100%, so baseline is 3. Description adds context that the first entity is treated as subject for narrative and that models parameter is optional, which goes 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?

Description clearly states it compares AI visibility across multiple entities side-by-side, using ai_visibility_check internally, and ranks results. This distinguishes it from the single-entity tool ai_visibility_check among 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 states use case for competitive AI-marketing audits and gives an example question. Does not explicitly state when not to use or alternative tools, but the context implies single-entity use should use ai_visibility_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?

Discloses that it fans out across two external services, mentions potential partial failures, and warns that bundlephobia's first measurement can take 5-30s. These are beyond what annotations (readOnlyHint, openWorldHint, idempotentHint) provide. 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 yet efficient, front-loading the core purpose, then providing usage guidance, behavioral notes, and limitations in a logical flow. No fluff.

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

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

Given the absence of an output schema, the description thoroughly explains the return value (summary block, advisory detail, links, alternative versions). Covers edge cases like partial failures and scoped packages, making it self-contained.

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

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

Schema coverage is 100% with descriptions already present. The description adds extra context: scoped packages accepted for 'package' and default behavior for 'version'. This enhances understanding 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?

The description clearly states the composite nature of the tool, combining deps.dev and bundlephobia data, and defines its purpose: assessing an npm package for safety, popularity, and size. It distinguishes itself from sibling tools, which are unrelated.

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: when an agent asks 'is X safe / popular / small' or 'what does adding lodash cost me'. Also specifies NPM ecosystem only in v1 and points to deps.dev:version directly for other ecosystems, providing clear alternatives.

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

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

Annotations already declare readOnlyHint, idempotentHint, etc. Description adds useful beyond-annotation details: embedding model (BGE-base-en), chunking (500-char windows), similarity measure (cosine), and 200K char cap with truncation flag. 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?

Single well-structured paragraph. Front-loaded with purpose. Every sentence contributes value: usage scenario, output details, pairing suggestion, technical specs. No fluff.

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

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

Covers purpose, when to use, output (passages with offsets and scores), truncation behavior, and pairing. No output schema exists, so description adequately describes return format. Could be slightly more precise about output structure but sufficient.

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

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

Schema coverage is 100% with descriptions for all three parameters. Description reinforces usage but does not add new meaning beyond 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?

Description states verb 'search inside', resource 'fetched record', and output 'passages with offsets and scores'. Distinguishes from siblings like ask_pipeworx_grounded by focusing on searching within already-fetched text, not the whole document.

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

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

Explicitly says 'Use when the record is too big to cram into the prompt' and suggests pairing with ask_pipeworx_grounded. Does not explicitly state when not to use, but context is clear enough.

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

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

Annotations present (idempotentHint=true). Description adds useful behavioral details: OAuth requirement, phone verification need, webhook auto-disable after 10 failures, and HMAC signing. Could be more explicit about idempotency behavior (e.g., duplicate subscription handling) but still adds value.

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?

Somewhat long but well-organized: main purpose first, then type-specific params, then delivery channels. Every sentence adds value. Minor verbosity in delivery section could be tightened, but overall effective.

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

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

Covers all key aspects: auth, supported types with param details, delivery channels with prerequisites and constraints. No output schema, but description mentions return of subscription id. Could add success/error handling or rate limits beyond SMS cap, but largely complete for a creation 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?

100% schema coverage baseline is 3. Description greatly enriches parameter meaning with concrete examples (e.g., 'items:["5.02"] = officer change', 'min_spread_bps?:500') and detailed delivery channel constraints (phone verification, SMS cap, webhook HMAC). Exceeds schema detail.

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

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

The description clearly states the verb 'Create' and the resource 'proactive monitoring subscription', with immediate output detail ('Returns the new subscription id'). It distinguishes itself from siblings like list_subscriptions, unsubscribe, and recent_alerts by focusing on creation and live-data event streams.

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 prerequisite (Pipeworx OAuth account), unsupported auth types (anonymous/BYO), and delivery channel options with constraints (phone verification, 10/day SMS cap). Lacks explicit 'when not to use' but covers context well.

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

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

Annotations already indicate read-only, idempotent, non-destructive. The description adds behavioral context: it returns example questions drawn from a live catalog and teaches how to call meta-tools. No contradictions. It explains what to expect without repeating 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 alternative phrasings, then describes return value and usage. It is a single paragraph that could be slightly more concise, but every sentence adds value. No wasted words, though some repetition exists.

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?

Although no output schema exists, the description hints at return format: 'category-bucketed example questions... each with the exact tool + argument shape'. This is sufficiently informative for an agent to understand what the tool provides. For a simple tool with one optional parameter, it is complete enough.

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

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

Schema coverage is 100%. The description adds value by explaining 'Call with no arguments for the full spread, or pass topic (e.g. 'finance', 'pharma', 'betting') to focus.' It lists example values and clarifies behavior, enriching beyond the schema's parameter description.

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

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

The description clearly states the tool's purpose: it returns category-bucketed example questions for an agent that just connected. It lists triggering questions like 'What can I ask Pipeworx?' and explains it provides exact tool + argument shapes. This distinguishes it from siblings like ask_pipeworx or entity_profile, serving as the onboarding entry point.

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

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

Explicitly says 'Use this FIRST when you do not yet know what Pipeworx can do for you, or to learn how to call the meta-tools.' This indicates primary use case. It also mentions optional topic filtering. However, it does not explicitly exclude other situations or directly reference alternatives like ask_pipeworx, though the context is clear.

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

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

Annotations indicate a non-destructive mutation (readOnlyHint=false, destructiveHint=false). Description adds that row is deactivated not deleted, preventing data loss, and ownership enforcement. Adds value beyond annotations.

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

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

Two concise sentences with no unnecessary words. First sentence states action and constraint, second explains consequence. Excellent structure.

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 one-parameter mutation with no output schema, description covers purpose, ownership, and outcome. No missing critical information, though output format is omitted.

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?

Only one parameter 'id' with schema coverage 100% and description linking to 'subscribe'. Tool description does not add further parameter details beyond what schema provides, so baseline score of 3 is appropriate.

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

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

Description clearly states 'Cancel a subscription by id', specifying verb and resource. Distinguishes from siblings like 'subscribe' 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 clear context: ownership enforcement limits usage to own subscriptions, and explains effect of deactivation referencing sibling 'recent_alerts'. No explicit when-not usage, but sufficient for 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 declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. The description adds significant behavioral details: the internal routing (fast path vs. grounded pipeline), the verdict categories (confirmed, approximately_correct, refuted, inconclusive, unsupported), and the inclusion of a citation and reasoning. 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 relatively long but well-structured: it starts with example triggers, explains the two processing paths, details the return values, and notes efficiency benefits. It could be slightly more concise, but every sentence adds useful information. Front-loading with relevant keywords helps.

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

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

Given the tool's complexity (two processing paths, multiple verdicts) and the absence of an output schema, the description provides a thorough explanation of return values and behavior. It covers what the tool does, how it processes claims, and what the agent can expect, making it complete for an AI agent.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining that tolerance_pct overrides the implied tolerance from the claim wording and gives usage examples (e.g., 'set 1–2 for hallucination detection'). This enriches the semantics beyond the raw 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 as 'natural-language claim verification against authoritative sources' with concrete examples like 'fact check' and 'verify the claim that…'. It distinguishes from siblings by noting it replaces 4-6 sequential calls.

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

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

The description explicitly tells when to use the tool: 'Use whenever the agent needs to check whether something a user said is factually correct.' It also outlines two distinct processing paths (SEC EDGAR for financial claims, grounded pipeline for others), providing clear context. However, it doesn't explicitly mention when not to use it or compare directly to sibling tools 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.