Maryland MVA

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

Annotations already indicate read-only, idempotent, open-world behavior. Description adds details about which LLMs are probed, key handling, and return structure, enriching transparency 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 efficient sentences: core action, model details, use cases. No fluff, well front-loaded, each sentence adds value.

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

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

Given no output schema, description adequately explains return format (per-model fields + combined view). Could mention rate limits or model availability, but overall sufficient for an external API 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%, so parameters are documented. Description goes beyond by explaining the default model for 'models' and that '_apiKey' is needed for Anthropic probes, adding practical context beyond schema.

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

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

Description clearly states the tool probes LLMs to score visibility (0-100) for a business/brand/product/topic. It specifies the default model and optional Anthropic integration, and provides example use cases, distinguishing it from siblings like entity_profile.

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

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

Provides explicit use cases (AI-marketing audits, pre-launch brand checks, competitive monitoring). However, it does not directly compare to similar sibling tools like scan_competitor_ai_presence, leaving room for clearer when-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 adds meaningful runtime behavior beyond the readOnly/openWorld/idempotent annotations: it routes to one of many tools, fills arguments, and returns structured answers with stable pipeworx:// citation URIs. It does not discuss failure modes or edge cases, but the annotation suite already covers the safety profile.

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

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

The description is dense but well organized: preference, scope, mechanics, triggers, examples, and routing guidance each earn their place. The main directive is front-loaded, and the examples serve as compact demonstrations rather than filler.

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

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

Despite the absence of an output schema, the description explains what the tool returns (structured answer with citation URIs), when to call it, what inputs it expects, and where it fits relative to other tools. An agent has enough context to select and invoke it correctly.

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

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

All parameters are documented in the schema, including the natural-language 'question' field and its aliases, so the baseline applies. The description contributes example questions but no additional meaning about parameter syntax or constraints beyond what the schema already states.

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

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

The description clearly identifies a general-purpose factual answering tool that routes questions to authoritative structured data sources and returns cited answers. It strongly conveys the tool's central role with 'START HERE' and explicit domain coverage, but it does not explicitly distinguish ask_pipeworx from sibling variants like ask_pipeworx_beta or ask_pipeworx_grounded.

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

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

It states a strong preference over web search, gives concrete trigger phrases, supplies multiple illustrative queries, and explicitly carves out niche cases like X visibility and MD DMV vehicle registrations as dedicated-tool territory. This gives an agent clear when-to-use and when-not-to-use guidance.

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

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

Annotations already cover read-only and idempotent behavior, and the description adds valuable context: beta status, experimentation lifecycle, current state with no active candidate, full router functionality rather than a partial fallback, and comparison against stable routing. 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 concise and front-loaded with the essential identity and behavior. A small amount of repetition exists between 'identical universal router' and 'currently matches ask_pipeworx exactly', but the added temporal and experimental context justifies the length.

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

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

For a router with a single required string parameter and strong annotations, the description adequately covers purpose, current behavior, usage, and output compatibility. It could be more explicit about response format nuances, but referencing ask_pipeworx's response shape is sufficient given the sibling 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%, and the schema already documents the question parameter and all five aliases. The description adds no new parameter-level meaning beyond saying it accepts the same arguments as ask_pipeworx, so it meets the baseline 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 identifies the tool as a beta version of ask_pipeworx, a universal router, and states exactly what makes it distinct: candidate routing improvements under test. It names the sibling it relates to and clarifies it is not a fallback or subset.

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

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

It explicitly says to use the tool exactly like ask_pipeworx when the newest routing is desired, and notes results are compared against the stable router. It does not detail exclusions or when to prefer the stable ask_pipeworx, but the intended context is clear.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds substantial behavioral detail beyond annotations: refusal payload enumerations, verbatim evidence extraction, single-source grounding, the extra LLM call cost, and explicit refusal reasons. No contradiction with annotations.

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

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

The description is dense but every sentence earns its place: purpose, output shape, refusal reasons, use-case guidance, and cost/alternative are all covered. The core behavior is front-loaded in the first sentence, and the sibling distinction is clear without redundancy.

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

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

There is no output schema, so the description appropriately discloses the full return shape, including answer, evidence, confidence, source, fetched_at, and refusal_reason values. It also explains the operational tradeoff versus ask_pipeworx, making the tool fully understandable and safely invocable in 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 description coverage is 100% because all parameters are aliases of the single 'question' property, and the schema documents each alias and the natural-language requirement. The description does not add additional parameter meaning, but it does not need to given the exhaustive schema coverage.

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

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

The description states a specific verb and resource: it answers questions by extracting answers using only the tool result, with explicit refusal behavior. It clearly distinguishes itself from ask_pipeworx by the grounded extraction mechanism and mentions 'same routing as ask_pipeworx' to position it relative to the sibling.

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 is explicit about when to use this tool: for high-stakes reads where answers will be quoted, cited, or acted on, and where hallucination is unacceptable. It also gives an explicit alternative and preference rule: 'prefer ask_pipeworx for casual lookups' because this mode costs an extra LLM call.

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

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

