Shopify

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds behavioral details: default free model, BYO key for Anthropic, per-model return structure, and combined view. No contradictions.

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

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

Two concise sentences with no fluff. First sentence captures core purpose and output; second provides key operational detail (default model, key usage, return structure). Every sentence earns its place.

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

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

Despite no output schema, the description explains the return format (per-model score, confidence, signals, raw_response + combined view). Parameters are fully described. The tool is self-contained for its complexity.

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

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

Schema coverage is 100% with descriptions for all 4 parameters. The description adds meaning beyond the schema (e.g., default model, free tier, context disambiguation). Agents gain actionable guidance.

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

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

The description uses a specific verb ('probe'), identifies the resource ('LLMs'), and specifies the output ('score visibility 0-100 per model'). It clearly distinguishes from siblings like entity_profile or scan_competitor_ai_presence by focusing on AI model knowledge scoring.

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 states use cases ('AI-marketing audits, pre-launch brand checks, competitive monitoring') but lacks explicit when-not-to-use or alternative tool references. Siblings exist (e.g., entity_profile) but are not mentioned.

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

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

Annotations already indicate read-only, open-world, idempotent, and non-destructive behavior. The description adds meaningful context beyond those flags: it routes questions to one of 5,596 tools across verified sources, automatically fills arguments, and returns structured answers with stable pipeworx:// citation URIs. This tells the agent what an invocation actually does and what to expect.

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

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

The description is longer than average but front-loads the most critical instruction — prefer this over web search — and then earns its length with domain scope, trigger phrases, examples, and explicit alternative tools. Minor redundancy remains, such as listing multiple overlapping trigger examples, but the structure is clear and usable.

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

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

For a tool with no output schema, the description covers what the agent needs: when to use it, how to phrase input, what data types it supports, what it does internally, and what kind of answer is returned (structured with citations). It also clarifies boundaries versus sibling tools.

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

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

Schema coverage is 100% with aliases fully documented, so the schema carries the burden of parameter understanding. The description adds examples and clarifies the plain-language nature of the input, but it does not materially deepen the meaning of the 'question' parameter beyond the schema description.

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

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

The description clearly identifies the tool as a router for natural-language factual questions, explicitly naming the domains it covers (SEC filings, FDA data, economic statistics, patents, real estate, news, stocks, etc.) and the type of answer it returns. It also differentiates itself from web search and sibling tools like ask_pipeworx_grounded and deep_research.

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

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

Provides strong when-to-use guidance: 'PREFER OVER WEB SEARCH', trigger phrases such as 'what is', 'look up', 'find', 'get the latest', and concrete examples. It also names alternatives for grounded answers and multi-topic deep research, so the agent knows when not to use this tool.

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

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

The description adds meaningful behavioral context beyond the readOnlyHint annotations: it is an experimental edge, candidates are only active during tests, the last candidate was retired on a specific date, and it currently matches ask_pipeworx exactly. It also clarifies that it is not a degraded fallback path but a full working router, which is valuable for invoking agent.

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 three-sentence, front-loaded paragraph with no redundant filler. Each sentence earns its place: one defines the tool, one explains the current live state, and one gives explicit usage guidance.

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

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

The description is enough to invoke the tool correctly given the schema and annotations. It covers the beta/experimental nature, alias behavior, and exact no-fallback guarantee. A small gap is that no output schema exists and the 'same response shape' claim relies on the agent understanding ask_pipeworx, but the description is otherwise reasonably complete and exceptional.

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 effectively 100%, with all parameters described as aliases for question or the question itself. The description adds nothing beyond what the schema already provides; it merely confirms those aliases rather than disambiguating them further, so a baseline 3 is appropriate.

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

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

The description clearly identifies this as the experimental beta of ask_pipeworx, a universal router backed by 5,596 tools and the same request/response contract. It distinguishes from the stable ask_pipeworx by noting it carries candidate routing improvements, though the core end-user behavior is expressed mainly through the ask_pipeworx comparison rather than a standalone definition.

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 states when to use it: when wanting the newest routing, and that it should be used exactly like ask_pipeworx. It also explains the current no-candidate state, which helps the caller decide whether it matters. It does not explicitly contrast with alternatives like ask_pipeworx_grounded, but the main beta-vs-stable choice is covered.

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

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

Annotations already mark the tool read-only, idempotent, and non-destructive, and the description adds substantial behavioral disclosure: it returns a structured {answer, evidence, confidence, source, fetched_at, refusal_reason} contract, covers refusal reasons like not_in_source and data_truncated, and mentions the extra LLM call cost. This goes far beyond the annotation surface and gives the agent realistic expectations for tool behavior.

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

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

The description is structured into three dense but purposeful sentences: first defines the behavior, second outlines the return and refusal contract, third states usage guidance and cost trade-off. Every sentence carries necessary information and the key differentiators are front-loaded.

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

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

There is no output schema, so the description compensates by fully specifying return shape, refusal reasons, and the conditions under which a refusal occurs. Combined with read-only and idempotent annotations, this gives an agent everything needed to select, invoke, and interpret the tool's result correctly.

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

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

