Arbeitnow

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

Discloses behavioral traits beyond annotations: default model is free, Anthropic requires a key and direct payment, and return structure includes per-model scores/signals. No contradiction with annotations (readOnly, idempotent).

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, no wasted words. Front-loaded with core function, followed by key option, return format, and use cases. Excellent structure.

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

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

Covers purpose, parameters, and returns adequately. No output schema, but description explains the return structure (per-model + combined). Could add more detail on raw_response format, but sufficient for agent understanding.

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

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

Schema covers 100% of parameters with descriptions; the description adds value by explaining the default model, when _apiKey is needed, and how context disambiguates. Adds meaning beyond schema alone.

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

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

The description clearly states the tool's verb (probe), resource (LLMs), and outcome (score visibility 0-100). It distinguishes itself from sibling tools like 'ask_pipeworx' or 'deep_research' by focusing on AI visibility measurement.

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

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

Explicitly lists use cases (AI-marketing audits, pre-launch brand checks, competitive monitoring) and explains when to use the Anthropic model (BYO key). Lacks explicit 'when not to use' guidance, but context is clear enough.

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

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

Beyond the readOnly/openWorld/idempotent annotations, the description discloses meaningful behavior: it routes to one of thousands of tools, fills arguments automatically, returns structured answers with stable pipeworx:// citation URIs, and is described as 'one fast call' working on every tier. This gives the agent an accurate model of what invoking the tool will do.

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 front-loads the most important directive ('PREFER OVER WEB SEARCH'), then covers scope, examples, and fallback/alternative tools in a clear hierarchy. There is no filler and the structure makes the decision procedure easy to follow.

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 broad scope and lack of an output schema, the description is remarkably complete. It states what data domains are covered, what kind of questions to ask, what the response will contain (structured answer plus citation URIs), and when to step up to alternatives. Nothing critical is missing for an agent to decide 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 schema already documents the question parameter and aliases at 100% coverage, so the baseline is 3. The description adds value by clarifying the expected form and breadth of the question: natural-language factual queries, with concrete examples like 'current US unemployment rate' and 'Apple's latest 10-K', which enriches the parameter semantics beyond schema text.

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 immediately identifies a specific resource and action: ask_pipeworx routes natural-language questions to authoritative structured data sources and returns cited answers. It clearly distinguishes this tool from web search and from more specialized siblings by scope and depth.

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 selection guidance: 'PREFER OVER WEB SEARCH', 'START HERE for most questions', and names exact alternatives with their trigger conditions, such as ask_pipeworx_grounded for hallucination-resistant single answers and deep_research for broad multi-part questions. It also clarifies that news and breaking-questions are already covered.

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

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

The description goes well beyond the annotations by disclosing that this is an experimental edge, that candidate routing improvements are enabled live only when under test, that no candidate is currently active, and that it does not fall back to another tool — it is a full working router. This is rich behavioral 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 dense and front-loaded with the key beta/universal-router concept first. There is slight redundancy between 'identical universal router' and 'currently matches ask_pipeworx exactly', but the additional candidate-status and no-fallback clarifications justify the length.

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

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

For a routing tool with no output schema, the description is notably complete: it covers identity, candidate status, current behavior, comparison against the stable router, and the fact that it is fully functional rather than a stub. An agent has enough context 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?

The input schema already describes parameters and aliases with 100% coverage. The description only repeats that it has the 'same arguments' as ask_pipeworx, which adds no meaningful parameter-level detail 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 immediately identifies it as a beta variant of ask_pipeworx and explicitly calls it a 'universal router' with the same 5,714 tools, arguments, and response shape. This clearly states what the tool does and distinguishes it from the stable ask_pipeworx sibling.

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

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

It explicitly says 'Use it exactly like ask_pipeworx when you want the newest routing' and explains that results are compared against the stable router to decide merges. This gives clear when-to-use guidance and names the alternative.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, but the description goes well beyond them. It discloses the success response shape, the refusal contract with specific refusal_reason enums (not_in_source, no_tool_match, etc.), that the answer is grounded only in the tool result, and the cost tradeoff. 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 dense but every sentence contributes: purpose, mechanism, success/refusal contract, when to use, when to avoid. It front-loads the core value proposition and leads with 'Hallucination-resistant' before the detailed contract. No filler or redundant restatement.

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 specifies the return shape and refusal reasons. It also covers routing scale, grounding constraints, cost, and the alternative tool. Combined with a complete input schema and rich annotations, an agent has everything needed to invoke this tool correctly in context.

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

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

Schema description coverage is 100%, so the schema fully documents the question parameter and all aliases. The tool description does not add param-level detail beyond what the schema provides, which is acceptable given the baseline rule. The description's 'fills arguments' is a general behavior statement, not parameter semantics.

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 purpose: 'Hallucination-resistant answer mode for high-stakes reads' that 'EXTRACTS the answer using ONLY what the tool result contains.' It explicitly differentiates from ask_pipeworx by name ('Same routing as ask_pipeworx') and from ask_pipeworx_beta, making the tool's role in the sibling family unambiguous. An agent can tell exactly what this tool does and how it differs.

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 whenever an answer will be quoted, cited, or acted on, and the agent must not invent facts' with concrete examples. It also states when not to use it: 'prefer ask_pipeworx for casual lookups,' and the reason is quantified ('Costs one extra LLM call'). This is ideal routing guidance.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true. The description adds extensive behavioral context: fan-out patterns, resolver contract, parent_event extractor, news fallback fields, safety short-circuits, wide-spread handling, and resolution-rule risk. All behaviors align with annotations.

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

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