Annotations already declare readOnly, idempotent, and non-destructive. The description adds deep transparency: low-confidence short-circuits, closed market handling, wide-spread warnings, cancellation rule parsing, and fallback behavior on API errors. 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?

While quite long, the description is well-structured with clear sections (classifiers, fan-out examples, response shapes, etc.). Every sentence adds necessary detail for correct tool use. Slightly verbose but justified by the tool's complexity.

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

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

Given no output schema, the description thoroughly explains the response structure (result.market, analysis, evidence) and covers edge cases (low confidence, closed markets, wide spreads, cancellation rules). It also explains the resolver contract and parent event extractor. Very 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 covers all 3 parameters with descriptions. The tool description adds significant context beyond schema: explains the effect of 'depth' (quick vs thorough), details valid input formats for 'market', and clarifies the use of 'include_raw'. This adds genuine value.

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

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

The description clearly states the tool's purpose: research a Polymarket bet by pulling Pipeworx data. It provides concrete examples of inputs and outputs, and differentiates from sibling tools like polymarket_arbitrage by focusing on comprehensive research and evidence.

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 cases (should I bet, what does data say, is there edge) and provides extensive examples of bet types and fan-out behavior. While it doesn't explicitly list when not to use it, the context is clear enough for appropriate selection.

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

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

Beyond annotations (readOnlyHint, etc.), description adds detailed behavioral info: data sources (SEC EDGAR/XBRL for companies, FAERS for drugs), handling of off-calendar fiscal years, result sorting by primary metric, and output includes citation URIs.

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 moderately lengthy but every sentence adds value. Front-loaded with query patterns. Could slightly tighten, but overall efficient 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 tool complexity (two entity types, diverse data sources, sorting, citation URIs), description covers all essential behaviors. No output schema, but return format is adequately described. Completeness is high.

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?

Description adds significant meaning beyond schema: explains what each 'type' enum gathers and provides concrete examples for 'values' (tickers/CIKs for company, drug names). Schema coverage is 100%, but description enriches each parameter.

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

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

The description clearly states the tool does side-by-side comparison of 2-5 companies or drugs, with specific verb phrases ('Compare X and Y', 'rank these companies'). It distinguishes itself from siblings by noting it reduces 8-15 sequential lookups.

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

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

Explicitly states when to use (for comparisons) and when not to (avoids sequential single-pack lookups). Provides clear examples of input patterns and types (company vs drug).

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

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

Annotations already mark it read-only, open-world, idempotent, and non-destructive, but the description adds substantial behavior beyond that: parallel decomposition across 5,798 tools, findings packet structure, gaps[] for unanswered facets, hop/aggregation semantics, contradictions[] behavior, semantic excerpting, citation resolvability, and latency expectations. No contradiction with annotations.

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

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

The description is front-loaded with account requirements, the fallback tool, and core functionality. It contains some redundancy, such as repeating the hop field and mixing 'findings packet' with 'no single output,' and a few niche details like the ADR/LangSmith note. Still, most sentences earn their place given the tool's complexity.

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

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

There is no output schema, so the description carries the full burden of explaining return values and behavior. It covers output structure, gaps[], contradictions[], citation URI fetchability, semantic excerpting, timing, auth/plan gating, and fallback routing. Nothing essential for correct invocation appears 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%, so the baseline is 3. The description adds practical semantics for both parameters: depth is mapped to facet count and hop behavior, and question is described as natural language accepting broad/multi-part queries. This is useful but not exhaustive, so 4.

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

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

The description states a specific verb-resource pair: grounded multi-source research across Pipeworx's 1517 structured data sources in one call. It explicitly contrasts itself with open-web search and differentiates itself from ask_pipeworx by saying single lookups should use ask_pipeworx instead, making sibling distinction clear.

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

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

It gives explicit when-to-use guidance: broad/multi-part questions over structured data, with concrete examples. It also gives when-not-to-use guidance, directing users to ask_pipeworx for single lookups and for non-signed-in users, and it explains depth-level selection.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable behavioral details: returns top-N tools with full schemas and curated examples, ready to call directly. No contradiction with annotations.

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

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

Description is concise (3-4 sentences) and front-loaded with the main purpose and usage. Every sentence adds value: purpose, when to use, what it returns, and a strong call-to-action. No superfluous text.

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 (meta-tool with aliases, no output schema), the description covers all needed context: how to invoke it, what it returns (tools with names, descriptions, schemas, examples), and the strategic advice to use it first. No missing information.

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

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

Schema coverage is 100% – all 6 parameters are described with aliases and types. The description does not add new parameter semantics; it only lists example queries. Baseline score of 3 is appropriate as the description does not enhance 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?

Description clearly states 'Find tools by describing the data or task.' It distinguishes this meta-tool from sibling tools that perform specific analyses or searches. The extensive list of domains and the directive to call it first when many tools exist makes 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?

