Wolfram Alpha

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

Annotations already provide readOnly, openWorld, idempotent, and non-destructive hints. The description adds useful behavioral details: default model is free, passing _apiKey probes Anthropic with direct payment to Anthropic, and the per-model return structure. 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?

Four sentences, each earning its place: main function, model configuration, return format, and use cases. No filler, front-loaded with purpose, and easy to scan.

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

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

With no output schema, the description compensates by specifying the per-model return shape (score, confidence, signals, raw_response) and a combined view. It covers default/cost behavior and use cases, making it self-sufficient for an agent to invoke correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds semantic value by explaining default model behavior (Workers AI free) and the cost/ownership implications of _apiKey (BYO key, pay Anthropic directly), which goes beyond the schema's field 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 a specific action (probe LLMs and score visibility) on a clear resource (business/brand/product/topic). It also distinguishes itself from siblings like scan_competitor_ai_presence by emphasizing multi-model visibility scoring and per-model scores.

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

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

It explicitly lists use cases (AI-marketing audits, pre-launch brand checks, competitive monitoring), giving clear context for when to use it. It does not name alternatives or exclusions, but the use-case enumeration is strong 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?

Beyond the readOnly, openWorld, idempotent, and non-destructive annotations, the description explains that the tool routes to one of 5,581 tools, fills arguments automatically, and returns structured answers with stable citation URIs. This gives the agent an important and non-obvious expectation about how broad the lookup is and what the output looks like.

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

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

The description is long but front-loaded with the critical PREFER OVER WEB SEARCH guidance and domain list. Some repetition exists across the category list, trigger phrases, and examples, but the examples earn their place for such a broad natural-language tool.

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

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

The description gives good overall coverage of intended use, data domains, and return style, including citations. However, with sibling tools ask_pipeworx_beta and ask_pipeworx_grounded available, an agent lacks the context needed choose among those variants, and there is no mention of what happens if no suitable source matches the question.

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 required question parameter and provides many aliases, so the baseline is 3. The description adds meaning by showing exactly what kind of phrasing is acceptable and giving representative query examples across filings, economics, weather, trials, and market data.

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 an actionable purpose: ask Pipeworx for factual questions across many recognized data domains and receive structured answers with citations. It distinguishes the tool from web search, but not from the sibling tools ask_pipeworx_beta and ask_pipeworx_grounded, so it stops short of full sibling differentiation.

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

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

The usage guidance is unusually explicit: prefer this over web search, use it whenever the user asks factual questions, and start here for most questions. It gives many concrete examples, though it does not specify when to choose ask_pipeworx_beta or ask_pipeworx_grounded instead.

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

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

The description adds substantial behavioral context beyond the annotations: it is a beta/experimental edge, candidates are enabled live only when under test, the last was retired, and it 'falls back to nothing' while still being a full working router. This goes well beyond the readOnly/idempotent/destructive hints and gives the agent an accurate mental model of the tool's current state.

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

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

The description is more verbose than the minimum but every sentence carries useful information: identity, current candidate state, usage instruction, and the 'full working router' clarification. It is front-loaded with the essential beta/experimental framing, though the dated retirement detail is slightly more than strictly necessary.

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

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

With rich annotations, a fully covered schema, and the description pointing to the exact stable sibling and response shape, the definition is nearly complete for an agent to call it. The main gap is that it does not describe what the ask_pipeworx response shape actually is, but it correctly references it rather than inventing a new format.

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

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

Schema description coverage is 100%: all six parameters (question, q, text, input, query, prompt) are documented in the schema, so the baseline is 3. The description only refers to 'same arguments' as ask_pipeworx, which does not add per-parameter meaning, but with full schema coverage no compensation is 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 states a specific verb ('ask') and resource ('universal router' with the same 5,581 tools and response shape as ask_pipeworx), and clearly distinguishes this experimental variant from the stable ask_pipeworx. It is not a tautology and an agent can tell it apart from sibling tools like ask_pipeworx and ask_pipeworx_grounded.

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

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

The description explicitly says to use it 'exactly like ask_pipeworx when you want the newest routing,' names the stable alternative, and clarifies that results are compared against the stable router to decide merges. It also tells the agent that currently no candidate is active, so it matches ask_pipeworx exactly, which is precise, actionable 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 establish read-only, idempotent, open-world, and non-destructive behavior. The description adds material behavioral context: the refusal contract with specific reasons, verbatim evidence, the extra LLM call cost, and the promise not to invent facts. No contradiction exists between description and annotations.

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

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

The description is well-structured and front-loaded with the core behavior, followed by return contract, usage guidance, and cost tradeoff. Minor details like the specific counts of tools and sources add scale context but are not strictly necessary for tool selection.

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

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

Despite having no output schema, the description fully compensates by specifying both the success response shape and the refusal response shape. It also explains when to use the tool, the tradeoff versus ask_pipeworx, and the routing behavior, giving an agent everything needed to invoke it appropriately.

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

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

Schema description coverage is 100%, and the schema thoroughly documents the question parameter and aliases, so the baseline of 3 applies. The description does not add parameter-level meaning, but it does not need to because the schema already handles it.

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

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

The description clearly identifies a specific behavior: a hallucination-resistant answer mode that routes like ask_pipeworx but extracts answers only from the tool result. It differentiates itself from the nearby sibling ask_pipeworx by emphasizing grounded extraction, evidence, and explicit refusals.

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

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

The description explicitly states when to use the tool ('whenever an answer will be quoted, cited, or acted on') and when not to ('prefer ask_pipeworx for casual lookups'). It names the primary alternative and gives a concrete cost-based reason for choosing between them.

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 is read-only, idempotent, and non-destructive, and the description adds extensive behavioral detail beyond that. It discloses the resolver contract (match confidence, alternatives), the low-confidence short-circuit that suppresses analysis fields, and the handling of closed/dead markets with blocking statuses. It also explains cancellation-rule risk (e.g., refund_50_50) and wide-spread market warnings, providing agents with safety-critical context.

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

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