The description is long but well-structured with labeled sections (classifiers, fan-out examples, response shapes, resolver contract, etc.). It is front-loaded with purpose and usage. While every part is informative, some redundancy could be trimmed, but overall it earns its length.

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

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

Given the tool's complexity (multiple data sources, fan-out, edge cases, resolution rules), the description is remarkably complete. It covers inputs, outputs, error handling, safety, and tradeability details. No output schema exists, but the description compensates thoroughly.

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

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

Schema coverage is 100% (all 3 parameters described). The description adds extra meaning beyond the schema, e.g., clarifying input formats for 'market', explaining 'depth' options (quick vs thorough), and detailing 'include_raw' behavior. This adds value without redundancy.

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

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

The description clearly states it researches Polymarket bets by pulling Pipeworx data, specifying input types (slug, URL, question text) and output (evidence packet, market-vs-model comparison). It distinguishes from siblings like polymarket_edges and polymarket_arbitrage by focusing on comprehensive data retrieval for bet 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?

Usage is explicitly stated ('should I bet on X', 'what does the data say about Y', 'is there edge in Z'), and classifiers, fan-out examples, and blocking paths (low-confidence, closed markets) are provided. However, it lacks explicit when-not-to-use instructions or direct comparison 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?

Adds significant behavioral detail beyond annotations: single parallel call, handles off-calendar fiscal years, sorts results by primary metric, and returns citation URIs. Annotations already indicate read-only and idempotent, but description expands on data sources and result structure.

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

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

Single dense paragraph with front-loaded natural language triggers, then key behavioral details. Every sentence adds value, but could be slightly more structured with bullet points or separation of input/output. Still concise and effective.

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

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

Covers input (type and values with examples), behavior (parallel call, sorting), and output (paired data + citation URIs). No output schema exists, but description adequately describes return format. For a complex multi-entity comparison tool, this is complete.

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

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

Schema coverage is 100%, so baseline is 3. Description adds meaning beyond schema: explains what data each type pulls (10-K, FAERS), gives examples for values (tickers vs names), and clarifies sorting behavior, helping agent use parameters correctly.

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

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

The description clearly states the tool performs side-by-side comparison of 2-5 companies or drugs, using specific financial or adverse event data. It includes natural language triggers like 'compare X and Y' and 'which is bigger,' making the purpose immediately recognizable and distinguishing it from siblings like entity_profile.

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

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

Explicitly instructs 'ALWAYS PREFER over sequential single-pack lookups when comparing entities' and mentions it replaces 8-15 sequential lookups, giving clear when-to-use guidance. Also implies not to use for single entity lookups via contrast with triggers and efficiency claim.

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, open-world, and non-destructive behavior. The description adds substantial behavioral context beyond that: explicit gaps[] rather than invented answers, contradictions[] on standard/thorough, semantic excerpting of large records, stable fetchable citation_uri, no hallucination, and expected latency of 15-90 seconds. This is far more than annotations alone 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 well-organized, front-loaded with the account caveat and sibling alternatives, and each major behavior gets a clear sentence. It is long, however, and somewhat repetitious with the schema's detailed depth descriptions and the earlier in-one-call point, so a little trimming would make it sharper.

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, this description covers essentially everything needed for correct invocation: output packet shape, citation semantics, gap/contradiction behavior, depth-level differences, auth/tier requirements, and latency expectations. There is no obvious missing guidance that an agent would need.

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

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

Input schema coverage is 100%, and the depth enum is already well-described. The description adds non-schema invocation context: thorough requires a paid plan, signed-in status gates usability, and it gives concrete natural-language question examples for the question parameter. It does not introduce fundamentally new per-parameter format details, but the added auth/tier context is actionable.

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 precise verb and resource: grounded multi-source research over Pipeworx's structured data sources in one call, explicitly noting it is NOT open-web search. It also distinguishes itself from siblings by naming ask_pipeworx for single lookups and ask_pipeworx_beta for breaking/current news, so an agent can immediately tell them apart.

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: best for broad/multi-part questions over structured data, use ask_pipeworx instead for a single lookup, and use ask_pipeworx_beta for breaking/current news. It also specifies the account/tier prerequisite and the fallback to ask_pipeworx if not signed in, 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, and destructiveHint=false. The description adds functional transparency by specifying the output: 'Returns the top-N most relevant tools with names, descriptions, and full input schemas (with curated examples) — each result is ready to call directly.' This aligns with annotations and provides extra behavioral 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 concise at 5 sentences, front-loaded with the core purpose, and efficiently adds usage guidance and output details. Every sentence earns its place with no redundancy.

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

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