Explicit guidance: 'Use when you need to browse, search, look up, or discover what tools exist for...' and 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' This clarifies when to invoke vs. alternative 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, openWorldHint, idempotentHint, and non-destructive, and the description layers substantial behavior on top: per-source soft-fail semantics (USPTO PatentsView sunset), the "empty section is a real no-data, not a bug" contract, expected-empty FDA results for small-molecule-only companies, and resolved:false-with-notes handling for private companies. Nothing contradicts the annotations.

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

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

The description is front-loaded with intent examples and the core value proposition, and nearly every clause earns its place — source list, failure semantics, input forms, edge cases. However, it is a dense single run-on paragraph that intermixes input handling, output shape, and failure semantics with semicolon-chained clauses, which hurts scannability.

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 high-complexity tool with no output schema, the description carries the burden well: it enumerates the source fan-out, key return fields (cik, company_name, resolved_from/to, recent_filings with URIs, fundamentals), and the sources_used/sources_failed contract. It still omits the return shapes of the news, hiring, and LEI sections and leaves the fundamentals detail abbreviated, so the output contract is not fully specified.

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% — the schema already documents type's interchangeable enum and value's ticker/CIK/name formats with the same examples. The description adds the resolved_from/resolved_to output nuance tied to name input, which is useful context, but it is output-oriented and the core parameter semantics remain schema-carried.

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

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

The description leads with concrete user-intent triggers ("Tell me about X", "research Acme", "brief me on Tesla") and pins the scope as a "full cross-source profile of a US public company in ONE parallel call." It also distinguishes itself from siblings by explicitly declaring "ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups," naming the alternative it should win against.

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 "ALWAYS PREFER ... when the user asks for a holistic view" directive gives an explicit when-to-use rule with a named alternative, and the input-format guidance (ticker, zero-padded CIK, company name) plus private-company behavior clarifies expected usage. It stops short of exclusions — it never says when to pick compare_entities, deep_research, or resolve_entity instead — so the when-not side is incomplete.

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 destructiveHint=true, but description adds context about clearing sensitive data. No contradictions, and description aligns with annotations.

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

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

Two sentences: first states purpose, second provides usage guidance. Every sentence provides value, no wasted words.

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

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

Tool is simple with one required parameter and no output schema. Description covers purpose, usage scenarios, and sibling relationships. Complete for a delete operation.

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

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

Schema coverage is 100% with one parameter 'key' described as 'Memory key to delete'. Description does not add additional detail beyond schema, so baseline score of 3 applies.

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

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

Description clearly states 'Delete a previously stored memory by key.' Verb and resource are specific, and it distinguishes from sibling tools 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 says when to use: 'Use when context is stale, the task is done, or you want to clear sensitive data.' Also mentions pairing with remember and recall, providing 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 and destructiveHint=false. The description adds that it fetches the page and extracts content, which is consistent. However, it doesn't detail response format or potential rate limits, but overall adequate.

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 with front-loaded purpose, process, and use cases. No redundant filler, every sentence adds value.

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

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

Given 2 parameters, no output schema, and good annotations, the description fully informs the agent about tool behavior, output format, and use cases. No gaps.

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

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

Schema coverage is 100%. The description adds context for 'url' (full URL, example) and 'max_links' (default 25, max 50), enriching the schema documentation beyond the basic 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 explicitly states the tool generates a production-ready llms.txt file for any URL, with specific verb and resource. It distinguishes from siblings like 'scan_competitor_ai_presence' by focusing on a standard file format.

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

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

The description lists three clear use cases (client indexing, personal project, competitor audit), providing context for when to use, but does not explicitly exclude alternatives or 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=true, idempotentHint=true, destructiveHint=false, covering safety and idempotency. The description adds the return field list and explains the include_inactive parameter, providing 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?

Two sentences with the main action front-loaded. No wasted words; every sentence serves a purpose.

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

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

With annotations covering safety and idempotency, a simple parameter, and no output schema required, the description fully covers purpose, return values, and usage guidance. Complete for this tool.

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

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

Schema coverage is 100% with a good description for the only parameter. The description lists return fields, adding value beyond the schema. Baseline 3, upgraded for return field context.

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

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

The description clearly states 'List the caller's active subscriptions' and lists the returned fields (id, type, params, etc.). This distinguishes it from sibling tools like subscribe and unsubscribe.

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

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

The description provides explicit usage context: 'Use this to review what you're monitoring before adding more or to find an id to cancel.' It implies use before subscribe/unsubscribe but does not explicitly exclude 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 as false. The description adds valuable context: data source (MVA registration counts), breakdown by fuel category, monthly time series since 2020, and that the county file includes out-of-state counties flagged by 'in_maryland'. No contradictions with annotations.

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

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

The description is a single, well-structured paragraph with no wasted words. It front-loads the core purpose, then provides examples and parameter details. Every sentence serves a clear 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?

The description adequately explains the output: counts split by fuel category, with a statewide total for context, and monthly data. It mentions two files (county and ZIP) and the in_maryland flag. Without an output schema, it gives a sufficient mental model for the agent. Minor gap: no mention of exact field names or pagination, but these are not critical for basic 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?