The schema description coverage is 100%, as each parameter is already documented as a natural-language question alias. The description does not add additional parameter semantics or syntax details, so the baseline 3 applies: the schema's high coverage does the work and the description adds no extra parameter 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 specifies a concrete purpose: a hallucination-resistant answer mode that extracts answers only from fetched source data. It clearly differentiates itself from the sibling ask_pipeworx by describing the grounded extraction behavior and explicit refusal handling, so an agent can tell them apart without reading schemas.

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 ('whenever an answer will be quoted, cited, or acted on', 'must not invent facts') and when not to use it ('prefer ask_pipeworx for casual lookups'), including the cost trade-off. This gives clear routing guidance with no need for inference.

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 consistent (read-only, non-destructive). Description adds extensive behavioral details: resolution process, fan-out logic, market-match confidence, parent event extraction, news fallback, safety mechanisms, closed market handling, wide spread warnings, and resolution rule 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?

Long but each sentence is informative. Front-loaded with purpose, then details. Could be more structured with subheadings, but no redundant text. Efficient for the complexity.

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

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

Covers all major aspects: inputs, resolution, fan-out, response shapes, match confidence, parent events, news fields, safety, closed markets, wide spreads, cancellation rules. No output schema but response shapes described in detail.

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 context: what depth does (quick vs thorough), market can be slug/URL/text, include_raw effect and when to use. Examples provided. Adds significant value beyond schema.

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

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

Clearly states it researches Polymarket bets by pulling Pipeworx data. Describes inputs (slug, URL, question text) and outputs (evidence packet, market-vs-model comparison). Distinguishes from siblings by focusing on research rather than edges or arbitrage.

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

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

Explicitly says 'Use for should I bet on X, what does the data say about Y, or is there edge in Z.' Provides classifiers and fan-out examples. Does not explicitly compare with alternative tools, but usage 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 declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. The description adds specific behavioral details: pulls latest 10-K from SEC EDGAR/XBRL (with off-calendar handling), sorts results by primary metric, returns paired data with citation URIs, and replaces multiple sequential lookups. 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 longer but front-loaded with example user queries and structured with clear details. Every sentence adds value, and it's organized logically. Could be slightly more concise, but overall efficient.

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

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

Given the high annotation coverage (readOnlyHint, openWorldHint, idempotentHint) and full schema parameter descriptions, the description is very complete. It explains behavior for both entity types, sorting, citation URIs, and performance benefits, leaving no significant gaps.

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

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

Schema coverage is 100% with both parameters described. The description adds value by clarifying that 'values' for company are tickers/CIKs and for drug are names, with examples. It also mentions sorting by primary metric, which provides context 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 it does side-by-side comparison of 2–5 entities (companies or drugs) in a single call. It includes example user queries ('X vs Y', 'which is bigger') and specifies the data sources for each type, distinguishing it from 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 instructs to always prefer this tool over sequential single-pack lookups, and provides context for when to use (comparison, ranking, head-to-head). While it doesn't state when not to use, the purpose is clear enough to avoid misuse.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds substantial behavioral context beyond that: it discloses latency expectations (15-60s, up to ~90s), the multi-hop internal behavior, gap[] and contradictions[] outputs, the rule that citations are only included when resolvable, and semantics of semantic excerpting. This goes beyond the annotations without contradicting them.

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

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

The description is quite long and covers many behavioral details (latency, citation semantics, excerpting) plus routing guidance. While most sentences are informative, the structure buries the headline use-case (grounded parallel research vs open-web search) in the middle, and the parenthetical formats ('(never invented)', 'not head-truncated') add slight verbosity. It earns marks for front-loading the account requirement and the key caveat, but it is long enough that an agent must parse a lot to extract the core decision rule.

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

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

The description covers the critical operational context: account/auth requirements, what inputs to provide, what outputs to expect (findings packet: evidence, confidence, source, fetched_at, citation_uri, gaps, contradictions), limitations (not a search for arbitrary text; only structured sources), latency expectations, and the alternative routing. Given no output_schema exists, the description carries the full burden of describing return shape and semantics, and it does so thoroughly.

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

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