Despite lacking an output schema, the description fully explains what the tool returns (tool names, descriptions, schemas with examples) and how to use it. It covers all necessary context for an agent to invoke the tool correctly, given the high schema coverage and clear annotations.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add significant new meaning beyond the schema; it reiterates aliases and the natural language nature of the query parameter. The examples in the input schema provide adequate context.

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

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

The description clearly states the tool's purpose: 'Find tools by describing the data or task.' It lists specific domains (SEC filings, FDA drugs, etc.) and distinguishes itself from sibling tools by explicitly stating 'Call this FIRST when you have many tools available and want to see the option set.'

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

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

The description provides explicit usage scenarios: 'Use when you need to browse, search, look up, or discover what tools exist for:' followed by concrete categories. It advises calling this tool first for option discovery. However, it does not explicitly state when not to use it or name alternative tools.

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

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

Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds significant behavioral context: it fans out across multiple sources, mentions the USPTO PatentsView API sunset May 2025 (soft-fails), and details the return structure including URIs and sorting. 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 about 150 words, slightly long but well-structured: starts with example queries, then states purpose, then details outputs. Every sentence adds value, but could be slightly more concise.

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

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

Given no output schema, the description thoroughly explains return data (cik, company_name, recent_filings with URIs, fundamentals, patents, news, LEI). It covers edge cases (name not supported, USPTO soft-fail) and references sibling tool resolve_entity. 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 coverage is 100%, and the description adds meaning beyond the schema: explains that type is only 'company' for now, that value must be ticker or zero-padded CIK, and that names are not supported. Provides examples. Baseline 3 is exceeded due to added context.

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

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

The description explicitly states the tool provides a 'full cross-source profile of a US public company in ONE parallel call', lists multiple data sources (SEC EDGAR, XBRL, USPTO, news, GLEIF) and specific return fields. It distinguishes itself from chaining single-pack lookups by explicitly preferring this tool for holistic views.

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 examples ('Tell me about X', 'research Acme'), states when to prefer this tool over alternatives, and notes that names are not supported, advising to use resolve_entity first. It also mentions soft-fails for USPTO API.

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

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

Annotations already provide destructiveHint=true and idempotentHint=true, so description adds minimal behavioral context beyond 'clear sensitive data'. No details on deletion failure or key not found, but acceptable for a simple operation.

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

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

Two concise sentences with purpose front-loaded and usage guidelines immediately after. 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?

Simple tool with one param and no output schema. Description covers purpose, usage, and pairing with siblings. Annotations cover behavioral traits. Complete for its complexity.

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

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

Schema coverage is 100% with parameter description 'Memory key to delete'. Description only adds 'by key', not adding significant meaning beyond schema.

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

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

Description clearly states the tool deletes a memory by key, with specific verb and resource. It distinguishes from siblings 'remember' and 'recall' which handle storing and retrieving.

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

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

Explicitly states when to use: when context is stale, task done, or to clear sensitive data. Mentions pairing with other tools, but doesn't explicitly exclude other scenarios.

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

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

Annotations already indicate a safe, read-only, idempotent operation. The description adds process details (fetches page, extracts title/description/key links) without contradicting annotations.

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

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

Two sentences plus a bullet list of use cases; every sentence adds value. No redundant or vague phrasing.

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

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

The output format is described as a single text blob, which is sufficient given no output schema. The process is explained, and the tool's purpose is fully covered 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 description coverage is 100%, so both parameters are fully documented. The description adds no additional meaning beyond what the schema already provides.

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

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

The description clearly states the tool generates a production-ready llms.txt file for any URL, specifying the exact output format and purpose for AI crawlers. It is distinct from all 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?

Explicit use cases are provided (client indexing, own project, competitor auditing), making it clear when to use this tool. No direct alternatives are mentioned, but the unique function makes this less critical.

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

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

Discloses that there is no dedicated upstream endpoint, so the tool scans ~3 recent pages. This is valuable behavioral context beyond the annotations (which already indicate safety and idempotency). 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?

Two sentences: the first states the core purpose, the second provides crucial constraints and alternatives. No superfluous text; 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?

Given the simple input (single slug), lack of output schema, and rich annotations, the description covers the tool's behavior, limitations, and fallback completely. No gaps for an agent to misunderstand.

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

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

Schema covers 100% of the single parameter 'slug' with a description that matches the tool's context. The description does not add significant meaning beyond the schema, meeting the baseline without exceeding.

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?

Explicitly states that the tool fetches full details of a single job posting by slug, including the full HTML description. It also distinguishes itself from the sibling tool 'search_jobs' by noting when the job cannot be retrieved.

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?

Clearly explains when to use (job within recent pages) and when not to (job scrolled off), and explicitly suggests the alternative 'search_jobs'. Provides actionable context for agent decision-making.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive properties. The description adds behavioral context such as reverse-chronological ordering, one-page results, and omission of HTML descriptions. 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?

Three well-structured sentences. The first sentence provides purpose and context, the second explains ordering and exclusion, and the third tells how to use parameters. No unnecessary 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 the tool's simplicity (2 optional params, no output schema, full annotations), the description covers all necessary aspects: data source, ordering, filtering, pagination, and relation to sibling. It is complete for an AI 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?