Although schema description coverage is 100%, the description adds significant meaning: it explains that supplying 'zip' reads the ZIP-level file, that 'county' results include an 'in_maryland' flag, that 'group_by' can be 'county' or 'zip' with 'zip' implying group_by='zip', and that 'month' defaults to the latest published month starting from 2020/07. This enriches each parameter 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 uses specific verbs ('measure', 'answers') and clearly identifies the resource (Maryland EV adoption from MVA registration counts). It explicitly distinguishes from the sibling tool md_dmv_vehicle_registrations, which covers the entire fleet across all fuel types. Example queries concretely illustrate the tool's scope.

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

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

The description explicitly states when to use this tool vs. the sibling: 'For Maryland's whole registered fleet across every fuel type use md_dmv_vehicle_registrations.' It also provides multiple example questions and explains how to choose between county and ZIP-level data via the 'zip' or 'group_by' parameter.

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, idempotentHint, destructiveHint. Beyond these, the description adds behavioral context: it counts whole fleet, returns genuine statewide total and each county's share, and specifies the data is from MVA published monthly since 2020. 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-loads purpose, then details outputs and usage with example questions, ends with sibling reference. Every sentence is essential 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 the tool's simplicity and no output schema, the description fully explains return values (counts, total, share), usage context, and alternatives. It is complete for an agent to select and invoke the tool correctly.

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

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

Schema coverage is 100% (baseline 3). The description adds practical meaning: month defaults to latest and series starts at 2020/07, limit default returns all 25 rows, county examples include apostrophe handling. This adds 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?

Description clearly states the verb 'count' and resource 'vehicles registered in Maryland by county for a given month'. It specifies the data source (MVA), temporal range (since 2020), and explicitly differentiates from sibling md_dmv_ev_adoption.

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

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

The description explicitly says to use this tool for total fleet counts and points to md_dmv_ev_adoption for electric/hybrid data, providing clear context with alternatives. It also implies usage for month-over-month trends via the month argument.

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

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

Annotations are all false, so the description carries the full burden. It discloses rate limiting (5/day), the claim_token workflow for follow-up, that it's free and doesn't count against quota, and that the team reads digests daily. No contradiction with annotations.

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

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

The description is long but well-structured: purpose, usage, exclusions, token mechanics, and constraints each in succession. Every sentence adds value; no fluff. Slightly verbose but justifiably so for a tool with nuanced rules.

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 fully covers return behavior (claim_token), scope limitations, message formatting, rate limits, and even follow-up usage. It is comprehensive for a tool of this complexity.

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

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

Schema coverage is 100%, so baseline is 3. The description adds extra nuance beyond the schema, such as 'don't paste the end-user's prompt' and 'Describe the issue in terms of Pipeworx tools/packs', which clarify how to fill parameters correctly. This pushes it above baseline.

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

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

The description opens with a clear, specific verb+resource: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' This immediately distinguishes it from all sibling tools, none of which are about feedback.

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

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

Explicitly states when to use ('Use when a tool returns wrong/stale data...') and when not to use ('ONLY for tools served by this Pipeworx connection — if the tool came from a different MCP server... file it with that server instead'), providing clear alternatives and 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?

Discloses data source (CF analytics-engine), no PII, caching behavior (5min-1h), and aggregation method. Adds significant 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?

Four sentences, front-loaded with purpose, followed by use cases and technical details. No redundancy or fluff.

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

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

Covers input, output description, parameter, and caching. Lacks exact output structure but sufficient for a trending tool. Annotations compensate for missing output schema.

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

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

Single parameter 'window' has full schema description covering enums and semantics. Tool description does not add extra param info, but schema already provides adequate context.

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

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

Description clearly states the tool returns top tools, packs, and call volume over a recent window. Distinct from siblings like discover_tools and recent_alerts.

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

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

Explicitly lists three use cases for discovering hot trends, confirming canonical tools, and aligning use cases. Lacks explicit when-not-to-use but strong guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the tool is safe. The description adds substantial behavioral detail: threshold for partition gap (3pp), semantic anchor (Jaccard ≥0.30), partition filter (placeholder slugs), and fill check (theoretical vs realizable). These details go well 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 information-dense but well-structured with clear mode descriptions and technical details. It is front-loaded with the main purpose and modes. While every sentence adds value, the length could be slightly reduced for better conciseness, but it remains 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?

Despite the absence of an output schema, the description thoroughly explains the response structure: opportunities[] with fields (gap_pp, suggested_trade, reasoning, monotonicity violation context) and partition_check for event mode. It also covers edge cases like fill check and references sibling tool polymarket_fill_risk for custom sizing.

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

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

Schema coverage is 100% with descriptions for both parameters. The description adds meaning beyond the schema by explaining what constitutes a valid event slug (including full URLs) and what the topic parameter does with examples (e.g., 'Fed rate decision'). It also clarifies the default behavior when no parameters are provided.

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

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

The description specifies the tool's purpose: finding arbitrage opportunities on Polymarket via monotonicity violations and partition-sum checks. It clearly distinguishes three operational modes (trending_scan, event, topic) and differentiates from sibling tools by detailing unique functionality like fill checks and cross-event scanning.

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

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