The description is extremely long and includes many detailed sections, but it is structured and front-loaded with the core purpose and usage. Each section adds behavioral or safety-relevant information, but the sheer volume makes it less concise than ideal. It could be trimmed by moving some details to an external reference or output schema.

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

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

Given the lack of an output schema, the description thoroughly covers the response shapes (result.market, result.analysis, result.evidence), resolver contract, parent event extractor, news fallback behavior, and special statuses. It also explains the cancellation-rule parsing, which is crucial for sizing bets. This makes the tool well-specified for an agent to 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?

All three parameters have full descriptions in the input schema (100% coverage), so the baseline is 3. The description does not add additional semantic detail about the parameters beyond what the schema already provides; it only uses them in examples. Thus, score 3.

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

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

The description begins with a specific verb+resource: 'Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call.' It further clarifies the tool resolves the market, classifies the bet, fans out to category-specific data packs, and returns an evidence packet with market-vs-model comparison. This clearly distinguishes it from sibling tools like polymarket_arbitrage or validate_claim.

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

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

The description explicitly states when to use the tool: 'Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z".' It also provides examples of fan-out for various categories. However, it does not explicitly mention when NOT to use it or name alternative tools for other scenarios, so it falls slightly short of a full 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 declare read-only/idempotent behavior, but the description adds substantial context: it sources data from SEC EDGAR/XBRL for companies, FAERS for drugs, handles off-calendar fiscal years, sorts by a primary metric, and returns paired data with citation URIs. This goes well beyond the annotation hints.

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

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

The description is dense but well-structured, front-loading trigger phrases and practical usage. Every sentence adds value, though it could be tightened slightly; the length is justified by the amount of behavior it documents.

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 output format (paired data + citation URIs), covers data sources, sorting logic, and entity-type differences. It fully equips an agent to invoke the tool correctly and interpret results for a 2-parameter tool.

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

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

Schema coverage is 100%, but the description enriches both parameters: it explains that 'type' values map to distinct data sources and metrics, and that 'values' accepts tickers/CIKs vs drug names with concrete examples. It also clarifies the sorting behavior, giving functional meaning to the parameter choices.

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

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

The description explicitly states it performs 'side-by-side comparison of 2–5 companies or drugs in ONE parallel call', with specific trigger examples like 'X vs Y' and 'rank these companies'. This clearly distinguishes it from sibling tools like entity_profile or 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?

It gives explicit when-to-use guidance with trigger phrases, and directly says 'ALWAYS PREFER over sequential single-pack lookups when comparing entities', naming the alternative approach. It also specifies what each type pulls, helping the agent choose the right 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?

Describes the internal decomposition and parallel tool-use approach, the exact return fields (verbatim evidence, confidence, source, citation, hop, gaps[]), states it never invents answers, and clarifies differences between 'standard' and 'thorough' passes. Behavior is fully disclosed.

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

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

The description is dense with information and moderately long, but effectively uses separators and structured sentences. It covers many facets without redundancy; slightly longer than optimal but not bloated.

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?

All critical usage context is provided: account/pricing, time expectations, return structure (including field names), edge cases (gaps, contradictions), and explicit instructions on when to prefer alternative tools. No ambiguity remains 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?

Both parameters are described clearly. 'question' is natural language, and 'depth' has an enum with explicit meaning for each value, extending the schema description into behavioral guidance for each choice.

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 unambiguously defines the tool as a broad, multi-source research engine that decomposes questions into facets and routes to thousands of tools in parallel, returning structured findings. It contrasts clearly with simpler lookup tools, making its purpose instantly understandable.

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 account requirements (paid plan for 'thorough'), directs users to use ask_pipeworx on lower tiers or for current news, explains the depth parameter tiers (focus on gap recovery and contradictions), and sets expectations for latencies. Enough detail for an agent to decide when and how to call it.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable behavioral context beyond annotations: it returns top-N relevant tools with names, descriptions, and full input schemas, and states that results are ready to call directly with no second schema lookup. This reveals the tool's output format and reduces uncertainty for the agent, though it omits details on failure modes or pagination.

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

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

The description is three sentences: the first states the purpose, the second lists supported domains and return behavior in a dense but organized way, and the third gives strategic usage guidance. Every sentence earns its place, and the most critical information (finding tools) 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?

With no output schema, the description takes responsibility for explaining the return format, which it does thoroughly: 'Returns the top-N most relevant tools with names, descriptions, and full input schemas (with curated examples)' and notes direct callability. Combined with clear usage guidance and domain coverage, this 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%, and each parameter (query, q, task, search, description, limit) already has clear descriptions in the schema. The description adds minimal extra parameter detail—only an implicit reference to 'top-N' mapping to the limit parameter. Since the schema does the heavy lifting, the baseline of 3 is appropriate; the description does not introduce any new meaning.

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

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

The description opens with a specific verb+resource: 'Find tools by describing the data or task.' It clearly distinguishes this from sibling tools by positioning it as a meta-tool for tool discovery, explicitly naming domains and contrasting with 'not just one answer.' This makes it unmistakable which tool to pick for browsing capabilities.

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

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

The description provides explicit when-to-use guidance: 'Use when you need to browse, search, look up, or discover what tools exist' and 'Call this FIRST when you have many tools available and want to see the option set.' It also implies when not to use it (when you need a single answer), which effectively contrasts with sibling tools like deep_research or short_answer.

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 read-only and idempotent, but the description adds rich behavioral context beyond that: it fans out across multiple sources, returns specific fields (cik, filings with URIs, fundamentals sorted), includes a known limitation (USPTO PatentsView API sunset May 2025 with soft-fail), and explains the GDELT→GNews fallback. 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?