Schema coverage is 100% with descriptions and examples. The description reinforces usage of 'page' and 'remote_only', adding that page defaults to 1 with 100 jobs per page and remote_only filters to remote jobs. This adds value beyond the schema.

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

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

The description clearly identifies the tool as listing recent job postings from Arbeitnow, specifying the board's characteristics (European, Germany-heavy, English-speaking, visa-sponsorship). It also distinguishes from the sibling get_job by noting that HTML descriptions are omitted.

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

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

The description explains when to use the tool (to list jobs, paginate, filter remote) and references get_job as an alternative for full descriptions. However, it does not explicitly mention when not to use it, though the context is clear enough.

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds value by listing return fields and usage context, but no additional behavioral traits beyond annotations.

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

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

Two concise sentences: first explains the function and outputs, second provides usage guidance. No wasted words, front-loaded with key information.

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

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

Given the simplicity (1 optional parameter, no output schema but return fields listed in description), the description is complete and sufficient for the agent to use the tool correctly.

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

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

Schema coverage is 100% and the parameter include_inactive has a description. The tool description does not add any extra meaning beyond what the schema provides, so baseline score of 3.

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

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

The description explicitly states the tool lists the caller's active subscriptions and enumerates the return fields (id, type, etc.). It clearly distinguishes from sibling tools like subscribe and unsubscribe, which are mutations.

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 advises using this tool to review subscriptions before adding more or to find an id to cancel, providing clear context. It does not explicitly state when not to use it, but the guidance is sufficient.

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

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