The description provides explicit usage guidance: 'Call with NO args for a trending_scan', 'event (recommended for a specific market)', and 'topic for cross-event scanning'. It also advises when not to trade via fill check results. However, it does not explicitly exclude scenarios where alternative tools like polymarket_edges might be preferred.

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

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

Description extensively covers behavioral traits beyond annotations: model families, response structure, diagnostics, cache behavior, tradeable-edge knobs, and market move warning. No contradiction with annotations (readOnly, idempotent, openWorld, non-destructive).

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 excessively long (500+ words), including detailed formulas and algorithmic explanations. While informative, it lacks conciseness and could overwhelm an AI agent. Better to front-load key usage information and move technical details elsewhere.

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

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

Given 9 parameters, no output schema, and sibling tool set, the description covers all necessary aspects: three opportunity segments, response fields, diagnostics for empty results, cache behavior, and tradeable-edge filters. Very thorough.

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 good descriptions. The tool description adds extra context like min_kelly vs min_partition_leg_kelly distinction and slippage recommendations, but much of the parameter detail is already in the schema.

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

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

Description clearly states the tool scans Polymarket markets for edges, with explicit purpose 'what should I bet on today'. Distinguishes from sibling tools like polymarket_arbitrage and polymarket_edge_tracker by focusing on Pipeworx disagreement and daily opportunity discovery.

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

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

Describes ideal use case and provides context (Feds bets caveat, cache behavior). Lacks explicit when-not-to-use or alternative tool references, but the description implies it's for daily scanning vs. other specialized 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 indicate readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description reinforces these by detailing the read-only nature and the computation logic. It explains the response structure (tracked[], expired[], snapshot_dates[]) and clarifies that decay numbers come from daily closes, not intraday. This adds substantial behavioral context beyond the annotations.

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

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

The description is comprehensive yet concise for the complexity involved. It front-loads the core purpose and question, then systematically details the response fields and limitations. Every sentence adds value; there is no redundancy.

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

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

The tool has no output schema, so the description must fully explain the return values. It does so with detailed breakdowns of tracked[], expired[], and snapshot_dates[], including fields like trend and decay_pp_per_day. It also covers limitations (TTL, decay basis, gap days). Given the complexity and the presence of sibling tools, the description 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?

The input schema covers both parameters with descriptions, achieving 100% schema description coverage. The description adds default values (14 days, '1wk'), constraints (max 30, clamp 2-30, valid windows: 24hr, 1wk, 1mo), and clarifies that 'window' refers to snapshot family. This adds meaningful semantics 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 starts with a specific verb-resource pair: 'Edge persistence and decay telemetry built from daily polymarket_edges snapshots.' It answers a concrete question: 'how long has this edge existed and is it shrinking?' This clearly distinguishes it from the sibling tool 'polymarket_edges', which likely provides raw snapshots.

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

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

The description explains when to use the tool: to understand edge persistence and decay, and it contrasts a fresh wide edge with a 3-week-old one. It provides limits (60-day TTL, decay from daily closes) but does not explicitly state when not to use it or alternative tools. Sibling tools are listed, but no direct comparison is given.

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

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

Annotations (readOnlyHint, idempotentHint, destructiveHint=false) are consistent and augmented by the description, which details return fields like top_of_book, vwap_fill_price, slippage_pp, and warnings about thin books and forced directional risk. No contradictions.

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

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

The description is lengthy but well-structured with clear sections for single-market and basket modes. It front-loads the core purpose. While not extremely concise, each sentence adds essential information. Minor improvement could be using bullet lists for output fields.

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 modes, multiple parameters, no output schema), the description thoroughly explains all return fields for both modes, constraints (size_usd clamp, default sides), and edge cases (thin legs, forced directional risk). Very 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 descriptions cover all 4 parameters (100% coverage). The description adds value by explaining the exclusive requirement for market/event, default side behavior in basket mode, and the interpretation of size_usd for single-market vs. basket modes. This exceeds baseline 3.

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

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

The description clearly states the tool's purpose: 'Realizable-vs-theoretical edge check against live CLOB order-book depth.' It distinguishes single-market and basket modes with specific use cases, and contrasts with siblings like polymarket_arbitrage and polymarket_edges.

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

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

Explicitly states when to use: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500.' Also explains consequences of not using it, such as partial basket fills converting arb into unhedged directional position.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering the safety profile. The description goes far beyond that: it details the matching logic (token-overlap matcher), the meaning of temporal_alignment_unknown ('NOT the same as confirmed-aligned'), the fees_note disclosing that reported spreads are gross and not net tradeable edges, and the compatibility warning codes (event_subject_mismatch, temporal_mismatch, etc.). It also explains that legs with unknown metric_type are never paired and land in skipped_unclassified or low_confidence_pairs. This adds substantial behavioral context beyond the annotations and does not contradict them.

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

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