Though long, every sentence earns its place: examples, usage directive, source enumeration, return fields, limitations, fallback, input constraints. The structure is logical and front-loaded with examples, making it dense but highly scannable.

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 covers return values (cik, filings, fundamentals, patents, news, LEI), input validation (name not supported), data source behavior (fallback, sunset), and performance (ONE parallel call). It is complete for the tool's complexity and the given 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 description needn't repeat parameter names. However, it adds value with concrete examples (AAPL, 0000320193), clarifies zero-padded CIK, and reinforces that names are not supported. This enriches the schema's existing descriptions.

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

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

The description opens with concrete usage examples ('Tell me about X', 'research Acme') and immediately states the core function: a full cross-source profile of a US public company. It clearly names the single verb+resource ('profile', 'US public company') and differentiates itself from sibling tools by instructing to 'ALWAYS PREFER' it over chaining single-pack lookups.

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

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

Explicitly states when to use this tool (holistic view requests) and when not to (if only a name is provided, use resolve_entity first). It also names the exact input formats (ticker or CIK) and explicitly contrasts with chaining single-pack SEC/XBRL/news lookups, giving clear alternatives.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the description adds limited new behavioral context. It reinforces the destructive nature with 'Delete' and adds the nuance of clearing sensitive data, but doesn't go beyond annotations significantly.

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

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

Two sentences, front-loaded with the action, and every word earns its place. No fluff or redundancy.

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

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

For a simple single-parameter tool with no output schema, the description fully covers purpose, usage conditions, and complementary tools. Annotations cover safety aspects, so no critical gaps remain.

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

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

Schema coverage is 100% with the only parameter 'key' well-described as 'Memory key to delete'. The description adds no additional parameter-level information beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

The description opens with a specific verb+resource: 'Delete a previously stored memory by key.' This clearly states the tool's function and distinguishes it from sibling tools like 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?

The description provides explicit when-to-use guidance: 'Use when context is stale, the task is done, or you want to clear sensitive data.' It also references related tools ('Pair with remember and recall'), though it doesn't explicitly state when not to use them instead.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable context about return structure (named pods) and gives examples of pod types, complementing 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?

Two sentences, front-loaded with the main purpose, then concise examples of use cases. No waste or redundancy.

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

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

With an output schema available and annotations covering safety, the description provides the key contextual information: what the tool returns, when to use it, and examples of use cases. This is complete for a read-only query tool.

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

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

Schema description coverage is 100%, so all four parameters are already described. The description mentions 'pods' and 'include_pods' implicitly through examples, but adds no new parameter semantics beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description clearly states what the tool does: 'Get the full structured result from Wolfram Alpha' with a specific verb and resource. It also distinguishes it from the sibling short_answer by explaining it returns named pods and is useful when more detail is needed.

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 'useful when short_answer is too terse or you need multiple facets', providing a clear when-to-use condition and implicitly excluding the alternative. This helps an agent choose between full_query and short_answer.

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=false, so the safety profile is known. The description adds useful behavioral context: it fetches the page, extracts title/description/key links, and emits standard llms.txt markdown. 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 three sentences and front-loaded with the core purpose. Each sentence earns its place: purpose, process/output, and use cases. There is no fluff or repetition of schema fields.

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

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

Despite having no output schema, the description clearly states the return value ('a single text blob ready to drop at site-root/llms.txt') and the markdown format. The parameters are fully described in the schema, and the tool's behavior is straightforward. For a simple two-parameter tool, this is complete enough.

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

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