With all annotations false, the description carries the full burden and delivers rich behavioral context. It discloses the claim_token flow, rate limiting ('Rate-limited to 5 per identifier per day'), cost ('Free; doesn't count against your tool-call quota'), and team response cadence ('The team reads digests daily and signal directly affects roadmap'). No contradiction with the readOnlyHint=false annotation, as this is a write operation.

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

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

The description is front-loaded with the primary purpose, then flows logically through usage guidelines, exclusions, token mechanics, and practical constraints. It is longer than average but every sentence earns its place by conveying critical operational details without 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 having no output schema, the description explains key return behavior (claim_token on filing without an account) and how to later retrieve status. It covers prerequisites, alternatives, limits, and actionable guidance for both initial filing and follow-up, making it complete for an agent to safely invoke.

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 all parameters with 100% coverage, so the baseline is 3. The description adds meaningful context for the claim_token parameter by explaining how to use it to read resolution status, and it also clarifies the context parameter by instructing to describe issues in terms of Pipeworx tools/packs. This goes beyond the schema, but not dramatically.

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

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

The description opens with 'Tell the Pipeworx team something is broken, missing, or needs to exist', which clearly and specifically defines the tool's action and target. It further distinguishes this from sibling research/query tools by listing feedback categories (bug, feature, data_gap, praise).

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 when a tool returns wrong/stale data (bug), when a tool you wish existed isn't in the catalog (feature/data_gap), or when something worked surprisingly well (praise).' It also provides a clear exclusion: 'ONLY for tools served by this Pipeworx connection... if the tool came from a different MCP server... file it with that server 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?

Adds details beyond annotations: data source (CF analytics-engine), no PII, caching (5min-1h), and return structure (top tools, top packs, total call volume).

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

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

Concise paragraph with front-loaded purpose and bullet-like use cases. Every sentence adds value; no fluff.

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

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

Given simple tool with one optional param and no output schema, the description covers all needed context: purpose, usage, data source, caching, privacy, and return format.

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

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

Schema already describes the enum and parameter. Description adds interpretive guidance (shorter windows vs longer windows) that adds value beyond the schema.

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

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

Clearly states it returns trending tool and pack usage data, with three explicit use cases. Distinct from sibling tools like discover_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?

Lists three specific scenarios where the tool is useful and explains window choice (short vs long windows). No explicit when-not-to-use, but 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 indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds extensive behavioral context: return format (opportunities[], partition_check), fill check logic (prices against CLOB depth, realizable_edge_pp ≤ 0 means do not trade), semantic anchor, and partition filter. No contradictions.

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

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

The description is comprehensive but slightly long; however, every sentence adds unique value. It is front-loaded with the main purpose and then details modes. Could be tightened by removing redundant mentions of 'recommended' but still clear and well-structured.

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

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

Given the complexity of arbitrage detection with multiple modes, fill checks, and no output schema, the description provides sufficient information: what it returns, how it works, when to use each mode, and what to do for custom sizing. An agent can confidently select and invoke the tool.

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

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

Schema coverage is 100% with parameter descriptions. The description adds examples of event slugs and topic seed questions, explains the behavioral difference between modes, and provides context on how parameters affect the scan (e.g., cross-event mode searches related events).

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 'Find arbitrage opportunities on Polymarket via monotonicity violations + partition-sum checks.' It uses a specific verb+resource and distinguishes from sibling Polymarket tools (e.g., polymarket_edges, polymarket_fill_risk) by focusing on arbitrage detection.

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 explains when to use each mode: no args for trending_scan, 'event' for a specific market (recommended with example slugs), 'topic' for cross-event scanning. It also mentions cross-event mode catches patterns missed by single-event mode and directs to polymarket_fill_risk for custom sizing.

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 readOnlyHint and idempotentHint annotations, the description reveals extensive behavioral details: the three model families, how edges are calculated (e.g., slippage, Kelly fractions), caching at KV level, and tradeable-edge knobs. It also explains why Fed bets are excluded. No contradictions with annotations.

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

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

The description is long but well-structured, with clear sections for segments, knobs, and diagnostics. It is front-loaded with the purpose. While every sentence adds value, some details (e.g., exact model parameters) could be condensed without loss of clarity. Still, it remains readable and informative.

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

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

No output schema exists, so the description fully compensates by detailing the response top-level structure (by_segment, fed_candidates, _diagnostics) and field meanings (edge_pp_net, kelly_fraction, etc.). It covers return format, caching, and filter behavior, making it complete for agent use.

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

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

Schema coverage is 100%, but the description adds substantial meaning beyond schema. For each parameter, it explains defaults, examples, and rationale (e.g., slippage_pp explains Polymarket fees, min_partition_leg_kelly clarifies why parent-level Kelly is always 0). This greatly aids correct parameter usage.

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

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

The description clearly states the tool scans Polymarket markets to find opportunities where Pipeworx data disagrees with market price, and it's built for 'what should I bet on today'. It distinguishes itself by focusing on top markets with three specific segments, avoiding the need to page through hundreds of markets. This sets it apart from siblings like polymarket_arbitrage and polymarket_edge_tracker.

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

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

The description explains the tool is for discovering betting opportunities, notes caching (1 hour), and excludes Fed bets from ranking. It provides guidance on using knobs to filter. However, it doesn't explicitly mention when not to use this tool versus siblings, such as switching to polymarket_arbitrage for direct arbitrage or polymarket_edge_tracker for historical tracking. Slight gap in exclusions.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds substantial behavioral details: response structure (tracked, expired, snapshot_dates), field meanings (trend, decay_pp_per_day, lifespan_days), and limitations (60-day TTL, decay from daily closes). No contradictions.

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

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

The description is detailed and front-loaded with purpose, but it is somewhat long. However, each sentence serves a purpose—explaining response format, fields, and limitations. Minor redundancy could be trimmed, but overall well-structured.

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

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

No output schema, so the description must fully explain return values. It does so exhaustively: tracked[], expired[], snapshot_dates[] with field meanings and limitations. Highly complete for a read-only telemetry tool.

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

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

Schema covers 100% of parameters with descriptions. The description adds value by specifying defaults (14 days, 1wk), constraints (max 30), and clarifying 'window' as 'snapshot family.' This goes beyond the schema alone.

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

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

The description clearly states the tool's purpose: 'Edge persistence and decay telemetry built from daily polymarket_edges snapshots.' It answers a specific decision-making question and distinguishes itself from siblings like polymarket_edges by focusing on temporal aspects.

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 implicitly gives usage context by contrasting fresh wide edges with old ones, suggesting when to use this tool over raw edges. It does not explicitly list alternatives or state when not to use, but the context is clear enough.

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

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

The description adds significant behavioral context beyond the annotations, which already indicate read-only, open-world, idempotent, and non-destructive behavior. It explains how the tool walks the order-book ladder, returns verdicts like 'clean|degraded|cannot_fill', and highlights the risk of partial basket fills converting arbs into directional positions.

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

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

The description is relatively long but well-structured, with clear mode separation and front-loaded with the main purpose. Every sentence provides necessary guidance, so the length is justified. Slightly verbose but not wasteful.

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

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

Despite lacking an output schema, the description thoroughly enumerates the return values for both modes (top_of_book, vwap_fill_price, slippage_pp, etc.) and explains per-leg fill details and thin_legs. It also covers the dominant loss mode, 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?

With 100% schema description coverage, the baseline is 3, but the description adds valuable semantic nuance. For example, it explains that size_usd is interpreted as 'settlement notional S (shares per leg)' in basket mode, and clarifies side defaults based on partition sum. This goes beyond the schema's basic descriptions.

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

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

The description clearly states the tool's function as a realizable-vs-theoretical edge check against live order-book depth. It distinguishes between single-market and basket modes and explicitly differentiates from sibling tools like polymarket_arbitrage and polymarket_edges by specifying when to use them.

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

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

The description explicitly states when to use this tool: before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500. It also provides warnings about theoretical overround on thin books and partial basket fills, giving clear usage 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?

Despite readOnlyHint and idempotentHint already covering safety, the description adds deep behavioral context: price gap ranges, response structure, compatibility_codes, skipped_unclassified handling, temporal_alignment, and counters for dropped comparisons. It also explains that unknown metric_type/match_subtype legs are never paired and that compatibility warnings may be non-empty even when matched_pairs>0 — valuable cautionary behavior not visible from annotations.

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

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

The description is long but every sentence carries unique operational content — no filler or restating of name/title. It is front-loaded with the core purpose, then follows a clear order: modes, response, safety fields, codes, skipped cases, and a final caution. The use of labeled sections and code names makes the density manageable.

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 carry the full burden of explaining return values — and it does. It enumerates response components (leg prices, top_spreads_pp, compatibility_warning, compatibility_codes, temporal_alignment, skipped_unclassified, low_confidence_pairs, counters). For a tool with three parameters, zero required fields, and no output schema, nothing operationally necessary 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?

Schema description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining how topic relates to the two override parameters, including the override semantics and the exact macro list. It doesn't over-explain each field, but it clarifies the mode interaction that the schema alone implies.

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 line names a specific verb and resource: 'Cross-venue spread between Kalshi and Polymarket for the same resolving question.' It immediately differentiates this tool from intra-venue or single-market siblings like polymarket_edges by fixing the two venues and the same-question constraint. The two-mode structure further disambiguates what the tool accepts.

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 for both invocation modes: 'topic' for 10 pre-mapped shortcuts and explicit ticker/slug for custom pairings. It also warns that 'pre-mapped ≠ tradeable' and that most topics return compatibility warnings, telling agents not to treat pre-mapped results as reliable without reading the safety fields. Alternatives are not named, but the tool's own mode-selection rules are unambiguous.

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, non-destructive. Description adds scoping to identifier and behavior of omitting key, providing value beyond annotations.

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

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

Three sentences, front-loaded with core function, 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?

Covers purpose, usage, scope, and sibling relationships; lacks error handling but compensable given tool simplicity.

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

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

Schema coverage is 100%; description reinforces and adds context (e.g., omitting key lists all, scoped to identifier).

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 retrieves a value saved via remember or lists all keys when omitted, distinguishing it from siblings remember and forget.

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

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

Explicitly advises when to use (look up stored context) and pairs with remember and forget as alternatives.

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

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

Annotations declare read-only, idempotent, non-destructive. Description adds behavioral details like mark_read affecting subsequent calls and the nature of the feed, complementing annotations well.

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 packs purpose, return fields, filtering, read status, and alternative access in two sentences 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 explains return fields (source, citation_uri, raw event payload). It covers all necessary context for an agent to use the tool effectively.

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

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

All 5 parameters are explained with clear semantics in the description, adding value beyond the schema descriptions. For example, 'mark_read:true to flag returned events read so the next call only shows newer ones.'

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, returning recent alerts with specific fields. It is distinct from sibling tools like list_subscriptions or subscribe.

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 guidance on polling and mentions an alternative access method via URL, implying when to use this tool. Could be stronger on when not to use it.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description leverages these. It adds valuable context beyond annotations, such as multi-source fan-out, soft-fail for USPTO, and return structure (changes[] with citation URIs). No contradictions.

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

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

The description is front-loaded with common query patterns and efficiently packs purpose, sources, fallback, parameter details, return structure, and alternative tool into a few sentences. Minor verbosity could be trimmed, but overall it earns its length.

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

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

Given the tool's complexity (multi-source, fallbacks), the description covers essential aspects: input parameters, behavior, return structure, and relationship to sibling. It lacks an output schema but describes key return fields adequately for agent understanding.

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

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

Schema coverage is 100% with descriptions, but the tool description enhances parameter meaning by explaining the relative shorthand for 'since', acceptable formats for 'value' (ticker or CIK), and providing example usage. This adds value beyond the schema.

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

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

The description clearly states the tool provides a change feed for a company in the last N days/weeks/months by fanning out to multiple sources (SEC, GDELT/GNews, USPTO). It uses specific verbs and resources, and explicitly distinguishes itself from the sibling tool 'entity_profile' for static profiles.

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

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

The description includes explicit when-to-use guidance (e.g., 'Use entity_profile instead when you want the static profile') and explains fallback behavior (GDELT preferred, GNews when rate-limited). It also provides parameter usage tips (e.g., 'Use "30d" or "1m" for typical monitoring').

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 (idempotent=true), description adds scoping by identifier, persistent vs 24-hour retention for anonymous sessions, and key-value storage details. 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?

Concise (about 80 words), front-loaded with main purpose, logical flow, no wasted sentences.

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?

Simple tool with complete schema and annotations; description covers all needed context for selection and invocation.

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

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

Schema covers both parameters with descriptions. Description adds naming conventions and value purpose, which is helpful but not critical. Baseline 3, plus 1 for added context.

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

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

The description clearly states the tool saves data for reuse across sessions, with specific examples like ticker, address, preference. It distinguishes from siblings recall and forget.

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

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

Explicitly says 'use when you discover something worth carrying forward' and mentions pair with recall/forget, providing clear when-to-use and alternatives.

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

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

Annotations already mark readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavior beyond that: internal cascading lookups, graceful degradation when GLEIF/OpenFIGI are unavailable, ambiguous FIGI results returned as 'figi_candidates' rather than asserted, and unresolved identifiers explicitly listed under 'unresolved' rather than omitted. This is rich, non-obvious behavioral 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 dense and somewhat run-on, especially inside the 'company' parenthetical, but it is front-loaded with purpose and usage, then structured by supported types. Every major point earns its place given the tool's complexity; a small structural cleanup would make it a 5.

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 convey what the agent can expect. It covers supported input types, output identifiers (CIK, LEI, FIGI, RxCUI, ingredient, brand), fallback behavior, ambiguity handling, and cross-source coverage. For a resolver of this complexity, the contextual picture is complete enough for correct 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%, so the baseline is 3, but the description substantially exceeds that baseline. It explains the 'type' enum with detailed output expectations per type, and enriches 'value' with per-type examples and a critical constraint: pass the entity name exactly as printed and never the full noun phrase (e.g., 'NEW YORK ST DORM AUTH' not 'revenue bonds'). This prevents a real failure mode.

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

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

The description names a specific verb ('resolve') and resource (user-spoken names to canonical identifiers), and enumerates supported entity types ('company', 'drug') and concrete identifier outputs (CIK, LEI, FIGI, RxCUI). It distinguishes itself from other tools by stating it supplies the IDs that 'other tools require as input', and the detailed examples ('ticker for…', 'CIK for…') make the purpose unmistakable.

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

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

It gives explicit direction: 'Use FIRST whenever you have a name but need an ID.' This is strong when-to-use guidance. It does not explicitly name sibling alternatives or say when not to use it, but the condition is clear enough that an agent can route appropriately without confusion.

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds that it probes each entity with ai_visibility_check, ranks by score, and returns a ranked list with score, confidence, signal density. This provides behavioral detail beyond annotations.

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

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

Three sentences, front-loaded with core purpose, then details. No unnecessary words. Every sentence adds value.

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

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

Given no output schema, the description fully explains return format (ranked list with score, confidence, signal density). All 4 parameters are addressed in context. The tool's role is clear even with annotations and sibling tools.

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

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

Schema description coverage is 100%. Description adds semantic meaning: first entity treated as 'subject', rest as competitors; explains that 'models' can be workers-ai or anthropic (with _apiKey), and 'context' disambiguates. This goes beyond schema descriptions.

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

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

Description starts with a specific verb 'Compare AI visibility across multiple entities side-by-side' and clearly states the resource (AI presence of entities). It distinguishes from sibling tool 'ai_visibility_check' which is used per entity, and 'compare_entities' by focusing on AI visibility ranking.

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

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

States explicit use case: 'competitive AI-marketing audits' with a concrete example question. Does not explicitly state when not to use, but the context is clear enough for an agent to decide.

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

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

Discloses behavioral traits beyond annotations: partial failures degrade gracefully, bundlephobia's first measurement can take 5-30s, sources_failed will list timeouts but rest still returns. Annotations already indicate safe, idempotent, non-destructive, and description adds context without contradiction.

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

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

The description is front-loaded with a clear summary and each sentence adds meaningful information. It is slightly long but well-structured, earning a 4.

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 covers all relevant aspects: what the tool does, what it returns (with field names), limitations (npm only, potential delay), and error handling. No output schema is provided, but the description compensates thoroughly.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds value by mentioning that scoped packages are accepted and that version defaults to the latest when omitted, which is useful context beyond the schema descriptions.

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

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

The description clearly states the tool's purpose: a composite check for adding an npm package, covering license, advisories, version history, bundle size, dependency count, and ESM/tree-shake support. It distinguishes itself from siblings by being a specific 'should I add this package' check.

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 tells when to use: when agent asks about safety, popularity, size, or cost of adding a package. Also provides exclusions: 'NPM ecosystem only in v1' and directs to deps.dev:version for other ecosystems.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds valuable behavioral details: client-side filtering, scanning up to 10 pages, case-insensitive matching, and a performance tradeoff (more pages slower). No contradiction with annotations.

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

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

The description is concise, consisting of two well-structured sentences. The first sentence states the purpose and key properties, and the second explains the client-side scanning approach and limitations. Every word adds value; no redundancy.

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

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

Given the tool has three parameters and no output schema, the description covers the essential aspects: what it does, how it works, parameter defaults and constraints, and a key limitation (only recent jobs). It is sufficient for an agent to use effectively, though not exhaustive (e.g., no example return format).

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

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

Schema coverage is 100%, but the description adds meaning beyond the schema: default pages=3, max 10, case-insensitive search, and default remote_only=false. It also explains the scanning behavior (pages = recent pages scanned). This provides useful context beyond the property descriptions.

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

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

The description clearly states the tool's purpose: keyword-search recent Arbeitnow job postings. It specifies the source (Arbeitnow) and the search fields (title, company, tags). However, it does not explicitly differentiate from sibling tools like 'get_job' or 'list_jobs', though the search function is distinct.

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

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

The description provides context on when to use the tool (for searching recent jobs) and explains its limitations (only recent pages, older jobs not found). It does not list alternatives but implies the tool is appropriate for recent searches. The explanation of the upstream API limitation gives clear guidance.

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

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

Beyond annotations (readOnly, idempotent, non-destructive), description adds critical behavioral details: truncation at 200K chars with flag, embedding model (BGE-base-en), windowing (500-char overlapping), and offset for verification. No contradictions.

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

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

Concise single paragraph that front-loads the core purpose. Every sentence adds value: purpose, usage, pairing, technical details. 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, description adequately explains return values (passages with offsets and scores). Covers input limits, embedding details, and sibling relationship. 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?

Schema coverage is 100%, so baseline is 3. Description adds some value by giving query examples and clarifying text truncation, but does not significantly extend beyond schema definitions for all parameters.

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

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

The description clearly states it performs semantic search inside a fetched record, returning top passages with offsets and similarity scores. It distinguishes from siblings like ask_pipeworx_grounded by explaining the pairing pattern.

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 when-to-use guidance: when the record is too large for the prompt. Also suggests pairing with ask_pipeworx_grounded for grounding, giving clear context 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?

Discloses behavior beyond annotations: requires OAuth, subscription persistence, delivery limits, webhook signing details. No contradictions with annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=true, destructiveHint=false).

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

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