The description is long but well-structured with clear sections: TWO MODES, RESPONSE, SAFETY FIELDS, and counters. It front-loads the core purpose and then systematically covers matching, warnings, fees, and skipped categories. Every sentence carries information - there is little fluff. It could arguably be trimmed, but given the complexity of the tool and the absence of an output schema, the length is justified. It is not under-specified; it uses capitalization and section markers to improve readability. The structure earns a 4 rather than 5 because of its length, but it 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 - two modes, multiple safety fields, compatibility codes, temporal alignment semantics, fees disclosure, and skipped categories - the description covers all functional aspects an agent needs to invoke and interpret results correctly. There is no output schema, so the description carries the full burden of explaining the response structure, including top_spreads_pp, compatibility_warning, compatibility_codes, temporal_alignment, fees_note, and skipped counters. It also clarifies edge cases like null temporal_alignment and unclassified legs. Nothing critical is missing for the agent to call this tool effectively.

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% - each parameter has a description in the schema. The description adds value by explaining the topic list explicitly (listing all shortcuts), clarifying that explicit ticker/slug override the topic-mapped side, and noting that both modes run the identical token-overlap matcher. This goes beyond the schema's basic type/description by providing semantic relationships and usage context. While the schema already documents each parameter, the description enriches the meaning of how the parameters interact, so a 4 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 precise statement of purpose: 'Cross-venue spread between Kalshi and Polymarket for the same resolving question.' It clearly identifies the resource (spread between two venues) and the specific verb (compute/retrieve). It also distinguishes itself from sibling tools like polymarket_arbitrage and polymarket_edges by focusing explicitly on cross-venue comparison of the same question, and it further elaborates two modes (topic precuts vs explicit ticker/slug), leaving no ambiguity about what the tool does.

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 when-to-use guidance: it introduces two modes - topic shortcuts for common macros and explicit ticker/slug for custom pairings - and explains when each is appropriate. It also gives a critical usage warning: 'Real cross-venue spreads are rarer than the macro-shortcut list suggests — most pre-mapped topics return compatibility_warning today; pre-mapped ≠ tradeable.' This tells the agent when not to expect a tradeable spread and to verify matching. It also contrasts with siblings implicitly by being the cross-venue tool. The guidance is explicit about the conditions and caveats.

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, destructiveHint. Description adds scoping details (anonymous IP, key hash, account ID) and listing behavior, adding 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, front-loaded with action verb, no wasted words.

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

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

Given single optional key parameter, no output schema, and annotations covering safety, description provides complete context including scope and pairing with siblings.

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

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

Schema coverage is 100%; description adds minor clarification (omit to list all keys), but does not significantly enhance parameter 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?

Description clearly states it retrieves a previously saved value or lists all keys if omitted, distinguishing it from siblings '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?

Explicitly describes when to use (look up stored context) and how to pair with remember/forget, 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 declare readOnlyHint=true, but description says setting mark_read:true flags events as read, which is a state change. This contradiction undermines transparency. Without the contradiction, the description adds useful behavioral context, but the inconsistency is critical.

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 at four sentences, front-loads the purpose, and each sentence adds value without redundancy. No unnecessary 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?

Description covers return fields, filtering, and optional mutation via mark_read. It also mentions an alternative access method. However, the contradiction with annotations slightly reduces completeness regarding behavioral expectations.

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 usage examples (e.g., 'sec_8k') and reiterates parameter purposes, but does not add significant new meaning beyond the schema descriptions.

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

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

Description clearly states 'Pull fired events from your subscription feed' with specific verb and resource. It distinguishes from siblings like 'list_subscriptions' and 'subscribe/unsubscribe' by focusing on retrieving fired events rather than managing 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?

Description provides clear usage context: filtering by type and since, setting mark_read, and polling. It mentions an alternative access method (GET endpoint) for scripts and dashboards, but lacks explicit 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?

Beyond annotations (readOnlyHint, idempotentHint, etc.), the description details fan-out behavior, fallback logic, soft-fail for USPTO, relative date parsing, and return format.

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

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

The description is dense but well-structured, starting with query examples, then parallel call, parameters, return format, and sibling note. Every sentence adds value, though slightly long.

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, fallbacks, no output schema), the description is remarkably complete, covering behavior, parameters, and return structure.

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?

Adds meaning beyond schema: explains 'since' accepts ISO or relative shorthand with examples, and 'value' can be ticker or CIK. Schema coverage is 100%.

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

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

The description explicitly states it's a change feed for a company, lists sources (SEC EDGAR, GDELT→GNews, USPTO), and distinguishes from entity_profile. It provides clear query examples.

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

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

