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?

Annotations already cover read-only, open-world, idempotent, and non-destructive behavior. The description adds valuable context beyond that: it discloses that the tool routes to sub-tools, fills arguments, and returns answers with stable pipeworx:// citation URIs. There is no contradiction with 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 opening sentences are strong and information-dense, but the description becomes repetitive: the 'START HERE... Examples' block appears multiple times, and the ending contains confusing, seemingly corrupted text about live news and '-news-feeds packs'. The useful content is buried under avoidable duplication.

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

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

For a tool with a single required string parameter and no output schema, the description covers the domain scope, trigger phrases, routing behavior, and output citation format. It is sufficient for an agent to invoke the tool correctly, though the final corrupted segment slightly weakens completeness.

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 documents all six properties as aliases of the single 'question' parameter, so the baseline of 3 applies. The description provides example questions and trigger phrases, which help an agent formulate input, but it does not add meaningful parameter-level semantics 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 states a specific mission: it routes questions to one of 5,798 tools and returns structured answers with pipeworx:// citation URIs, and it enumerates covered domains such as SEC filings, FDA data, patents, and weather. It is clearly about answering factual real-world questions, but it does not differentiate itself from sibling tools like ask_pipeworx_grounded or ask_pipeworx_beta.

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 strong when-to-use guidance: 'PREFER OVER WEB SEARCH', trigger phrases like 'what is', 'look up', 'get the latest', and six concrete example questions. It also says 'START HERE for most questions', but it never explicitly says when not to use it or when a sibling variant like deep_research or short_answer would be better.

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

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

Beyond the annotations, it discloses that this is an experimental edge, that routing candidates are only enabled during tests, that no candidate is currently active, and that the tool is a fully working router with nothing to fall back to. This is exactly the behavioral context an agent needs before invoking a beta variant.

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?

Each of the four sentences adds distinct, useful information: what the beta is, the current candidate state, usage guidance, and fallback clarification. It is slightly long and has some repetition ('identical'/'exactly'), but it is front-loaded and 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?

For a question-only interface, the description covers the tool's current behavior, experimental status, relationship to the stable router, and safety profile indirectly via annotations. The main gap is that the response shape is only referenced by equivalence to ask_pipeworx rather than described directly, and 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?

Schema coverage is 100% and every parameter is documented as an alias for question, so the description adds little here. Its 'same arguments' comment points to ask_pipeworx rather than explaining argument behavior, keeping this at the baseline for fully documented schemas.

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

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

The description identifies the tool as a beta version of ask_pipeworx, a universal router with the same 5,798 tools, arguments, and response shape. It clearly differentiates it from the stable ask_pipeworx by its experimental routing-candidate behavior, though full purpose comprehension still depends on knowing what ask_pipeworx itself does.

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

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

The description explicitly says to use it exactly like ask_pipeworx when the newest routing is desired, and explains that results are compared against the stable router to decide merges. It gives the current state caveat that no candidate is active, but stops short of explicitly saying when not to use this vs. the stable tool.

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

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

Even though annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, the description adds meaningful behavioral detail: it discloses the strict extraction rule, the full success/refusal return shape, the refusal_reason enum, and the extra-call cost. This significantly exceeds what the annotations alone communicate.

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 the description is dense, every sentence earns its place: mode, routing, extraction rule, output contract, refusal reasons, use cases, and cost trade-off. It is front-loaded with the defining benefit and flows logically from behavior to usage.

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

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

For a tool with no output schema, the description fully explains the return contract, including success and refusal payloads. It also covers safety via annotations, cost/performance trade-offs, and routing relationship to the sibling tool, leaving no obvious gap for an agent deciding whether and how to call 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?

The input schema covers 100% of parameters and documents the question parameter plus aliases, so the baseline is 3. The description does not add parameter-level meaning beyond implying that a natural-language question is the input, which is acceptable because the schema already handles parameter semantics thoroughly.

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 and resource: it is a hallucination-resistant answer mode that routes like ask_pipeworx, fetches data, and extracts answers only from tool results. It explicitly contrasts itself with the sibling ask_pipeworx by emphasizing grounded extraction and refusal behavior, so an agent can distinguish it without opening schemas.

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

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

The description gives explicit when-to-use guidance: use it when an answer will be quoted, cited, or acted on and fact-invention is unacceptable, naming domains like financial verdicts and medical lookups. It also gives an exclusion and alternative preference: prefer ask_pipeworx for casual lookups because this tool costs an extra LLM call.

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

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

Annotations already declare 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?

Despite readOnly/idempotent annotations covering safety, the description adds substantial behavioral context: account and paid-tier requirements, parallel routing across 5,798 tools, gaps[] for unanswered facets, contradictions[] for disagreeing findings, semantic excerpting, latency expectations, and the fetchability guarantee of 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 and front-loaded with the critical account requirement, but it is verbose and contains repetitive guidance about ask_pipeworx plus an awkward 'Then more:' transition that reads like an artifact. Not every sentence earns its place.

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

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

For a complex tool with no output schema, the description is unusually complete: it specifies the return packet fields, gap and contradiction behavior, excerpting strategy, latency, auth prerequisites, and sibling-tool routing. An agent has all necessary information to 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?