Well-structured with clear sections: main purpose, types, delivery channels. While detailed, each sentence adds value. Could be slightly more concise but not wasteful.

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?

Comprehensive for a subscription creation tool with 3 params and no output schema. Covers all aspects: auth requirements, type-specific params, delivery options, limits, return value (subscription id). Agent can confidently invoke the 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?

Adds significant meaning beyond 100% schema coverage: explains type and params with concrete examples for each subscription type, details delivery options including email, SMS, webhook with signing instructions. Schema descriptions are brief; description provides essential context.

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

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

Clearly states it creates a proactive monitoring subscription to a live-data event stream and returns the new subscription id. Lists specific subscription types, distinguishing it from siblings like unsubscribe and list_subscriptions.

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

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

Provides explicit requirements (Pipeworx OAuth account, phone verification for SMS, 10/day SMS cap). Implicitly advises against use by anonymous/BYO users. Does not explicitly contrast with sibling tools like list_subscriptions, but context is clear.

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

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

Annotations declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. Description confirms no mutation, returns information, and adds details about output structure (category-bucketed examples with tool+argument shape). 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?

Description is slightly long but front-loaded with common query examples and every sentence adds value. Could be slightly more concise but no redundancy.

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

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

For a tool with one optional parameter and no output schema, the description fully covers purpose, usage, parameter semantics, and behavioral context. Complete and actionable.

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

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