Schema description coverage is 100% and both parameters have meaningfully detailed schema descriptions (depth enumerations and question guidance). The description adds additional semantic value over the schema by explaining the trade-offs of 'standard' vs 'thorough' in terms of hops and contradiction scans, and by clarifying that 'quick' is single-hop. The parameter descriptions plus the description text together are nearly complete.

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 identifies a specific verb (research/decompose/route) and resource (Pipeworx's 1,465 structured data sources) and clearly contrasts itself with open-web search and single-lookup alternatives. It provides concrete example questions, so an agent can determine when this tool is the right fit among 35+ siblings.

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

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

The description explicitly states when to use this tool vs ask_pipeworx: 'for a single lookup use ask_pipeworx instead', and mentions the account requirement as a routing condition. It also gives example question shapes ('broad/multi-part questions over structured data') and excludes open-web search, making the decision boundary 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?

Description adds that results include full input schemas with examples and are ready to call directly. Annotations already declare readOnlyHint, idempotentHint, destructiveHint, so description provides behavioral context beyond that.

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

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

Description is front-loaded with purpose and examples. Every sentence is useful, though a bit lengthy for a tool description. Could be slightly tighter.

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 explains output contents (names, descriptions, schemas) and when to use. Complete for a discovery tool with good annotations.

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 3. Description gives example queries and mentions aliases for query, but does not add deep semantics beyond schema.

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

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

Clearly states the tool finds tools by describing data or task. Lists many example domains (SEC filings, FDA drugs, etc.) and distinguishes from siblings by being a discovery/browsing 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?

Explicitly says 'Call this FIRST when you have many tools available and want to see the option set.' Implies when to use vs alternatives, though could mention exclusions more directly.

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 and idempotentHint; description adds details about fanning across multiple sources, specific return fields, and a note about patents API soft-failing. This enriches transparency beyond annotations.

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

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

Description is front-loaded with examples and then provides structured detail. Every sentence adds value 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?

No output schema exists, but description thoroughly explains return fields (CIK, filings, fundamentals, patents, news, LEI) and data sources. This is complete for a profiling 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 baseline is 3. Description adds examples, clarifies type is only 'company', and explains value must be ticker or CIK. This adds meaningful extra 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 the tool's purpose: 'full cross-source profile of a US public company in ONE parallel call.' It lists specific data sources and distinguishes it from siblings like resolve_entity and compare_entities.

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

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

Explicitly states 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups' and notes names are not supported, directing users to use resolve_entity first. This provides clear when-to-use and alternatives.

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

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

Annotations provide destructiveHint=true and idempotentHint=true. Description restates the delete action but adds no new behavioral details.

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

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

Two sentences with no waste, front-loaded with key action and context.

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

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

Tool is simple with one param and no output schema. Description covers purpose, usage guidelines, and sibling relationships adequately.

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

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

Input schema covers parameter fully (100% coverage). Description adds no extra meaning beyond what 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?

Description uses specific verb 'Delete' and resource 'previously stored memory by key', clearly distinguishing it from siblings 'remember' and 'recall'.

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

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

Explicitly states when to use: stale context, task completion, clearing sensitive data. Mentions pairing with siblings, though lacks explicit when-not guidance.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds behavioral details: fetches page, extracts title/description/key links, outputs markdown blob. Does not contradict annotations, but lacks error handling or rate limit info.

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

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

The description is three well-structured sentences, front-loaded with purpose, then details, then use cases. No redundant information; 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 the tool's simplicity (2 params, no output schema), the description covers generation purpose, input expectations, output format, and use cases. Missing error/edge case behavior (e.g., unreachable URL) but adequate for typical use.

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

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

Schema description coverage is 100%, so the schema already explains both parameters. The description adds minor context (e.g., 'Full URL' and default/max for max_links), but does not significantly extend beyond schema.

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

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

The description explicitly states the verb 'generate' and the resource 'llms.txt file', specifies the action of fetching, extracting, and emitting standard format, and clearly distinguishes from sibling tools, none of which generate llms.txt files.

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

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

The description provides clear use cases (client indexing, personal projects, competitor auditing) but does not mention when not to use it or contrast with alternatives like ai_visibility_check or scan_competitor_ai_presence.

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=true, destructiveHint=false, idempotentHint=true. The description adds return fields and the effect of the include_inactive parameter, but does not disclose additional behavioral traits beyond what annotations imply.

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, no fluff. The most critical information (lists subscriptions, return fields, usage purpose) is front-loaded.

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

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

Given the low complexity (single optional parameter, no output schema but described return fields) and rich annotations, the description is fully 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%, and the parameter include_inactive is already well-described in the schema. The description adds no extra semantic value for the 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 lists the caller's active subscriptions with specific return fields (id, type, etc.). It distinguishes well from siblings like subscribe and unsubscribe.

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

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

Explicit guidance: 'Use this to review what you're monitoring before adding more or to find an id to cancel.' Tells when and why to use it.

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

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

Annotations provide no hints (all false), so the description carries full burden. It discloses the claim_token return mechanism, rate limits ('Rate-limited to 5 per identifier per day'), cost ('Free; doesn't count against your tool-call quota'), and operational details ('The team reads digests daily'). This goes well beyond a simple send-feedback tool.

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

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

The description is longer than average but every sentence contributes: purpose, when-to-use, scope limitation, claim token, processing, rate limit, and cost. It is front-loaded with the main action and logically organized, though it could be slightly tightened without losing information.

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

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

With no output schema, the description explains the primary return behavior (claim_token) and the later polling mechanism. It covers rate limiting and scope. It does not fully specify error handling or success messages, but for a feedback submission tool the provided details are 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%, so baseline is 3. The description adds meaningful context for the claim_token parameter by explaining how to use it to check status: 'pass it back later as pipeworx_feedback({claim_token:"pwfb_…"}).' It also reinforces the message field guidance ('don't paste the end-user's prompt'). 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?

The description opens with 'Tell the Pipeworx team something is broken, missing, or needs to exist,' which is a specific verb+resource statement. It clearly differentiates this tool from siblings by focusing on feedback for Pipeworx tools, not on research or data queries. The explicit mention of bug/feature/praise categories further clarifies its purpose.

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 it: 'Use when a tool returns wrong/stale data (bug), when a tool you wish existed isn't in the catalog (feature/data_gap), or when something worked surprisingly well (praise).' It also provides an exclusion and alternative: for non-Pipeworx MCP servers, 'file it with that server instead.' This is model usage guidance.

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

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

Annotations already state readOnly, openWorld, idempotent, not destructive. The description adds valuable context: data is self-aggregating from CF analytics-engine, no PII, cached 5min-1h. 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, well-structured with bullet points for use cases, and front-loaded with the core functionality. 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?

For a simple tool with one parameter and no output schema, the description covers purpose, use cases, data source, privacy, caching, and window semantics. It is fully complete given 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?

The schema already covers the single parameter 'window' with enum and description (100% coverage). The description adds semantic nuance about short vs long windows and default value, providing 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 returns top tools, top packs, and total call volume over a recent window. It uses specific verbs and resource references, and the purpose is distinct from sibling tools like discover_tools or ask_pipeworx.

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

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

The description explicitly lists three concrete use cases: discovering hot data sources, confirming canonical tool choice, and aligning use cases. It also explains caching behavior. It lacks explicit when-not-to-use or alternatives, but the context is clear enough.

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

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds significant behavioral detail: internal checks (monotonicity, partition-sum, semantic anchor, partition filter, fill check) and response structure. No contradictions with annotations.

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

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

The description is thorough and well-structured with paragraphs for each mode and additional details. However, it is somewhat verbose (multiple complex sentences). It front-loads the core purpose and efficiently conveys the necessary 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?

With no output schema, the description fully explains the response structure (opportunities[], partition_check details, fill check). It covers all usage scenarios, parameters, and internal logic. Sibling tools provide relevant context for comparison. The description is 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?

Both parameters have schema descriptions (100% coverage), and the description enriches them with usage context, example values, and behavioral implications (e.g., recommended mode, cross-event logic). The description adds meaning beyond the schema's basic definitions.

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

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

The description clearly identifies the tool as finding arbitrage opportunities on Polymarket via monotonicity violations and partition-sum checks. It distinguishes between two modes (event and topic) and contrasts with sibling tools like polymarket_edges and polymarket_fill_risk.

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

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

The description explains when to use each argument: no args for trending scan, `event` for a specific market, `topic` for cross-event scanning. It recommends event mode and provides context on cross-event mode catching patterns missed by single-event. It does not explicitly state when not to use, but the guidance is clear and practical.

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 extensive behavioral context: three model families, caching, diagnostics, tradeable-edge knobs, and a 24h-move warning. 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 the main purpose and well-structured with clear sections. However, it is verbose with detailed model family explanations, which could be condensed for an AI agent.

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 return structure (by_segment, fed_candidates, _diagnostics) and the per-opportunity fields. It also covers caching, knobs, and edge cases like the Fed note. Extremely complete.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaningful context beyond schema descriptions, such as explaining 'Tradeable-edge filter' for max_spread_pp and min_liquidity, and the relationship between min_kelly and min_partition_leg_kelly.

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 scans Polymarket markets for opportunities where Pipeworx data disagrees with market price, using specific verbs and resource. It distinguishes itself from sibling tools like polymarket_edge_tracker by focusing on top markets and multiple model families.

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

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

The description explicitly says 'Built for "what should I bet on today"' and mentions agents discover opportunities without paging hundreds of markets. It does not provide explicit when-not-to-use or alternatives, but the context is clear.

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

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

The description adds significant behavioral context beyond the annotations: decay computed on daily closes (not intraday), history bounded by 60-day TTL, and gaps indicate no scan. Annotations already indicate read-only and idempotent operations.

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 fairly long but well-structured with sections (ARGS, RESPONSE, LIMITS). Some redundancy in listing response fields, but overall 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?

Without an output schema, the description fully compensates by detailing the response structure: tracked[], expired[], snapshot_dates[]. It also covers limitations and edge cases, making the tool's behavior complete for an agent.

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

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

Schema coverage is 100%, and the description adds value by specifying defaults (days=14, window='1wk'), clamps (days 2-30), and explaining window as a snapshot family. This goes beyond the schema descriptions.

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

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

The description clearly states the tool's purpose: providing edge persistence and decay telemetry to answer 'how long has this edge existed and is it shrinking?'. It distinguishes from the sibling polymarket_edges tool by being a derived analysis tool built from 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 gives clear context for when to use: when needing to differentiate between fresh and old edges. It provides default parameter values and clamping behavior. However, it does not explicitly contrast with siblings 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 provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds substantial behavioral context: it walks the order-book ladder, returns specific fields like slippage_pp, verdict, thin_legs, and forced_directional_risk. It also warns about partial basket fills causing directional exposure. No contradiction with annotations.

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

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

The description is verbose but well-structured with clear mode sections. It front-loads the purpose and uses imperative language ('REQUIRES', 'USE THIS'). Minor redundancy (e.g., stating 'SINGLE-MARKET' and 'BASKET' separately) could be trimmed, but overall acceptable for the complexity.

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

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

Given no output schema, the description fully enumerates return fields for both modes: top_of_book, vwap_fill_price, slippage_pp, shares_filled, max_fillable_usd, verdict for single-market; theoretical_sum, realizable_sum, capture_ratio, profit_usd, per-leg fill detail, thin_legs, max_clean_notional_usd, forced_directional_risk. It also explains the risk scenario, making it self-contained.

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

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

Schema description coverage is 100%, but the description adds meaning beyond schema: it explains the dual interpretation of size_usd (spend for buys, target proceeds for sells; for basket, settlement notional), default behavior for side in basket mode ('auto from partition sum'), and valid range (clamp 10–1,000,000). This enriches the agent's understanding.

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

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

The description clearly states the core function: 'Realizable-vs-theoretical edge check against live CLOB order-book depth.' It distinguishes between single-market and basket modes with specific syntax and examples, making it unambiguous. It also differentiates from sibling tools like polymarket_arbitrage and polymarket_edges by specifying when to use this one.

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 instructs 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500.' It explains the rationale ('theoretical overround on thin books is not capturable, and partial basket fills convert an arb into an unhedged directional position'), providing clear when-to-use and when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint true and destructiveHint false, but the description adds extensive behavioral context: safety fields (compatibility_warning, temporal_alignment, skipped counters), the meaning of zero matched pairs, and when spreads are mathematically meaningless. No contradiction with annotations. This exceeds what annotations provide.

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

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

The description is relatively long but efficient, front-loading the core purpose. Every sentence adds value, explaining modes, safety fields, and caveats. Minor redundancy (e.g., repeating 'pre-mapped' multiple times) could be trimmed, but overall it's well-structured for the complexity.

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

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

Given the complexity and lack of an output schema, the description covers response structure (leg prices, spread, compatibility_warning, temporal_alignment, skipped counters) sufficiently. It could be more explicit about the exact JSON format, but it provides necessary details for an agent to interpret results correctly.

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

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

Schema coverage is 100%, so all three parameters are documented. The description adds meaning by listing the 10 pre-mapped topic shortcuts and explaining how explicit parameters override mapped values. It also notes that pre-mapped topics are not necessarily tradeable, adding context beyond the schema.

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

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

The description clearly states the tool's core function: 'Cross-venue spread between Kalshi and Polymarket for the same resolving question.' It explains the two modes (topic shortcuts and explicit ticker/slug) and distinguishes itself from sibling tools like polymarket_arbitrage by focusing on cross-venue comparison between Kalshi and Polymarket.

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 guidance on when the spread is meaningful (equivalent bet shapes) and warns that most pre-mapped topics return compatibility warnings. It explains the two modes but does not explicitly mention alternatives among siblings or state when not to use the tool. Still, it gives sufficient context for appropriate use.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint; description adds scoping per identifier and pairing with other tools. No contradiction. Adds meaningful behavioral 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?

Three sentences, no fluff. First sentence states primary action and alternative, second gives use cases, third covers scoping and tool pairing. Every sentence adds essential 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?

With a simple tool (one optional param, no output schema), the description covers all needed aspects: what it does, how to use (with/without key), when to use, and how it relates to other tools. Complete and sufficient.

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

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

Schema coverage is 100% with a description for the single optional parameter. Description adds value by explaining that omitting key lists all keys and provides examples of typical keys (ticker, address), which goes beyond the schema's generic description.

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

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

Description clearly states it retrieves previously saved values or lists all keys, with specific verb-resource pairing (retrieve memory, list all keys). It distinguishes itself from sibling tools remember and forget by explicitly naming them and describing the relationship.

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

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

Provides clear when-to-use guidance: looking up context stored earlier (ticker, address, notes). Explicitly pairs with remember and forget. Does not specify when not to use, but the context is sufficient for an agent to decide.

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 contradicts annotations: readOnlyHint=true but mark_read parameter modifies state by flagging events as read. This is a serious inconsistency that undermines transparency.

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

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

Single paragraph, front-loaded with purpose. Every sentence adds value, but slight room for tighter 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?

No output schema, but description details return fields (source, citation_uri, payload) and explains parameter behavior. Adequately covers complexity of 5 optional parameters.

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 by explaining filtering with type and since, and the side effect of mark_read. Schema coverage is 100%, but description enriches understanding.

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

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

The description clearly states the tool pulls fired events from a subscription feed, using specific verbs and specifying the resource. It distinguishes from sibling tools like list_subscriptions which list subscriptions themselves.

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

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

Provides clear context for use, including that polling works and an alternative REST endpoint. Lacks explicit comparison to all sibling tools but gives practical advice.

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 discloses fallback behavior (GDELT preferred, GNews on rate limits), USPTO soft-failure, and that results include structured changes with citations. 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 that front-loads example prompts, explains functionality, then details parameters and alternatives. Every sentence adds value; no waste.

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

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

Despite no output schema, the description explains the return format (structured changes with citations and total count). It covers input, behavior, fallbacks, and provides an alternative 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?

While schema coverage is 100%, the description adds meaningful context: examples for 'since', clarification for 'value' (ticker or CIK), and confirmation that 'type' only supports 'company'. This enhances understanding beyond the schema.

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

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

The description clearly states the tool provides a change feed for a company, using example queries like 'What's new with X' and specifying it fans out to multiple sources. It distinguishes from sibling tool 'entity_profile' by advising to use that for static profiles.

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

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

The description explicitly tells when to use the tool (e.g., queries about updates, latest changes) and when not to (use entity_profile for static profiles). It also explains the fallback mechanism for GDELT/GNews and the format for the 'since' parameter, providing clear context.

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

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

The description adds significant behavioral context beyond the annotations: scoping by identifier, persistent vs. 24-hour retention based on authentication, and pairing with recall/forget. No contradictions with annotations.

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

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

The description is concise at three sentences, each earning its place: purpose, usage guidance, and behavioral details. Front-loaded with the primary action.

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

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

For a tool with 2 required parameters, full schema coverage, no output schema, and clear sibling relationships, the description fully covers what the agent needs to know: purpose, when to use, and behavioral nuances.

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

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

Schema coverage is 100% with clear descriptions for key and value. The description adds examples of key patterns and value types, but does not substantially extend the meaning beyond well-described schema parameters.

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

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

The description clearly states the tool's purpose: 'Save data the agent will need to reuse later'. It specifies the resource (key-value pairs) and the verb (save), and distinguishes from sibling tools like recall and forget by mentioning their pairing.

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

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

The description provides explicit guidance on when to use: 'Use when you discover something worth carrying forward'. It also mentions pairing with recall and forget, but does not explicitly state when not to use, though the purpose is clear from the context.

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

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

Beyond the readOnly/idempotent hints, the description discloses valuable behavioral details: graceful degradation (if GLEIF/OpenFIGI unavailable, EDGAR results still return), explicit reporting of unresolved identifiers rather than omission, and source labeling for every identifier. These add significant context that annotations do not cover, making behavior predictable for the agent.

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 appropriately detailed for a complex tool with two entity types and multiple identifier sources. It is front-loaded with user query examples and the core purpose, then progressively elaborates. Some redundancy exists (e.g., repeating 'accepts ticker, CIK, ISIN' later), and the single dense paragraph could be better structured with line breaks, but overall every sentence contributes functional information.

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

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

Given there is no output schema, the description carries the burden of explaining return behavior. It covers key outputs (identifiers, sources, unresolved list, ownership data, drug citations) and mentions degradation/resolution logic. However, it does not describe the exact output structure (e.g., field names or nesting), which could leave some ambiguity for the agent. For a tool this rich, a bit more structural detail would be warranted, hence a 4 rather than 5.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning beyond the schema by introducing ISIN as an accepted input format (which the schema's parameter description omits), and explains how ISIN maps to legal entity. It also clarifies CIK formatting with leading zeros. This extra parameter nuance justifies a score above baseline.

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

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

The description clearly states the tool resolves user-spoken names to canonical/official identifiers, with specific examples like 'ticker for...' and 'CIK for...'. It distinguishes itself from siblings by explicitly noting it produces IDs that other tools require as input, and the supported types (company, drug) are enumerated. This is a clear, specific verb+resource pairing.

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

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

The description gives explicit guidance: 'Use FIRST whenever you have a name but need an ID.' This is a direct usage instruction. However, it does not explicitly contrast with sibling tools like entity_profile or compare_entities, nor does it state when NOT to use this tool. The guidance is clear but lacks explicit exclusions or named alternatives, which is why it stops short of a 5.

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

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

Annotations already provide readOnly, idempotent, openWorld hints. Description adds behavioral details: probes each entity with ai_visibility_check, ranks, returns ranked list with score, confidence, signal density. No contradictions.

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

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

Two sentences, front-loaded with purpose, no wasted words. Perfectly concise.

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

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

No output schema, but description details return structure (ranked list with score, confidence, signal density). All parameters explained via schema and description. 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%, but description adds value by explaining first entity as 'subject' and context as disambiguator, beyond what 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?

Clearly states it compares AI visibility across multiple entities, probes each, ranks by score, and surfaces most/least recognized. Distinguished from sibling 'ai_visibility_check' by emphasizing batch comparison and ranking.

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 use case: competitive AI-marketing audits, with example question. Provides context but does not list exclusions or alternatives beyond the implicit distinction from single-probe 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 the tool safe and idempotent; the description adds critical behavioral details: composite fan-out, partial failure with graceful degradation, 5-30s delay for first bundlephobia measurement, and sources_failed listing. No contradiction with annotations.

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

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

The description is a single dense paragraph with a clear, front-loaded purpose. Every sentence earns its place, though minor restructuring could improve readability. Approximately 150 words with no waste.

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 enumerates return fields, failure behavior, and constraints. It covers the tool's complexity adequately, ensuring an agent can confidently invoke and interpret results.

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

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

Input schema has 100% coverage with descriptions. The description adds value by clarifying scoped package acceptance and default version behavior. While schema already covers well, the description provides practical nuance.

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

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

The description clearly states the tool's purpose as a composite check for evaluating npm packages, listing specific data sources (deps.dev, bundlephobia) and the return summary block. It distinguishes from siblings by noting NPM-only scope and directing other ecosystems to a different 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?

Explicitly states when to use: when agent asks about safety, popularity, size, or cost of adding an npm package. Also provides exclusion criteria: non-NPM ecosystems go to deps.dev:version directly. Partial failure behavior is explained.

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 idempotent and read-only behavior. Description adds specific technical details: BGE-base embeddings, cosine similarity, 500-char windows, 200K char cap with truncation flag. No contradictions.

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

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

Concise and front-loaded with core purpose. Technical details are included but not overly verbose. Well-structured for agent comprehension.

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

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

Covers purpose, usage context, input parameters, technical behavior, limitations (truncation), and relationship to sibling tool. Sufficient for agent to use correctly without 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?

Schema coverage is 100%, so baseline 3 applies. Description reinforces inputs but adds minimal extra meaning beyond schema descriptions (e.g., max ~200K chars already in schema).

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

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

Clearly states semantic search inside a fetched record, returns top-N passages with offsets and scores. Differentiates from siblings by specifying pairing with ask_pipeworx_grounded and contrasting with other memory tools.

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

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

Explains when to use (record too big for prompt) and pairs with another tool. Lacks explicit exclusions or alternatives, but provides strong contextual guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so safety and idempotency are clear. The description adds value by specifying the exact fields returned (line items, customer info, fulfillment status, totals, shipping address) and that it uses the Admin API. No contradiction with annotations.

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

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

The description is a single sentence of 22 words, front-loaded with verb and resource, and contains zero filler. Every word 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?

For a simple fetch tool with 3 required parameters and an output schema (not shown but noted), the description sufficiently covers what the tool returns. No additional details are needed; it is 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 description coverage is 100%, with each parameter having a clear description. The description reinforces that 'id' is a numeric ID but adds no new semantic detail beyond the schema. Baseline score of 3 is appropriate given full 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 clearly states the action ('Fetch'), the resource ('a single Shopify order by numeric ID'), and explicitly lists returned data (line items, customer info, fulfillment status, totals, shipping address). It distinguishes from siblings like shopify_list_orders (list vs single) and shopify_get_product (different resource).

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 clear about what the tool does and implicitly when to use it (fetching a single order by ID). However, it does not explicitly state when not to use it or mention alternatives (e.g., shopify_list_orders for multiple orders). Still, the context makes usage straightforward.

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, destructiveHint, idempotentHint, and openWorldHint. The description adds that it uses the Admin API and lists returned fields, but does not disclose additional behavioral traits (e.g., rate limits, authentication details). The description does not contradict annotations.

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

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

Single sentence, front-loaded with action and expected results. No extraneous words, highly efficient.

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

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

Has output schema (referenced in context). Description covers the main returned fields. For a simple read tool with good annotations and full schema coverage, the description is adequately complete, though it could mention pagination or edge cases.

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

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

Schema coverage is 100% with clear parameter descriptions. The description mentions 'numeric ID' but adds minimal value beyond the schema (e.g., no further guidance on formatting or constraints). Baseline 3 applies due to high schema coverage.

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

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

The description clearly states the tool fetches a single Shopify product by numeric ID, specifying the returned fields (title, description, variants, pricing, inventory, images). It distinguishes from siblings like shopify_list_products (multiple products) and shopify_get_order (different resource).

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

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

No explicit when/when-not/alternatives are given. The description implies usage for fetching a single product, and sibling tool names (e.g., shopify_list_products) provide context, but no direct guidance on when to use this vs. alternatives.

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

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

Annotations declare readOnlyHint, idempotentHint, and destructiveHint false, indicating a safe, read-only operation. The description adds valuable behavioral context: the 250-per-call limit and the specific fields returned. It does not contradict 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, front-loaded with the main action and limit, followed by return fields and requirements. 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?

For a simple list tool with rich annotations and an output schema, the description is largely complete. It covers the action, constraints, return fields, and auth. A minor gap is lack of pagination details beyond the per-call limit, but this is acceptable given the tool's simplicity.

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

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

Schema coverage is 100%, so parameters are already well-documented. The description does not add new parameter details beyond restating requirements. It implicitly mentions the 'limit' parameter via the 250 cap, but no syntax or defaults.

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

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

The description clearly states the action ('list customers'), the resource ('customers in a Shopify store'), and includes specific constraints ('up to 250 per call') and return fields ('IDs, names, emails, order counts, and total spend'). This distinguishes it from sibling tools like shopify_list_orders and shopify_list_products.

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 specifies prerequisites ('Admin API access token and shop domain'), but does not explicitly compare with sibling tools or state when not to use it. However, the context of sibling names makes the usage clear enough.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety. The description adds no additional behavioral context (e.g., pagination, rate limits, or response structure beyond the output schema).

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 efficient sentence with no wasted words. However, it is very minimal and could benefit from additional context without losing conciseness.

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 100% schema coverage and an output schema present, the description is minimally adequate. However, it omits details on pagination, sorting, and handling of large result sets, which are important for a list 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 description coverage is 100%, so the schema already documents all parameters. The description reiterates the status filter but adds no new meaning beyond what is in the schema.

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

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

The description clearly states the verb 'List', the resource 'orders', and the scope 'from a Shopify store' with optional status filtering. It distinguishes from sibling tools like shopify_get_order and shopify_list_products.

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

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

No explicit guidance on when to use this tool versus alternatives. The purpose is implied by the name and description, but there is no mention of exclusions or when to use other tools like shopify_get_order for a single order.

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

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

Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description's only added behavioral information is the default limit of 50 products, which is already documented in the schema. It does not disclose ordering, rate limits, or response shape, so adds little 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?

The description is two sentences long, directly states the action and default behavior, and contains no redundant or irrelevant information. It is well-structured and front-loaded.

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

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

Given that an output schema exists, the description need not explain return values. It covers the essential purpose and default limit. However, it omits details on pagination beyond the limit parameter and any default ordering, which could be helpful for completeness in a list 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?

The input schema has 100% description coverage for all three parameters (_shop, limit, _apiKey). The description does not add any meaning beyond what the schema provides, so it meets the baseline without enhancing understanding.

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

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

The description clearly states the tool lists products from a Shopify store, which directly matches the name and title. It distinguishes itself from sibling tools like shopify_get_product (single product) and shopify_list_orders/list_customers by specifying the resource type.

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 no guidance on when to use this tool versus alternatives, such as shopify_get_product for single products or shopify_list_orders for orders. It does not mention limitations like pagination, filtering, or prerequisites beyond the required parameters.

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 states 'Create... Returns the new subscription id,' implying each call creates a new subscription. However, the annotation idempotentHint=true contradicts this, suggesting identical calls may not create multiple subscriptions. The description does not address idempotency or clarify the behavior. This is a direct 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 detailed but well-structured: it starts with the core purpose and return value, then lists prerequisites, supported types with examples, and delivery channel details. Every sentence provides specific information, though it is somewhat lengthy. It front-loads the most important information.

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

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

Given the tool's complexity (multiple types, optional delivery channels), the description covers the key aspects: what it does, required authentication, type-specific parameters, and delivery options with limitations. It does not cover error scenarios or idempotency, but overall it is fairly complete for a subscription creation tool.

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

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

Schema coverage is 100% with descriptions for all parameters. The description adds significant context beyond the schema, including concrete examples for each subscription type, constraints on delivery channels (e.g., SMS cap, phone verification, webhook signing), and clarifies parameter usage. This extra information is valuable for correct invocation.

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 'Create a proactive monitoring subscription to a live-data event stream. Returns the new subscription id.' This clearly states the action (create) and the resource (subscription to alerts). It distinguishes from sibling tools like list_subscriptions (list) and unsubscribe (remove).

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 create a subscription) and lists supported types with examples, but does not explicitly state when not to use it or compare with alternatives. It implies usage but lacks explicit guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds behavioral context: it returns category-bucketed examples with tool shapes, 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 information-dense but front-loads common queries and explains the output well. Slightly verbose but 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?

No output schema, but the description adequately describes the output structure (category-bucketed examples with tool shapes). Given the tool's role as an onboarding entry point, the coverage is sufficient.

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

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

The description enhances the schema's parameter definition by listing possible topic values and explaining the effect of omitting the parameter. Schema coverage is 100%, so baseline is 3, but the extra context justifies a 4.

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

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

The description clearly states the tool's purpose: returning category-bucketed example questions for onboarding. It specifies the categories and that it includes tool + argument shapes, distinguishing it from sibling tools like ask_pipeworx and entity_profile.

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

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

Explicitly advises to use this tool FIRST when the agent doesn't know what Pipeworx can do, or to learn how to call meta-tools. Also explains the optional topic parameter for focused queries.

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 no readOnly (write), idempotent, and non-destructive. The description adds key behavioral context: the row is deactivated not deleted, and historical events remain available via recent_alerts. This goes beyond annotations.

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

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

Three sentences, front-loaded with the primary action. No extraneous information. 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?

No output schema, but the description explains the effect (deactivation) and mentions historical data availability. For a simple one-parameter tool, this is sufficiently complete.

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

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

Schema description coverage is 100% for the single parameter 'id', so the baseline is 3. The description does not add extra meaning beyond the schema (e.g., format, example). No additional parameter context needed.

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

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

The description clearly states 'Cancel a subscription by id.' The verb 'Cancel' and resource 'subscription' are specific, and it distinguishes from sibling tools like 'subscribe' and 'list_subscriptions'.

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

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

Provides explicit guidance that ownership is enforced — 'you can only cancel your own subscriptions.' This helps the agent understand when it's appropriate to use the tool. Could mention when not to use, but the ownership constraint is clear.

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

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

The description goes well beyond annotations by disclosing the two processing paths (SEC EDGAR vs. grounded pipeline), the list of verdicts, the special semantics of 'could_not_verify' and 'unsupported', and the error structure. It clearly explains the tool's behavior and caveats, with no contradiction to annotations.

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

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

The description is long but well-structured, starting with trigger phrases and use cases, then technical details and important callouts. It is front-loaded and every sentence conveys crucial information, though the initial list of trigger phrases is slightly redundant.

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

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

Given the tool's complexity and lack of an output schema, the description fully covers return values, verdict meanings, error handling, and routing logic. It also explains the tool's efficiency benefit, making it comprehensive for an AI agent to invoke correctly.

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

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

Schema description coverage is 100%, and the input schema already provides thorough descriptions for both 'claim' and 'tolerance_pct', including default behavior and override guidance. The description adds minor context about 'exact percent-delta math' but does not significantly enhance parameter understanding beyond the schema.

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

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

The description explicitly identifies the tool as a natural-language claim verification tool with clear trigger phrases and a specific resource ('authoritative sources'). It distinguishes itself from sibling tools by focusing on fact-checking and even mentions replacing multi-step pipelines.

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 when to use ('Use whenever the agent needs to check whether something a user said is factually correct') and provides detailed routing guidance for financial vs. other claims. However, it does not explicitly mention when not to use it or name alternative tools, so it stops 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.