Schema coverage is 100% and the schema already explains both `question` and `depth` in detail, so the baseline is 3. The description adds marginal peripheral context—example questions, latency implications of depth—but no new parameter-level semantics beyond what the schema provides.

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

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

The description states a specific verb+resource: grounded multi-source research across Pipeworx's 1517 structured data sources in one call. It also explicitly differentiates itself from open-web search and from ask_pipeworx, so an agent can distinguish it from siblings without guessing.

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?

Gives explicit when-to-use instructions: use ask_pipeworx if not signed in and for single lookups; use deep_research for broad/multi-part questions over structured data. It also explains depth tiers and when each is appropriate, leaving little to inference.

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

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

Annotations 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 mark it read-only, idempotent, and non-destructive; the description adds valuable behavioral context: USPTO soft-fails after May 2025, empty sections are real 'no data' not bugs, private companies return resolved:false with an explicit notes line, and sources_used/sources_failed report which sources actually returned data. This goes 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 informative and well-structured: examples first, then routing rule, then source fan-out, return fields, accepted inputs, and edge cases. There is minor redundancy near the end when restating that type and value shapes are interchangeable, but overall the length is justified by the tool's complexity.

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

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

With no output schema, the description must carry the burden of explaining return values, and it does: it enumerates each result section, mentions URIs for filings, explains source-failure reporting, and clarifies expected empty sections. An agent can correctly invoke the tool and interpret its response without additional documentation.

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

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

Schema coverage is 100%, but the description enriches both parameters with concrete examples, zero-padded CIK expectations, the fact that type is interchangeable, name resolution via SEC EDGAR, and the private-company edge case. It tells an agent how each parameter behaves, not just what it is.

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 user phrasings and immediately states 'full cross-source profile of a US public company in ONE parallel call.' It names the major data sources and return sections, clearly identifying this as the holistic company-lookup tool and distinguishing it from single-source lookups like SEC/XBRL/news 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 explicitly says 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view,' which is a strong, actionable routing rule. It also specifies acceptable input forms (ticker, CIK, name) and the private-company fallback, giving clear guidance on when and how to invoke the tool.

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

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

Annotations already 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?

The description goes far beyond the readOnly/idempotent annotations by disclosing matching methodology, safety fields, skipped-pair counters, temporal alignment semantics, fee handling, and the fact that all spreads are gross and not net tradeable. It also clarifies the meaning of null temporal_alignment and warns that both compatibility fields can be non-empty even when pairs are returned. This is exemplary behavioral 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 very long, but it is densely informative and clearly structured with labeled sections (TWO MODES, RESPONSE, SAFETY FIELDS, Codes, fees_note, skipped counters). It front-loads the core purpose and mode selection. It could be tightened and some warnings are repeated, but given the tool's complexity and the absence of an output schema, the length is largely justified.

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 covers return shape, price units, spread sign convention, safety codes, failure/skipped cases, temporal alignment semantics, fee limitations, and the rarity of real spreads. An agent has nearly everything needed to invoke the tool correctly and interpret its result.

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

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

Schema coverage is 100%, so the schema already documents all three parameters. The description adds valuable semantics by explaining how topic, kalshi_event_ticker, and polymarket_event_slug interact (overrides), that both modes run the same matcher, and what the topic values map to. This goes beyond the schema's brief descriptions, though it does not add much syntax-level detail.

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

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

The opening sentence states the resource precisely: a cross-venue spread between Kalshi and Polymarket for the same resolving question. It clearly distinguishes itself from single-venue tools by name, but it does not explicitly contrast itself with nearby siblings like polymarket_arbitrage or polymarket_edges, so the differentiation is implicit rather than stated.

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 thorough usage context: two modes (topic shortcuts vs explicit ticker/slug), shared matching logic, and strong caveats about pre-mapped topics not being tradeable. It does not explicitly say when an agent should prefer another sibling tool instead, but it clearly explains what this tool is for and what its limitations are.

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?

The description adds substantial behavioral context beyond the annotations: graceful degradation when GLEIF/OpenFIGI are unavailable, explicit `unresolved` output for failed identifiers, ambiguity handled via `figi_candidates`, and cascading internal lookups. There is no contradiction with the readOnlyHint, openWorldHint, idempotentHint, or destructiveHint 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 dense with necessary caveats and examples, and it is front-loaded with user-phrasing examples. However, it is structured as one large nested paragraph, which reduces scannability despite every sentence contributing useful information.

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

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

For a tool with no output schema, the description covers resolution sources, supported entity types, ambiguity handling, unresolved identifiers, and degradation behavior. It gives an agent enough detail to select and invoke the tool correctly without needing additional lookups.

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

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

Although schema coverage is 100%, the description adds significant meaning: accepted input forms for company (ticker, CIK, ISIN, or name), brand/generic for drug, concrete examples, and critical guidance about passing only the entity name with a counterexample. This goes well beyond the schema.

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

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

The description clearly states the verb and resource: it 'resolve[s] a user-spoken NAME to the canonical/official identifiers other tools require as input' and gives concrete examples. It distinguishes itself as a first-step resolution tool with 'Use FIRST whenever you have a name but need an ID,' though it does not explicitly name or differentiate against 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 a clear trigger condition ('Use FIRST whenever you have a name but need an ID') and route-specific guidance for company vs drug lookups. However, it does not state when not to use the tool or how it relates to alternatives like entity_profile or compare_entities.

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.