Schema covers 100% of the single parameter. Description adds significant value by enumerating acceptable topic values and explaining the effect of omitting vs. specifying a topic.

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

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

The description clearly states it is the onboarding entry point for 'What can I ask Pipeworx?', returns categorized example questions, and distinguishes from sibling tools like ask_pipeworx and compare_entities. It uses specific verbs and resources.

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

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

Explicitly says 'Use this FIRST when you do not yet know what Pipeworx can do for you, or to learn how to call the meta-tools'. Provides guidance on optional topic parameter and when to omit for full spread.

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?

Aligns with annotations (non-destructive, idempotent) and adds key context: soft-delete behavior and historical data availability. No contradictions.

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

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

Two sentences covering purpose, constraint, and side effect. No wasted words, information density is high.

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

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

Complete for a simple mutation tool: covers function, ownership, idempotency, impact on data, and relation to other tools. No gaps given annotations and single parameter.

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

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

Single parameter 'id' with schema giving type and provenance. Description adds ownership context (must be your subscription), slightly increasing semantic value beyond baseline 3.

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

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

Description states 'Cancel a subscription by id' with specific verb and resource. Ownership enforcement and soft-delete behavior distinguish it from sibling tools like 'subscribe' and 'list_subscriptions'.

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

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

Explicitly states ownership enforcement ('you can only cancel your own subscriptions') and explains the non-destructive effect (deactivated, not deleted) with a pointer to 'recent_alerts' for historical data.

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

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