The description says when to use the tool (for 'what's new' queries) and explicitly recommends entity_profile for static profiles, providing a clear 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?

Description adds context beyond annotations: scoping by identifier, persistence for authenticated users, 24-hour retention for anonymous sessions. No contradiction with annotations (write, idempotent, non-destructive).

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

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

Single dense paragraph of 4 sentences, front-loaded with the purpose. Every sentence adds value with no redundancy.

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

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

Given the simple two-parameter tool, the description covers purpose, usage, behavioral details, and pairing with recall/forget. No missing information for agent invocation.

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

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

Schema covers both parameters fully (100% coverage). Description reinforces key-value nature and provides usage examples, but doesn't add significant new parameter-level 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?

Description clearly states the tool saves data for reuse later, specifying key-value pairs and scoping by identifier. It distinguishes from sibling tools by mentioning recall 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?

Explicitly says when to use: when discovering something worth carrying forward, with concrete examples like resolved ticker or user preference. Also clarifies authentication scoping and session duration.

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 annotations already mark the tool as read-only, open-world, idempotent, and non-destructive; the description adds significant behavioral detail beyond that: graceful degradation of LEI/FIGI enrichment, internal cascading through multiple lookup endpoints, source-labeling of identifiers, and explicit `unresolved` output rather than omission. No contradiction with annotations.

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

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

The description is front-loaded with examples and the 'Use FIRST' directive, and every block supports tool selection or correct invocation. However, it is dense and long, mixing multiple distinct behaviors into a single run-on passage, so it loses a point on structural readability.

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

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

With no output schema, the description adequately describes return contents: EDGAR identifiers, LEI and ownership data, FIGI, RxCUI with citation, and the `unresoved` field. It also covers failure modes and input edge cases, so an agent has everything necessary to call and interpret this tool correctly.

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

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

Even though schema coverage is 100%, the description substantially extends the schema's paramter descriptions: it specifies accepted forms (ticker, CIK, ISIN, name), clarifies that the value must be the entity name only and not a full noun phrase, gives bond-issuer examples, and explains ISIN-to-legal-entity semantics. This is meaningful guidance beyond the structured schema.

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

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

The description names its specific action ('resolve a user-spoken NAME to canonical/official identifiers') and provides concrete example queries ('ticker', 'CIK', 'LEI', 'RxCUI'). It also positions itself as the first tool to use when a name needs to become an ID, distinguishing it from sibling tools that consume IDs (entity_profile, compare_entities) without naming them.

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

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

Offers explicit when-to-use guidance: 'Use FIRST whenever you have a name but need an ID.' It also enumerates supported types and input formats, making the activation condition clear. It does not explicitly name alternatives or give when-not-to-use conditions, so it misses the top tier.

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 that it probes with ai_visibility_check and returns a ranked list with score, confidence, and signal density, providing useful behavioral context 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?

The description is 4-5 sentences, front-loaded with the main action, and every sentence adds value with no redundancy.

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

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

Given the schema covers all parameters and the description explains the function, return format, and use case, the description is complete for this tool's complexity.

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

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

Schema coverage is 100%, so baseline is 3. The description adds the nuance that the first entity is treated as the subject, but other parameters are covered by the schema.

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

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

The description clearly states the tool compares AI visibility across multiple entities, uses ai_visibility_check, ranks by score, and surfaces most/least recognized. It distinguishes from siblings by specifying it is a composite comparison tool.

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

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

The description provides a use case ('competitive AI-marketing audits') and an example question, helping the agent decide when to use it. However, it does not explicitly mention when not to use or alternative tools.

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

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

The description adds behavioral context beyond annotations: it fans out to external services, partial failures degrade gracefully, and bundlephobia's first measurement can take 5-30s. Annotations already indicate read-only, idempotent, and non-destructive behavior, which the description does not contradict.

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 informative but somewhat lengthy. However, every sentence adds useful detail about the composite nature, services, use cases, ecosystem scope, and edge cases. It is well-structured with front-loaded 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?

Given the complexity of the tool (two external sources, multiple output fields) and the absence of an output schema, the description thoroughly explains what is returned (summary block, advisories, links, alternative versions) and handles edge cases like delays and failures.

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

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

The input schema already provides clear descriptions for both parameters, achieving 100% coverage. The description confirms that scoped packages are accepted and that version defaults to latest, adding minor value but not essential.

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

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

The description clearly states the tool's purpose: a composite check for evaluating npm packages using deps.dev and bundlephobia. It uses specific verbs ('scan', 'fans out') and lists the exact data provided, distinguishing it from sibling tools that address different domains.

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

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

The description explicitly says when to use the tool: when an agent asks if a package is 'safe / popular / small' or what it costs. It also specifies that it's npm-only in v1, pointing to alternative tools for other ecosystems, and describes graceful degradation for partial failures.

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

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

Adds significant behavioral details beyond annotations: uses BGE-base-en embeddings + cosine over 500-char overlapping windows, caps input at 200K chars with truncation and flagging, and includes character offsets for verification. 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 concise, front-loaded with purpose, followed by use case and technical details. Every sentence adds value, no fluff.

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

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

Despite no output schema, the description explains what is returned (passages with offsets and scores), covers edge cases (truncation), and mentions integration with sibling tool. Complete for the tool's complexity.

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

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

Schema already describes all parameters well (100% coverage). Description adds no new parameter-level meaning; the extra context about embedding and windowing is behavioral, not parameter-specific. Baseline 3 is appropriate.

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

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

The description clearly states it performs semantic search inside a fetched record, specifying the use case (when record is too large for prompt) and output (passages with offsets and scores). It distinguishes from siblings by mentioning pairing with ask_pipeworx_grounded.

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

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

Explicitly says when to use: 'when the record is too big to cram into the prompt'. Provides context on pairing with ask_pipeworx_grounded and mentions input cap (200K chars) and truncation flag.

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?

Exceeds annotations: details OAuth requirement, type-specific parameter formats, delivery channel behaviors (feed always on, email/SMS optional, webhook with signing secret and auto-disable after 10 failures). Annotations only indicate idempotent, non-destructive, open world.

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?

Dense but well-organized: purpose first, then type list with examples, then delivery channels. Every sentence adds value; no fluff. Slightly long 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?

Complete for a creation tool: covers return value (subscription id), types, parameters, delivery channels, auth requirements, and limits (10 SMS/day). No output schema, but description sufficiently documents what is returned.

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

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

Schema coverage is 100%, but description adds extensive examples for each type (e.g., sec_8k items, polymarket_edge topic), constraint details (phone verification, webhook restrictions), and clarifies delivery schema beyond what JSON 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?

Clear verb 'Create' and resource 'proactive monitoring subscription' immediately in first sentence. Returns subscription id. Distinguishes from siblings like list_subscriptions and unsubscribe.

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

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

States when to use (creating new subscription) and lists prerequisites (OAuth account for persistence, phone verification for SMS). No explicit exclusion for duplicate subscriptions, but idempotent annotation suggests safe re-call.

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

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

Annotations already indicate readOnly, openWorld, idempotent, and non-destructive behavior. The description adds valuable context: it returns category-bucketed examples with tool+argument shape, drawn from a live catalog. 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 front-loaded with key phrases and examples. It is slightly verbose (multiple clauses and lists), but every sentence adds value. Could be tightened slightly, but structure is clear.

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

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

For a simple, single-parameter discovery tool with no output schema, the description fully explains what to expect (categorized examples with tool calls) and when to use it. 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 covers 100% of parameters with a description for 'topic'. The description adds context on usage: 'call with no arguments for full spread, or pass topic to focus', which provides meaningful guidance 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 is the onboarding entry point that returns categorized example questions with tool calls. It uses specific verbs like 'returns' and 'use this FIRST', and distinguishes itself from siblings like 'ask_pipeworx' and 'discover_tools' by being the initial exploration tool.

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

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

The description explicitly says 'Use this FIRST when you do not yet know what Pipeworx can do for you' and provides example queries. It gives clear context but does not include explicit when-not-to-use or alternatives beyond mentioning meta-tools.

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

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

Discloses important behavioral details beyond annotations: ownership enforcement, deactivation instead of deletion, and that historical events remain accessible via recent_alerts. Aligns with annotations (readOnlyHint=false, destructiveHint=false) and 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?

Two sentences, front-loaded with core action, followed by key constraints and side effects. No redundant or vague phrasing.

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

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

For a simple tool with one parameter and no output schema, the description covers purpose, usage constraints, and side effects comprehensively. Minor omission: no mention of error behavior or return value, but still adequate.

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

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

Schema coverage is 100% with a single parameter 'id' described as 'Subscription id (uuid) returned by subscribe.' The description does not add additional parameter semantics beyond what the schema provides, so baseline 3 is appropriate.

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

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

Clearly states 'Cancel a subscription by id' with verb and resource. Differentiates from sibling tools like subscribe, list_subscriptions, and recent_alerts by specifying cancellation and ownership enforcement.

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

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

Provides explicit ownership constraint ('you can only cancel your own subscriptions'), clarifying appropriate use. Does not explicitly state when not to use or compare to alternatives, but context is clear enough for decision-making.

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

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

Beyond the annotations (read-only, idempotent, open-world), the description adds critical behavioral details: the two pipeline paths (SEC EDGAR/XBRL vs. grounded), the exact verdict list, the meaning of 'could_not_verify' (not evidence) vs. 'unsupported', and the citation format. This is extensive and highly valuable context not inferable from annotations.

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

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

Though lengthy, every sentence serves a purpose: trigger phrases, usage guidance, pipeline explanation, return value specification, and crucial caveats. The structure is front-loaded and logically ordered, with no fluff or redundancy.

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

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

With no output schema, the description must explain return values and does so thoroughly, including all verdicts, the actual value with citation, reasoning, and error semantics. It also covers the two distinct execution paths and the efficiency benefit, making the description self-sufficient for a tool of this complexity.

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

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

Schema coverage is 100%, with both parameters (claim and tolerance_pct) already fully described in the input schema. The description does not add significant parameter-level meaning beyond what the schema provides, so it stays at the baseline of 3.

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

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

The description clearly states the tool's purpose: natural-language claim verification against authoritative sources. It includes trigger phrases and specific verb+resource framing ('verify the claim that…'). It differentiates from sibling tools by focusing on fact-checking with structured verdicts and by mentioning 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 provides explicit when-to-use guidance: 'Use whenever the agent needs to check whether something a user said is factually correct.' It also explains the routing for company-financial vs. other claims. However, it does not explicitly list when-not-to-use or name alternative sibling tools, so it falls short of a 5.

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