The input schema covers both parameters (url and max_links) with descriptions, so the schema already provides full semantic meaning. The description mentions 'any URL' and the output format, but it does not add substantive parameter-level detail beyond what the schema already states. This matches the baseline of 3 for 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 a specific verb (Generate) and resource (llms.txt file for any URL), and describes the outcome (production-ready file for AI crawlers). It distinguishes itself from sibling tools by focusing on generating the file rather than auditing visibility or scanning competitor presence.

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 use cases ('getting a client's site indexed by AI, drafting llms.txt for your own project, or auditing how an AI crawler would see a competitor'), making it clear when to use the tool. However, it does not explicitly name alternatives or state when not to use it, which prevents 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 declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable context that the tool lists only the caller's subscriptions and returns specific fields, which is not covered by annotations. It does not contradict any 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 compact and front-loaded. The first sentence states the purpose and returns, and the second sentence gives practical guidance. No redundant phrases or filler.

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

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

This is a simple list tool with one optional parameter and no output schema. The description covers purpose, return fields, and use cases. With good annotations and schema coverage, nothing essential is missing.

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

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

The schema description for include_inactive is fully self-explanatory (100% coverage), so the description does not need to elaborate. However, the tool description does not add any additional parameter meaning beyond what the schema already provides, so baseline 3 is appropriate.

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

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

The description uses a specific verb ('List') and identifies the resource ('the caller's active subscriptions'). It also names the returned fields, making the tool's scope unmistakable and distinguishing it from subscription mutation tools like subscribe/unsubscribe.

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

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

The description clearly states when to use the tool: to review existing subscriptions before adding more or to find an id to cancel. It does not explicitly mention alternatives or when not to use it, but the use cases are well-defined.

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

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

Annotations are all false and neutral, but the description reveals important behavioral traits: rate limit of 5 per identifier per day, claim_token workflow for later status checks, team digestion cadence, and that it's free with no quota impact. This adds substantial context beyond annotations.

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

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

The description is dense but well-structured, covering purpose, usage scenarios, exclusions, workflow, and rate limits without redundancy. Every sentence serves a distinct purpose, and the structure is logical and front-loaded with the core purpose.

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

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

Despite having no output schema, the description fully covers the tool's complexity: the optional nested context, the claim_token read flow, rate limiting, and scope limitations. It leaves no significant gaps for an agent to understand when and how to invoke it.

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

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

Schema coverage is 100%, so parameters are already well-documented. The description adds useful semantic guidance, such as 'Describe the issue in terms of Pipeworx tools/packs — don't paste the end-user's prompt' for the message parameter and clarifies claim_token usage for reading past reports. This elevates it above the 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's function: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It distinguishes itself from siblings by specifying it's for feedback on Pipeworx tools and explicitly differentiates from other MCP servers, making its purpose unambiguous.

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

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

It provides explicit when-to-use scenarios (bug, feature/data_gap, praise) and a clear when-not-to-use case for tools from other MCP servers, instructing to file those elsewhere. This goes beyond mere context to offer actionable alternative guidance.

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

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

Beyond the readOnly/idempotent annotations, the description discloses the data source ('derived from CF analytics-engine'), privacy ('no PII'), output shape ('just (pack, tool, count)'), and caching behavior ('Cached 5min-1h depending on window'). These details add real informational value not captured by annotations.

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

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

The description is structured with a clear opening statement, three numbered use cases, and a concise technical note. Every sentence carries information without redundancy. The length is appropriate for the richness of context provided.

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

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

For a single-parameter, read-only tool, the description covers purpose, output, parameter meaning, data source, privacy, and caching. There is no output schema, but the description specifies the output structure enough for an agent to understand the result. No critical information is missing.

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

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

The schema already fully describes the 'window' parameter with enum values. The description goes further by explaining semantic differences: 'Shorter windows surface what's hot right now; longer windows show steady-state demand.' This interpretive layer provides added value beyond the raw schema.

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

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

The description opens with a specific question: 'What other AI agents are calling on Pipeworx right now', then states the concrete outputs (top tools, top packs, total call volume) and the time window. It differentiates from sibling tools like discover_tools by focusing on aggregate usage trends, not just tool discovery.

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

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

The description provides three explicit use cases: identifying hot data sources for current events, confirming a canonical tool choice, and checking use-case alignment. It does not mention when not to use the tool or name alternative tools, but the scenarios give 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?

Goes far beyond annotations by disclosing internal thresholds (3pp partition deviation, ≥0.30 Jaccard similarity), placeholder filtering with null signals, and pricing against live CLOB depth with a no-trade rule for non-realizable edges. No contradiction with readOnlyHint/idempotentHint.

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?

Although long, every sentence serves a purpose and the text is front-loaded with the core purpose. Sections like SEMANTIC ANCHOR, PARTITION FILTER, and FILL CHECK make it skimmable. No redundant filler.

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

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

With no output schema, the description fully covers response fields (opportunities[], partition_check) and important edge cases (skipped_low_similarity, placeholders_filtered, thin_legs). It also cross-references polymarket_fill_risk for deeper sizing, making it complete for a complex tool.

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

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

While the schema already describes both parameters, the description adds concrete examples of event slugs and seed questions, explains the exact scanning behavior each parameter triggers, and clarifies accepted URL formats. This enriches the schema's generic descriptions.

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

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

The description opens with a specific verb+resource+method: 'Find arbitrage opportunities on Polymarket via monotonicity violations + partition-sum checks.' It clearly distinguishes from sibling tools like polymarket_edges (edges vs arbitrage) and polymarket_fill_risk (custom sizing).

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 specifies invocation modes: no args for trending scan, event slug for single-event partition check, and topic for cross-event scan. Recommends event for specific markets and suggests polymarket_fill_risk for custom sizing, plus warns against trading when realizable_edge_pp ≤ 0.

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 far beyond the annotations (readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false) by disclosing internal model details, caching behavior ('Cached 1h at the KV level keyed on all knobs'), and caveats (e.g., 24h-move warning, Fed signal unreliability). It also explains why segments may be empty via _diagnostics. This is rich contextual disclosure.

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 highly structured, with clear segments (MODEL_DRIVEN, STRUCTURAL_ARBITRAGE, CONCENTRATED_LONGSHOT, TRADEABLE-EDGE KNOBS, RESPONSE TOP-LEVEL). It front-loads the purpose and then organizes details. While verbose, the complexity of the tool (9 params, multiple model families, diagnostics) justifies the length; every sentence adds context about behavior or output structure.

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

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

There is no output schema, so the description must fully specify return values. It does so by describing by_segment, fed_candidates/fed_note, _diagnostics, and per-opportunity fields (edge_pp_net, kelly_fraction, market.liquidity, etc.). It also explains filtering mechanisms and caching. The tool is complex, and the description covers all relevant aspects for correct invocation and interpretation of results.

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

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

Schema description coverage is 100%, so the schema already documents all 9 parameters. The description adds meaningful cross-parameter semantics, such as min_kelly not filtering partition_overround opportunities (which always return kelly_fraction_half=0) and min_partition_leg_kelly applying per-leg instead. It also clarifies that edge_pp_net is after slippage and explains slippage_pp defaults. This goes beyond the schema's individual parameter descriptions.

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

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

The description opens with a specific verb and resource: 'Scan top Polymarket markets and return opportunities where Pipeworx data disagrees with market price.' This clearly states what the tool does and distinguishes it from siblings by describing the unique model families and response segments. It is not a tautology.

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

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

The description explicitly frames when to use the tool: 'Built for "what should I bet on today" — agents discover opportunities without paging hundreds of markets.' It also gives clear exclusions (Fed bets excluded from ranking due to unreliable signal) and explains how knobs like min_liquidity and max_spread_pp filter tradeable edges. However, it does not name alternative sibling tools (e.g., polymarket_arbitrage), so it misses the full 'when-not/alternatives' guidance.

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

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

The description adds substantial behavioral context beyond the readOnly/idempotent annotations: it explains the 60-day TTL bound, that snapshots are written on cache-miss so gaps mean no scan, and that decay is computed from daily closes rather than intraday. This gives the agent nuanced expectations about data availability and computation.

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

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

While the description is long, it is well structured with Args/RESPONSE/LIMITS sections and every sentence conveys essential information. It is front-loaded with the purpose and does not waste words.

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

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

Because there is no output schema, the description thoroughly documents the response structure (tracked, expired, snapshot_dates) and their meanings, including edge case behavior. It also explains limitations, making it fully self-contained for invocation.

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

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

Schema coverage is 100% and the description largely repeats the schema (days and window with defaults). No additional semantic meaning is added beyond 'snapshot family' and 'lookback', so the schema already does the heavy lifting.

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

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

The description states 'Edge persistence and decay telemetry built from daily polymarket_edges snapshots' and answers a specific question ('how long has this edge existed and is it shrinking?'). This clearly distinguishes it from sibling tools like polymarket_edges by focusing on historical trend analysis rather than current edges.

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

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

It clearly communicates the intended use case ('how long has this edge existed and is it shrinking?') and contrasts fresh vs old edges to convey when this tracker adds value. However, it does not explicitly name alternative tools or state when not to use it, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description rightly focuses on adding context. It discloses that the tool walks the order book ladder, returns specific metrics (top_of_book, vwap_fill_price, slippage_pp), and importantly warns that partial basket fills convert an arb into an unhedged directional position—a key behavioral risk not encoded in annotations.

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

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

The description is long but every sentence earns its place. It uses clear labels (SINGLE-MARKET, BASKET), enumerates return values, and closes with a pourquoi-style justification. The structure front-loads the core purpose and then branches into modes—appropriate for a tool of this 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 comprehensively covers return values for both modes, including edge-case fields like thin_legs, max_clean_notional_usd, and forced_directional_risk. It also contextualizes the tool within an arb-bot workflow, making it nearly impossible for an agent to misuse it. Completeness is 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?

Although schema coverage is 100%, the description adds substantial semantic meaning beyond the raw schema. It explains how size_usd is interpreted differently in single-market mode (max spend/target proceeds) vs basket mode (settlement notional), how side defaults change per mode, and how market vs event select different modes. This transforms the parameter list into 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 opens with a specific verb+resource phrase: 'Realizable-vs-theoretical edge check against live CLOB order-book depth.' It clearly distinguishes the tool from siblings by naming polymarket_arbitrage and polymarket_edges as tools it should precede, and it details two distinct modes (single-market and basket) with exact parameters and return values.

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

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

Explicitly states when to use: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500.' It also explains why with a concrete risk rationale (theoretical overround not capturable on thin books, partial fills create unhedged directional risk). This provides strong guidance relative to sibling tools.

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

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

Despite annotations already declaring read-only, open-world, idempotent, and non-destructive behavior, the description adds extensive behavioral context: compatibility_warning conditions, temporal_alignment semantics, skipped_cross_type/subtype counters, and the practical caveat that 'pre-mapped ≠ tradeable.' This goes far beyond the annotations.

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

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

The description is long but structured with clear labels (TWO MODES, RESPONSE, SAFETY FIELDS). The first sentence is a concise purpose statement, and every subsequent sentence adds necessary detail about behavior or caveats. It is not wasteful, though it could be tightened slightly; near the upper bound but not perfectly lean.

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

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

Given the tool's complexity (two venues, multiple modes, safety logic) and the absence of an output schema, the description covers all key aspects: return fields (leg-by-leg prices, top_spreads_pp), edge cases (compatibility_warning conditions), temporal alignment, and practical limitations. It is remarkably complete for a complex tool.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds substantial meaning by enumerating the 10 topic shortcuts, explaining the two operation modes, and clarifying that kalshi_event_ticker and polymarket_event_slug override the topic mapping. This exceeds baseline value.

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

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

The description clearly states the tool's purpose: 'Cross-venue spread between Kalshi and Polymarket for the same resolving question.' It names specific resources (Kalshi, Polymarket) and the action (computing spread), and differentiates from sibling tools like polymarket_arbitrage and polymarket_edges by focusing on cross-venue comparison.

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

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

Provides clear context on when to use: for comparing the same outcome across Kalshi and Polymarket, with two concrete modes (topic shortcuts or explicit tickers/slugs). It cautions that most pre-mapped topics return compatibility_warning, indicating when not to expect useful output. However, it does not explicitly name alternative tools or exclusion criteria, so it falls short of a 5.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior, so the description does not need to repeat those. It adds useful behavioral context: scoping to identifier (anonymous IP, BYO key hash, or account ID) and the optional list-all-keys behavior. 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 three sentences, starts with the main action, and every sentence adds value: behavior, use case, scoping, and companion tools. There is no fluff or repetition of schema details.

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

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

For a simple read-only tool with one optional parameter, full schema coverage, and strong annotations, the description plus schema is complete. It covers purpose, usage, scoping, and relationships with siblings. The lack of an output schema is acceptable because the description indicates what is returned (a value or list of keys).

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 covers 100% of the single parameter, so baseline is 3. The description adds semantic richness by providing examples of key values ('user's target ticker, an address, prior research notes') and clarifies that omitting the key lists all keys, which goes beyond the schema's basic 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 uses specific verbs and resources: 'Retrieve a value previously saved via remember' and 'list all saved keys (omit the key argument)'. It clearly distinguishes itself from the sibling tools 'remember' and 'forget' by focusing on retrieval and listing.

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

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

It explicitly states when to use the tool: to look up previously saved context like the user's target ticker, address, or research notes, without re-deriving it from scratch. It also mentions scoping and pairs with 'remember' and 'forget', but does not provide explicit when-not-to-use scenarios or alternative tool names.

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

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

Annotations already indicate a safe, read-only, idempotent operation. The description adds important behavioral context beyond annotations: it discloses that setting mark_read:true modifies state by flagging events as read, affecting subsequent calls. It also reveals the return payload structure and the availability of an HTTP mirror, adding transparency without contradicting the annotations.

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

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

Three sentences, each earning its place. The purpose is front-loaded, followed by return details, filtering, and a usage tip with an alternative. No redundant or vague wording.

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

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

With no output schema, the description covers return values (source, citation_uri, raw payload), filtering, side effects (mark_read), and even mentions an alternate access method. It is complete for a feed-pulling tool, leaving no major operational 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%, so the baseline is 3. The description goes beyond by providing an example for type (sec_8k), specifying the ISO timestamp format for since, and explaining the side effect of mark_read:true. This enriches the schema, though unread_only and limit remain only 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 tool pulls fired events from the subscription feed and returns the most recent alerts. It specifies the verb 'pull' and the resource, and distinguishes itself from siblings like list_subscriptions by focusing on alerts rather than subscription management.

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

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

The description provides clear usage context, including filtering options, mark_read behavior, and notes that polling works fine. It also mentions an alternative HTTP endpoint for scripts/dashboards, which serves as an explicit alternative for different use cases. It lacks explicit 'when-not-to-use' guidance, but the niche is well-defined.

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

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

The description richly discloses behavior beyond annotations: multiple API fan-outs, GDELT→GNews fallback on rate limits/5xx, USPTO soft-fail due to API sunset, and return structure (changes[] grouped by source, total_changes, citation URIs). No contradiction with annotations.

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

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

The description is dense yet every sentence earns its place: examples, source behavior, parameter formats, output shape, and an alternative. It's well-structured with a clear lead and supporting details, appropriate for the tool's complexity.

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

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

Given the tool's multi-source complexity and absence of an output schema, the description fully explains the return format and failure modes. It also covers fallback logic and the entity_profile alternative, making it self-contained for an agent.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value with explicit examples for `since` (ISO/relative shorthand) and a recommendation for typical monitoring, plus clarification that `value` can be a ticker or CIK. 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 identifies this as a change feed for a company over a time window, listing example queries and detailing specific data sources (SEC, GDELT/GNews, USPTO). It distinguishes itself from entity_profile by explicitly stating the alternative for static profiles.

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

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

Provides explicit guidance on when to use this tool versus entity_profile, and clarifies the parallel call efficiency. It also gives parameter usage examples like '7d', '30d', and recommends '30d' or '1m' for typical monitoring, which helps agents choose appropriate inputs.

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 context beyond annotations by disclosing that data is stored as a key-value pair scoped by the agent's identifier, and that persistence varies by auth status (persistent for authenticated users, 24 hours for anonymous). It does not explicitly mention overwrite behavior, but the idempotentHint annotation already signals that repeated saves are safe, so the description adds valuable extra details without contradicting the annotations.

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

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

The description is a compact paragraph with the main purpose front-loaded, followed by concrete examples, storage mechanics, and important caveats. Every sentence earns its place, with no fluff or redundancy.

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

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

For a simple two-parameter tool with no output schema, the description covers the full behavioral picture: what it saves, when to use it, how it is scoped, persistence rules, and related tools. This is sufficient for an agent to select and invoke the tool correctly in real scenarios.

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

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

The schema already fully describes both parameters (key and value) with examples, achieving 100% coverage. The description contributes illustrative use cases but no additional syntax or constraints beyond what the schema provides, so it meets the baseline but does not elevate it.

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

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

The description states a specific action ('Save data') with a clear resource (data the agent will need to reuse later), and provides concrete examples ('resolved ticker', 'target address', 'user preference', 'research subject'). It distinguishes the tool from siblings by explicitly naming recall and forget as companions for retrieval and deletion, making the purpose unambiguous.

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

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

The description gives explicit when-to-use guidance: 'Use when you discover something worth carrying forward... so you don't have to look it up again.' It also states how to complement with other tools ('Pair with recall to retrieve later, forget to delete') and notes persistence differences based on authentication status, which helps the agent choose appropriately.

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, and openWorldHint=true, so the safety profile is clear. The description adds useful context: it describes cascading internal lookups (SEC EDGAR, GLEIF, OpenFIGI, RxNorm) and states that each call 'replaces 2-3 manual lookups'. However, it does not detail any rate limits, latency expectations, or what happens when a lookup produces no results beyond the mention of a graceful degradation for LEI/FIGI.

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

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

The description is comprehensive with multiple paragraphs covering query patterns, supported types, and edge-case behavior, but it is quite long (over 250 words) and includes parenthetical asides that could be tightened. While every sentence adds value, the length risks overwhelming the agent's context window. A more front-loaded structure with the core directive ('resolve name to ID, use first') at the very top would improve 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?

Given the tool's moderate complexity (2 required parameters, no output schema, no nested objects), the description is thorough: it covers input patterns, supported entity types, identifier sources (EDGAR, GLEIF, OpenFIGI, RxNorm), graceful degradation, and the 'unresolved' output behavior. The only notable gap is the lack of explanation about the return structure (e.g., whether multiple identifiers are returned as a flat list or grouped), which would be especially helpful since there is no 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?

The input schema already covers both parameters ('type' with enum, 'value' with description) with 100% schema description coverage. The description adds meaningful context by explaining the identifier sources (EDGAR, GLEIF, OpenFIGI, RxNorm) and showing examples like 'AAPL', '0000320193', or 'ozempic', which enriches the schema's static enum/string hints. However, because the schema already does the heavy lifting, the added semantic value is moderate and justifies a baseline 3.

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

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

The description opens with concrete query patterns like 'What's the ticker for…' and 'find the CIK for…', then clearly defines the tool's action: resolve a user-spoken name to canonical/official identifiers that other tools require. It explicitly supports two entity types ('company' and 'drug') with distinct identifier sets, strongly distinguishing it from sibling tools like 'ai_visibility_check' or 'entity_profile' which serve different purposes.

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

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

The description explicitly says 'Use FIRST whenever you have a name but need an ID', providing a clear directive for when to invoke this tool. It lists alternative input formats (ticker, CIK, ISIN, company name) and explains that an ISIN resolves to the legal entity via GLEIF, covering non-US cases EDGAR cannot reach. The description also notes that LEI/FIGI enrichment degrades gracefully, guiding the agent on expected behavior under partial availability.

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

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

The annotations (readOnlyHint=true, idempotentHint=true, openWorldHint=true, destructiveHint=false) already communicate the safe read-only nature. The description adds behavior beyond annotations by explaining that it probes each entity with ai_visibility_check, ranks by score, and returns a ranked list with score/confidence/signal density. It does not mention rate limits or cost implications, but given the annotation coverage, this is acceptable.

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 exactly three sentences, front-loaded with the primary action and followed by mechanism, use case, and output format. Every sentence earns its place with no redundancy or filler.

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

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

Despite no output schema, the description explicitly tells the agent what to expect: 'Returns ranked list with score, confidence, signal density per entity.' It covers the orchestration flow (probes, ranks, surfaces) and provides a concrete use-case example. Entity count limits and model options are already covered in the parameter schema, leaving no critical gap.

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

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

Schema description coverage is 100% with each parameter already well-described in the schema. The description adds no new parameter-level semantics; it only restates the multi-entity concept in the narrative. Since the schema fully documents parameters, the baseline of 3 applies.

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

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

The description clearly states the tool's purpose: 'Compare AI visibility across multiple entities side-by-side.' It specifies the action (compare), the resource (AI visibility), and the scope (multiple entities). It distinguishes itself from the sibling tool ai_visibility_check by referencing it as the underlying probe and framing this as a multi-entity competitive audit tool.

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

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

The description explicitly provides a use case: 'Useful for competitive AI-marketing audits' with an example query. It implies when to use this tool over ai_visibility_check (multiple entities vs. single), but it does not explicitly name alternatives or state when not to use it. This is clear context but lacks an explicit exclusion.

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

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive. The description adds significant behavioral context: fan-out across two services, partial-failure degradation, 5-30s first-measurement latency, sources_failed reporting, and full return field details. 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 appropriately sized for a composite tool. It front-loads the core purpose and then packs every sentence with actionable info: sources, use cases, return fields, ecosystem scope, and failure behavior. No wasted words.

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

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

Given no output schema, the description enumerates the summary block fields, per-advisory details, links, and alternative versions. It also covers edge cases (first-version timeout, ecosystem fallback). This makes the tool fully self-contained for an agent to understand inputs, outputs, and failure modes.

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

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

The input schema covers 100% of parameters with clear descriptions (npm package name, scoped packages accepted, version default). The description adds no new parameter-level meaning beyond the schema, so baseline 3 is appropriate.

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

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

The description states a specific composite check for npm packages ('should I add this npm package to my project') and names the data sources (deps.dev and bundlephobia). This clearly differentiates it from sibling research tools like deep_research or validate_claim.

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

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

Explicitly provides when-to-use triggers ('Use whenever an agent asks "is X safe / popular / small"...') and an important exclusion ('NPM ecosystem only in v1; PyPI / Maven / Cargo / Go fall under deps.dev:version directly'). This gives agents clear decision criteria 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?

The description discloses meaningful behavioral details beyond annotations: BGE-base-en embeddings, cosine similarity, 500-char overlapping windows, 200K character cap with truncation flagged, and that results include character offsets and similarity scores. Annotations already declare read-only, idempotent, and open-world, so the extra technical details provide substantial added 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?

The description is information-dense and front-loaded, with the first sentence stating the core purpose and the following sentences adding usage and technical details. It is slightly long, but every clause contributes value (e.g., embedding details, truncation behavior, offset capability). No fluff or repetition.

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

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

The description fully equips an agent to select and invoke the tool correctly: it explains the purpose, use case, output characteristics (offsets, scores), algorithmic details, and limits, all while differentiating from sibling tools. Even without an output schema, the description covers what to expect and how to handle edge cases like truncation.

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 each parameter described, including max length for text, example queries, and default limit. The description adds minimal new parameter semantics beyond reinforcing the 200K cap and showing query examples; it mostly reiterates what the schema already provides. A baseline score of 3 is appropriate.

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

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

The description clearly states the tool performs semantic search inside a fetched record, using a specific verb ('search') and resource ('inside a fetched record'). It distinguishes itself from siblings by emphasizing it operates on text already retrieved, with a strong explanation of its value proposition (saves context, returns only passages that matter).

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 provides when-to-use guidance: 'Use when the record is too big to cram into the prompt.' It also names the complementary alternative ask_pipeworx_grounded and explains the pairing pattern: fetch with the gateway, then ground over relevant passages. This is clear, actionable, and distinguishes it from alternatives.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds that the answer is 'terse' and returns 'one string', which is some behavioral context, but does not go beyond what annotations and output schema imply. No contradiction.

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

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

The description is two sentences, front-loaded with the main purpose, and every sentence provides value. The 'Returns one string' is a clear and useful outcome statement.

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, full schema coverage, and the presence of an output schema, the description adequately covers purpose, use cases, and behavioral expectations. No missing information that would impede correct usage.

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

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

Schema description coverage is 100%, so parameters are fully documented. The description adds general use-case context (e.g., 'unit conversion' implies the units parameter) but no new parameter-specific semantics, aligning with the baseline for 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 'Get a single terse plain-text answer from Wolfram Alpha' and lists example use cases, making the purpose obvious. However, it does not explicitly name or differentiate from sibling tools like wolfram_compute or full_query, so it falls short of a 5.

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 'Best for' list provides clear context for when to use the tool (arithmetic, unit conversion, factual lookups). However, it lacks explicit 'when not to use' guidance or references to alternative tools, which would earn 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 mark it as non-readonly, idempotent, and non-destructive, but the description adds crucial behavioral details: OAuth requirement, anonymous/BYO cannot persist, phone verification, 10/day SMS cap, webhook auto-disable after 10 failures, and one-time signing secret. These go well beyond the annotations.

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

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

The description is long but densely packed with essential information, front-loaded with core purpose, then types, then delivery channels. Every sentence adds value, and the structured use of semicolons and examples keeps it readable.

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

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

Given the tool's complexity (3 params, nested objects, enums, no output schema), the description covers auth requirements, type-specific filters, delivery options with caveats, return value (subscription id), and webhook secret behavior. It is fully self-sufficient for an agent to use correctly.

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

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

Even though schema coverage is 100%, the description enriches parameter meaning with concrete examples for each type (sec_8k items codes, polymarket_edge topic, fred_series series_id) and detailed delivery channel semantics including webhook signing and verification requirements. This significantly aids 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 clearly states the verb 'Create' with a specific resource: 'a proactive monitoring subscription to a live-data event stream.' It distinguishes itself from sibling tools like list_subscriptions and recent_alerts by focusing on creation, and details supported subscription types.

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 provides clear context on when to use (creating persistent subscriptions) and prerequisites (OAuth account), and mentions the always-on feed that can be pulled via recent_alerts as an alternative for retrieval. However, it does not explicitly name alternatives for one-time edge queries like polymarket_edges, so not a full 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 declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive hint, so the safety profile is covered. The description adds valuable context about what the tool returns (example questions sourced from 'the live catalog of thousands of tools') and positions it as a learning tool, enriching beyond 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 dense but well-structured, front-loading example queries and immediately stating the tool's role. The initial sentence is a bit long, but every part earns its place by covering purpose, invocation, and output. It's longer than typical but appropriately so for an onboarding tool.

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

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

Given a single optional parameter and no output schema, the description is remarkably complete. It explains what to expect in the response (category buckets, exact tool + argument shape), how to narrow results, and when to use the tool overall. There is no missing critical information for an agent to select and invoke it correctly.

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

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

The schema already fully describes the `topic` parameter (coverage 100%). The description adds examples (finance, pharma, betting) and clarifies that omitting the parameter yields a 'cross-category spread', which goes beyond the schema's generic description and helps an agent understand the parameter's behavior.

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

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

The description clearly identifies the tool as 'the onboarding entry point' and specifies it returns 'category-bucketed example questions' each with 'the exact tool + argument shape'. This distinguishes it from siblings like discover_tools by positioning it as the first stop for learning what Pipeworx can do.

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 'Use this FIRST when you do not yet know what Pipeworx can do for you', giving a clear when-to-use directive. It also explains how to call with or without the `topic` parameter. However, it does not explicitly name or contrast alternatives (e.g., discover_tools) or say when not to use it, slightly reducing the score.

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, the description explains that the row is deactivated (not deleted), meaning historical events remain accessible via recent_alerts—a key behavioral consequence. It also discloses ownership enforcement, which is not captured in annotations. This adds significant 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?

Three focused sentences: action+parameter, ownership constraint, and deactivation consequence. Every sentence adds value and the main verb is front-loaded.

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

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

For a single-parameter operation with annotations and full schema coverage, the description is complete. It explains the mutation behavior, ownership, and the relationship to recent_alerts, which is sufficient for an agent to select and invoke the tool safely.

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

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

The input schema already provides full coverage (100%) with a clear description of the 'id' parameter (uuid returned by subscribe). The tool description does not add additional parameter-level meaning, so the baseline score of 3 applies.

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

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

Description clearly identifies the action (Cancel), the resource (subscription), and the key parameter (by id), differentiating from sibling tools like subscribe and list_subscriptions. The ownership and deactivation details further clarify scope.

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

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

The description states the core use case (cancel a subscription) and notes ownership constraints (only your own) and the consequence for historical events (still available via recent_alerts). It does not explicitly mention when not to use it or name alternative tools, 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?

Annotations already declare read-only, idempotent, and non-destructive. The description adds substantial behavioral context: the two pipeline paths (SEC/XBRL vs grounded), the meaning of each verdict (especially could_not_verify vs unsupported), and the 'replaces 4–6 sequential calls' efficiency. This goes well beyond what annotations provide.

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

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

The description is long but well-organized and front-loaded with purpose and examples. Each section (routing, verdicts, error semantics) earns its place. It could be tightened, but it is not bloated or 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?

With no output schema, the description fully compensates by explaining the return values (verdict types, citation, reasoning) and the distinction between could_not_verify and unsupported. This makes the tool's behavior fully self-contained and clear 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?

The schema already documents both parameters with 100% coverage. The description adds practical guidance for tolerance_pct (e.g., 'set 1–2 for hallucination detection') and clarifies the default behavior, adding value beyond the schema.

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

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

The description clearly defines the tool as 'natural-language claim verification against authoritative sources' with concrete examples of user phrasing. It distinguishes itself from sibling tools like ask_pipeworx by focusing on fact-checking with a verdict output, rather than general Q&A or 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?

It explicitly states when to use the tool: 'Use whenever the agent needs to check whether something a user said is factually correct.' It also details the routing logic for company-financial vs. other claims. However, it does not explicitly name alternatives or provide 'when not to use' guidance, which prevents 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 declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds the key behavioral detail that it runs in a 'real Wolfram kernel,' indicating actual computation rather than a mock or LLM guess. This goes beyond annotations, so a 4 is appropriate.

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 efficient with three sentences: purpose, example queries, and an explicit input example. It is front-loaded and each clause adds value, though slightly dense. No filler.

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

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

The tool has no output schema, so the description should explain return behavior, but it does not mention what the kernel returns (e.g., result, error messages) or how time_constraint_seconds affects execution. It covers common use cases well but omits these details, leaving gaps for a computational tool.

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

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

Schema description coverage is 100% for both parameters, so the schema already documents code and time_constraint_seconds. The description adds an explicit call example and reinforces that 'code' must be actual Wolfram Language code, but this is marginal beyond the schema. Baseline 3 is correct.

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 evaluates Wolfram Language code in a real Wolfram kernel, with specific verb ('Evaluate') and resource ('Wolfram Language code'). It lists concrete capabilities (symbolic math, exact arithmetic, matrix algebra, unit conversion) and example queries, making it unmistakable versus the unrelated sibling tools.

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

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

The description provides clear usage context by giving natural-language examples ('integrate x^2 sin x', 'solve this equation symbolically') and instructs the user to 'Give actual Wolfram Language code.' It does not explicitly exclude alternatives or mention when not to use it, but given no sibling tool overlaps, this is sufficient.

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