Beyond the readOnly/openWorld/idempotent annotations, the description discloses critical behavior: the meaning of each verdict, the special non-evidentiary status of 'could_not_verify', the definition of 'unsupported', the fallback routing between structured and grounded pipelines, and the performance benefit of replacing multiple calls. This is substantial additional 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 well-structured and front-loaded with natural-language triggers. Every sentence adds value: usage scenarios, path routing, return values, error semantics, and efficiency gains. No fluff or redundancy; 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?

Despite lacking an output schema, the description fully explains return values (verdicts, actual value, citation, reasoning) and error behavior (verification_error, could_not_verify vs unsupported). It covers the main use cases and edge cases, making it self-sufficient 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?

Schema coverage is 100% and the schema already provides detailed descriptions for both parameters (claim examples, tolerance_pct range/default/use cases). The description adds only marginal extra meaning (e.g., 'exact percent-delta math'), so it does not significantly surpass the schema 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 purpose: natural-language claim verification against authoritative sources, with specific verb ('verify') and resource ('claim'). It differentiates from siblings by scoping to claim verification and explicitly stating it replaces multi-step sequential calls, making its role distinct from research or search 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 gives explicit when-to-use guidance ('Use whenever the agent needs to check whether something a user said is factually correct') and distinguishes between company-financial claims (structured path) and other claims (grounded pipeline). However, it does not explicitly name alternative tools or state when not to use this tool, 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.