Artsmia

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

Annotations already declare read-only, non-destructive. The description adds: default model, fee structure for Anthropic calls, and the structure of the return value (per-model fields + combined view). This provides sufficient transparency about behavior and outputs.

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

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

The description is three sentences long, each sentence serves a purpose: action, model options, return structure and use cases. No redundant words.

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

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

Given no output schema, the description adequately describes the return format (per-model and combined view). It covers key aspects of usage and parameters, but could mention error handling or rate limits for completeness.

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

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

Schema coverage is 100% with parameter descriptions, but the description adds value by explaining the interaction between models and _apiKey, and clarifying the purpose of the context parameter. This goes beyond the schema descriptions.

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

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

The description clearly states that the tool probes LLMs for knowledge about an entity and returns visibility scores per model. It distinguishes from sibling tools like ask_pipeworx or deep_research by focusing on AI visibility auditing.

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

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

The description explicitly lists use cases (AI-marketing audits, pre-launch brand checks, competitive monitoring). It explains default vs. BYO model. However, it does not explicitly state when not to use it or compare directly to siblings, so a slight deduction.

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 reveals concrete behavior beyond the readOnly/openWorld/idempotent annotations: it routes to one of 5,798 tools across 1,517 sources, fills in arguments, and returns structured answers with citation URIs. This gives the agent a realistic model of what happens when the tool is invoked, and it does not contradict the annotations.

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

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

The description is front-loaded with the core usage directive and then provides concrete examples and escalation guidance. It is longer than strictly necessary, with some repetition around preferring this over web search, but the structure is clear and each section serves a routing purpose.

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

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

For a broad general-purpose ask tool with rich annotations and a fully documented schema, the description covers when to use it, what it does, and when to step up to siblings. It does not deeply describe the output shape beyond 'structured answer with citation URIs,' but that is sufficient for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100%: the schema fully documents the 'question' parameter and all aliases (q, text, input, query, prompt). The description adds helpful examples of natural-language questions, but it does not provide additional semantic detail about the parameters beyond what the schema already states, so the baseline score of 3 applies.

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

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

The description opens with a clear directive, 'PREFER OVER WEB SEARCH,' and explicitly states that the tool routes factual questions to the right source and returns structured answers with stable pipeworx:// citation URIs. It differentiates itself from siblings like ask_pipeworx_grounded and deep_research by positioning itself as the default 'START HERE' tool for most questions.

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 trigger phrases ('what is', 'look up', 'find', 'get the latest', 'how much', 'current'), a list of covered domains, and explicit escalation conditions to ask_pipeworx_grounded and deep_research. The description also says 'even if web search could also answer it,' making the decision boundary clear.

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

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

Annotations already mark the tool read-only, idempotent, and non-destructive. The description goes beyond these by disclosing that candidate routing improvements may be live during tests, that no candidate is currently active as of 2026-07-26, and that it does not fall back to anything—it is a fully working router in its own right. This is strong behavioral context for an experimental tool.

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

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

The description is four sentences with each contributing relevant context: identity, current experimental state, usage guidance, and fallback behavior. It is slightly dense with repeated references to ask_pipeworx and the same-tools phrasing, but remains focused and well organized.

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

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

The description covers what the tool is, its current routing state, how to use it, and that its response shape matches ask_pipeworx. Since there is no output schema, mentioning the response shape is helpful, though a fuller standalone explanation of what ask_pipeworx returns would make it more self-contained.

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

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

Schema description coverage is 100%, and the schema already documents the question parameter plus all aliases. The description adds only that the tool accepts the same arguments as ask_pipeworx, which is useful but does not provide additional parameter-level meaning beyond what the schema already supplies.

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 ask_pipeworx_beta as a beta version of ask_pipeworx and calls it an identical universal router with 5,798 tools, same arguments, and same response shape. It distinguishes it from the stable ask_pipeworx by its experimental routing edge, though it relies somewhat on the reader already understanding what ask_pipeworx does.

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

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

The description explicitly says to use it exactly like ask_pipeworx when you want the newest routing, and mentions that results are compared against the stable router. It does not explicitly state when not to use it, such as for stable/production needs, but the experimental framing makes the intended use case reasonably clear.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive, so the safety profile is covered. The description adds substantial behavioral context beyond that: exact return shape, explicit refusal semantics with enumerated refusal_reason values, the constraint that answers must come only from tool result content, and the extra LLM call cost. This fully informs the agent about runtime behavior.

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

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

The description is dense but every sentence earns its place: purpose, routing, extraction rule, return/refusal format, when to use, and cost trade-off. Key differentiators are front-loaded in the first phrase, and no filler or redundant restatement of the schema is present.

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

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

Given there is no output schema, the description compensates by explicitly documenting both success and refusal return shapes. It also covers failure modes (no_tool_match, tool_error, data_truncated, etc.), which is unusual and valuable. The only required parameter is a natural-language question, and the description leaves no ambiguity about how the tool behaves in edge cases.

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

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

The input schema already documents the question parameter and all its aliases at 100% coverage, so the baseline for schema compensation is met. The description does not add new parameter-level semantics, but it also does not need to; the schema is sufficient. It reinforces the question-based interaction but adds no extra syntax or formatting guidance.

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

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

The description states a specific mode ('Hallucination-resistant answer mode') with a concrete resource ('high-stakes reads') and a precise behavior: extract answers using only the tool result. It explicitly distinguishes itself from ask_pipeworx by describing the same routing but an additional extraction step, so an agent can select it unambiguously.

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 usage criteria: 'Use whenever an answer will be quoted, cited, or acted on' and lists concrete high-stakes domains. It also gives an exclusion rule with the alternative: 'prefer ask_pipeworx for casual lookups.' This is clear when-to-use and when-not-to-use guidance, including cost trade-offs.

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

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

Annotations already indicate readOnly, idempotent, non-destructive. The description adds extensive behavioral detail: resolver contract (confidence levels, alternatives), parent event extraction, news fallback handling, safety short-circuit for low-confidence, closed market handling, wide-spread illiquidity, and resolution-rule risk. These go far beyond the annotations.

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

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

The description is very long and detailed, bordering on verbose. While it is well-structured with headers (RESOLVER CONTRACT, PARENT_EVENT EXTRACTOR, etc.), not every detail is essential for tool selection. It could be more concise while retaining 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 3 parameters, no output schema, and the tool's complexity, the description covers all aspects: input, fan-out logic, output shapes, edge cases (closed markets, low confidence, wide spread), and resolution rules. It leaves very little ambiguity.

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 each parameter description is clear. The description adds extra context: market parameter accepts slug, URL, or question text; depth defaults thorough; include_raw defaults false with explanation of when to set true. This enriches 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 researches a Polymarket bet by pulling Pipeworx data in one call. It specifies input types (slug, URL, question text) and what it does (resolves market, classifies, fans out, returns evidence and comparison). This is specific and distinct from sibling tools like deep_research or ask_pipeworx.

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

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

Explicitly says 'Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z"' – clear use cases. Lacks explicit when-not-to-use or direct alternatives, but given the tool's specificity, it's adequately scoped.

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 context beyond annotations, detailing data sources (EDGAR/XBRL for companies, FAERS for drugs), handling of fiscal year offsets, sorting by primary metric, and 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 informative and well-structured, but slightly verbose with example phrases. Each sentence adds value, though minor trimming could improve conciseness.

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

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

Given the tool's complexity (two entity types, multiple data sources) and no output schema, the description covers purpose, triggers, usage preference, entity specifics, data details, sorting, and return format. Complete for agent decision-making.

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 by explaining valid parameter values (tickers/CIKs for company, names for drug), constraints (2-5 items), and data retrieval behavior for each type.

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's purpose: side-by-side comparison of 2-5 companies or drugs in one parallel call. It provides clear trigger phrases and distinguishes from sequential single-pack lookups.

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

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

The description explicitly advises 'ALWAYS PREFER over sequential single-pack lookups when comparing entities.' It also provides natural language examples to guide when to use the tool.

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

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

Annotations already mark it read-only and non-destructive; the description adds substantial behavior beyond that: account requirements, paid tier restriction, parallel decomposition across tools, gap handling, contradiction scanning, latency expectations, and citation fetchability semantics. No contradiction with annotations exists.

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 information-dense; each sentence introduces a new operational fact (pricing, decomposition, gaps, citations, latency). It is front-loaded with the access gate and fallback. Slight over-density from cramming many clauses into a few sentences, but no filler.

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

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

Given no output schema, the description covers return format (evidence, confidence, source, fetched_at, citation URI, gaps, contradictions), execution behavior (parallel routing, excerpting), access limits, and latency. For a complex research tool this is remarkably complete — an agent can predict what will happen and what it will get.

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

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

The input schema already documents both parameters at 100% coverage, so the description didn't need to re-explain them. Still, it enriches the 'depth' parameter with tier-specific behavioral consequences (hops, contradiction scan, paid requirement) and clarifies that 'question' can be multi-part. This exceeds baseline schema-only meaning.

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

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

The description identifies a specific verb ('research'), a distinct resource (Pipeworx's structured data sources vs open-web search), and a clear deliverable (findings packet with citations and gaps). It explicitly contrasts itself with ask_pipeworx and open-web search, preventing confusion with 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?

Explicitly states when to use this tool ('broad/multi-part questions over structured data') and when to use the alternative (single lookups → ask_pipeworx). It also gives a sign-in conditional, routing unsigned-in users to ask_pipeworx. This is ideal guidance for an agent.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds behavioral context beyond these: it reveals that results rank imaged objects first and that the tool is 'keyless' (no API key required), which is useful for an AI agent.

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

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

The description is extremely concise—one sentence plus a list of departments—with no wasted words. It is front-loaded with the key action and sorting behavior.

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

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

For a simple browse tool with two parameters, rich annotations, and no output schema, the description is adequately complete. It defines purpose, sorting, department list, and keyless access. Omission of pagination or return format is acceptable given low complexity.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema; the 'keyless' note is about tool access, not parameter semantics. The schema already provides parameter descriptions and examples.

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

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

The description clearly states the action ('Browse artworks'), the resource ('Minneapolis Institute of Art curatorial department'), and the sorting behavior ('imaged objects ranked first'). It provides a list of example departments, making the purpose specific and unambiguous.

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

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

The description includes 'Keyless' to indicate no authentication is needed, but does not explicitly state when to use this tool versus alternatives like 'search_artworks'. Usage context is implied but not explicitly directed.

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

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

Description adds value beyond annotations: explains return format (top-N tools with names, descriptions, full schemas, curated examples) and that results are ready to call directly. No contradiction with annotations.

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

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

Description is somewhat long but well-structured: purpose first, then usage guidance, then output explanation. Every sentence 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 no output schema and 6 params (mostly aliases), description fully explains input (query aliases, limit) and output (top-N tools with schemas, ready to call). Complete for a search/discovery 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% (baseline 3). Description adds meaning by listing query aliases (task, q, search, description) and specifying limit default/max, plus example queries. Adds context beyond schema.

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

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

Description explicitly states the tool finds tools by describing data/task, lists specific use cases (SEC filings, financials, FDA drugs, etc.), and distinguishes from siblings by being the discovery tool for browsing available 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?

Clearly says 'Call this FIRST when you have many tools available' and implies use for browsing/searching. Does not include explicit exclusions but provides strong context.

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

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

Beyond the readOnly/idempotent annotations, the description discloses valuable behavioral details: the tool fans out across many sources in parallel, returns sources_used/sources_failed, treats empty sections as real no-data results, and returns resolved:false with a notes line for private companies rather than raising a bare failure. This gives the agent an accurate model of what the tool will and will not 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 this is justified by the tool's breadth: it covers many data sources, return fields, input forms, and edge cases. It is front-loaded with the main purpose and usage rule, though the dense one-paragraph structure makes scanning harder than it could be with lists or headings.

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

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

With no output schema available, the description carries the full burden of explaining return values, and it does so thoroughly: CIK, resolved_from/resolved_to, recent_filings with URIs, fundamentals, patents, contracts, FDA products, hiring, news, LEI, and source success/failure reporting. It also covers the private-company case and input flexibility, so an agent has enough context to call 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?

The input schema already documents both parameters thoroughly, including that type accepts company/ticker interchangeably and value accepts ticker, CIK, or company name. The description mostly echoes this same guidance, with minor additions like the private-company resolved:false behavior, which is more about output semantics than parameter meaning.

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

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

The description opens with concrete user phrasings and immediately states the core action: full cross-source profile of a US public company in ONE parallel call. It clearly distinguishes this tool from narrower single-pack SEC/XBRL/news lookups and sibling tools like resolve_entity.

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

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

The description explicitly says to ALWAYS PREFER this tool over chaining single-pack lookups when the user asks for a holistic view. It also tells the agent what inputs are acceptable, how name resolution behaves, and what happens for private companies, leaving no ambiguity about when and how to invoke 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 provide destructiveHint and idempotentHint. The description adds context about clearing sensitive data and stale context, which is valuable beyond annotations. No contradictions.

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

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

Two concise sentences with front-loaded purpose, followed by usage guidelines. Every sentence serves a clear purpose 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?

The description covers purpose, usage, and partners for a simple one-parameter tool. It is mostly complete, though minor details like key matching behavior are omitted.

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

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

Schema coverage is 100% with the 'key' parameter described as 'Memory key to delete'. The description adds no extra parameter details beyond the schema, so baseline score applies.

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

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

The description clearly states 'Delete a previously stored memory by key' with a specific verb and resource. It distinguishes itself from siblings 'remember' and 'recall', making the purpose unambiguous.

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

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

Explicit guidance on when to use: 'when context is stale, the task is done, or you want to clear sensitive data'. Also mentions pairing with siblings, providing 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable context: it fetches the page, extracts title/description/key links, and outputs standard markdown format. This goes beyond the annotations and clarifies the process.

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 (3-4 sentences) and front-loaded with the core action. Every sentence adds value, covering the action, process, output format, and use cases without unnecessary elaboration.

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 relatively simple tool with comprehensive schema and annotations, the description is fully complete. It covers the input, process, output, and practical applications, leaving no gaps for the agent to infer.

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

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

Both parameters are fully described in the schema (100% coverage), so the description has no need to add extra semantics. The tool description does not provide additional parameter context beyond what the schema already offers.

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 action ('Generate'), the resource (llms.txt), and the context (AI crawlers). It distinguishes itself from sibling tools by focusing on file generation, which no other tool does.

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

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

The description provides explicit use cases (client indexing, personal projects, competitor auditing), giving clear context for when to use. However, it does not mention when not to use or compare directly with alternatives like ai_visibility_check.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds 'Keyless' (no auth) and lists returned fields, which provides some extra behavioral context but no further details on rate limits, error handling, or output 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?

Two concise sentences, front-loaded with purpose. Every word contributes value: states action, resource, fields, and keyless nature. No verbosity.

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

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

For a simple get-by-id tool with one parameter, strong annotations, and no output schema, the description fully covers what the tool does, required input, and key behavioral hints (keyless). No gaps.

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

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

Schema coverage is 100% with a clear description and example for the 'id' parameter. The description reinforces that the id is numeric and relates to a collection object, but adds no new meaning beyond what the schema provides.

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

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

The description clearly states the tool retrieves full details for one object by numeric collection id, listing specific fields (title, artist, etc.). It distinguishes from siblings like 'search_artworks' by focusing on a single, known object.

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 implies use when a specific numeric id is known ('by its numeric collection id') but does not explicitly state when not to use or name alternatives. The 'Keyless' hint is helpful. Sibling awareness is not directly addressed.

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

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

Annotations already declare readOnly, idempotent, non-destructive. Description adds behavioral nuance: by default returns only active subscriptions, and lists specific return fields. 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 concise sentences: first states purpose and output, second provides usage guidance. No redundant information. Efficient and well-structured.

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

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

Given no output schema, the description lists return fields. One parameter with full schema documentation. Usage guidance completes the picture for an agent to decide when to invoke. Fully sufficient.

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

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

The description mentions 'active subscriptions' implying default behavior, which complements the documented optional include_inactive parameter. Adds clarity on default filter even though schema coverage is 100%.

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

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

The description clearly states it lists active subscriptions and enumerates the returned fields (id, type, etc.). It distinguishes from siblings like subscribe and unsubscribe by focusing on reading existing 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 usage guidance: use to review monitoring before adding more or to find an id for cancellation. Implicitly contrasts with subscribe/unsubscribe. 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?

Goes beyond the sparse annotations (all false) by disclosing the claim_token flow, rate limit ('Rate-limited to 5 per identifier per day'), and that it's free and doesn't count against quota. This gives the agent a clear picture of side effects and expectations.

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

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

The description is lengthy but every sentence delivers distinct value: purpose, use cases, exclusions, formatting guidance, token mechanics, rate limit, and cost. It is front-loaded with the core purpose in the first sentence, though it could be slightly more compact.

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

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

Despite having no output schema, the description covers purpose, scope, exclusions, the claim_token return, rate limits, and cost. It is complete for a tool of this complexity and leaves no major ambiguity about behavior or usage.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaningful context for the message parameter (describe in terms of Pipeworx tools, don't paste end-user prompt) and explains claim_token usage ('pass it back later as pipeworx_feedback({claim_token:"pwfb_…"})'), which enriches semantics beyond the schema.

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

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

The description clearly states the tool's function: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It enumerates specific feedback types (bug, feature, data_gap, praise) and distinguishes it from sibling tools like ask_pipeworx or 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?

Provides explicit when-to-use guidance ('Use when a tool returns wrong/stale data...'), when-not-to-use with a concrete alternative ('if the tool came from a different MCP server... file it with that server instead'), and instructions on how to frame feedback.

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 destructiveHint=false. The description adds valuable behavioral context: self-aggregating signal from CF analytics-engine, no PII, and caching behavior (5min-1h). No contradiction with annotations.

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

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

Description is three sentences: first explains what it returns, second lists use cases, third adds data source and caching. Front-loaded with key info, no fluff. 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?

The description covers purpose, usage, behavior, and parameters well. However, since there is no output schema, the return format is only vaguely described as 'top tools, top packs, and total call volume'. It could be more explicit about the response structure (e.g., sorted lists with counts). Still, overall complete for a simple trending 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?

Only one parameter (window) with 100% schema description coverage. The description adds meaning beyond the enum by explaining when to use each window: shorter for hot trends, longer for steady-state demand. This helps the agent choose appropriately.

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

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

Description clearly states the tool returns top tools, packs, and call volume over a window. The verb 'Returns' is specific, and the resource (Pipeworx trending data) is unambiguous. It distinguishes from siblings like discover_tools and ask_pipeworx by focusing on trending usage data.

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

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

The description provides three explicit use cases: discovering hot data sources, confirming canonical tool, and checking alignment. It also notes caching and data source. However, it does not explicitly state when not to use or mention alternatives, though the sibling list provides 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?

Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds extensive behavioral context including the filtering logic (Jaccard similarity threshold, placeholder fraction filter), the fill check mechanism against live order book depth, and the response structure. No contradictions with annotations.

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

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

The description is thorough but somewhat verbose. While all information is relevant, there is some repetition (e.g., partition_check explanation appears in both event and topic sections). It is well-structured conceptually but could be tightened without losing clarity.

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 modes, filters, fill check), the description is complete. It covers all modes, explains response fields, provides examples, and references another tool (polymarket_fill_risk) for custom sizing. No output schema exists but return values are sufficiently described.

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

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

Schema coverage is 100%, so baseline is 3. The description adds significant value beyond schema: it explains the semantic difference between event and topic parameters, accepts full URLs for event, provides example slugs and seed questions, and describes how parameter choice affects the scan behavior.

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

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

The description clearly states the tool's purpose: finding arbitrage opportunities on Polymarket via monotonicity violations and partition-sum checks. It distinguishes itself from siblings by specifying three distinct modes (trending scan, event mode, topic mode) and explicitly referencing related tools like polymarket_fill_risk for custom sizing.

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

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

The description provides explicit guidance on when to use each mode: no args for trending scan, event for specific market slug, topic for cross-event scanning. It explains recommended usage, gives example inputs, and clarifies when to avoid trading based on fill check results.

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 extensive behavioral context: caching at KV level keyed on all knobs, model family details, diagnostics structure, fed notes, and edge metrics. 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 very long (~400 words), but well-structured with clear sections using capitalized segment names and parentheses. It front-loads purpose and then details each segment and knob. Could be more concise, but every sentence adds 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 9 parameters and no output schema, the description is remarkably complete. It explains the three response segments, edge metrics, tradeable-edge knobs, diagnostics for empty segments, and caching behavior. No apparent gaps.

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

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

Schema coverage is 100%, but description adds significant value for each parameter, e.g., slippage_pp explains Polymarket fees, min_partition_leg_kelly explains basket trade behavior. Some repetition exists but overall enhances understanding.

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

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

The description clearly states it scans Polymarket markets for opportunities where data disagrees with market price, explicitly targeting 'what should I bet on today' use case. It distinguishes from siblings by focusing on edge opportunities from model-driven and structural arbitrage, not arbitrage or fill risk.

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

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

The description provides explicit when-to-use context: agents discover opportunities without paging hundreds of markets. It implies usage through tradeable-edge knobs and caching, but doesn't explicitly state when not to use or compare directly to siblings like polymarket_arbitrage or polymarket_fill_risk.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds significant behavioral details: LIMITS on history depth (60-day TTL, snapshot start), decay calculation from daily closes (not intraday), and response structure (tracked, expired, snapshot_dates). 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 well-structured and informative, front-loading the core purpose. It contains some technical details but every sentence adds value. Could be slightly trimmed for brevity.

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 the response shape (tracked, expired, snapshot_dates) and provides limits and parameter details. It is complete for the tool's complexity.

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

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

Schema coverage is 100%, but the description adds defaults (days=14, window='1wk'), valid ranges (days clamp 2-30), and clarifies window as 'snapshot family' with listed options (24hr, 1wk, 1mo). This adds meaning 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 it provides edge persistence and decay telemetry from daily snapshots, answering 'how long has this edge existed and is it shrinking?' The verb-resource pair is specific and distinguishes from siblings like polymarket_edges.

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

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

The description gives context on when to use by contrasting fresh vs old edges, but does not explicitly mention when not to use or name alternative tools. The implied use case 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, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds critical behavioral context: partial basket fills convert an arb into an unhedged directional position, and explains the 'thin_legs' and 'forced_directional_risk' outputs. This goes beyond annotations.

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

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

The description is long but well-structured with clear headings (SINGLE-MARKET, BASKET) and a usage warning at the end. Every sentence provides necessary detail for a complex two-mode tool. Could be slightly shorter but the structure aids readability.

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

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

Given the tool's complexity (two modes, no output schema), the description comprehensively explains return fields for both modes: top_of_book, vwap_fill_price, slippage_pp, shares_filled, max_fillable_usd, verdict for single-market; theoretical_sum, realizable_sum, capture_ratio, profit_usd, per-leg fill detail, thin_legs, max_clean_notional_usd, forced_directional_risk for basket. Complete.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds significant value: explains how size_usd is interpreted differently for single-market (spend/proceeds) vs basket (settlement notional), side defaults to auto for basket, and clarifies the difference between market and event parameters. This is above baseline.

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

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

The description clearly states the tool's purpose as a realizable-vs-theoretical edge check against live order-book depth. It distinguishes two modes (single-market and basket) and explicitly differentiates from sibling tools like polymarket_arbitrage and polymarket_edges.

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

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

The description provides explicit usage guidance: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500.' It also explains why (theoretical overround on thin books is not capturable, partial fills lead to unhedged positions) and warns about the dominant loss mode.

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 read-only/idempotent annotations, the description discloses all key behaviors: compatibility_codes can be non-empty even when pairs match, pairing_unverified is always set, temporal_alignment null means unknown rather than aligned, Kalshi fees are not modeled, and unknown leg types are never paired. This materially changes how an agent should interpret returned results.

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

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

The description is long but well organized, moving from purpose to modes to response shape to safety fields to caveats. A few redundancies, such as repeatedly noting 'EITHER mode' and restating matcher identity, add length, but the structure is front-loaded and every major section earns its place for a caveat-heavy tool.

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

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

Even without an output schema, the description fully defines the response anatomy: leg-by-leg prices, top_spreads_pp, compatibility_warning and compatibility_codes, temporal_alignment, fees_note, and skipped counters. It explains ambiguous values such as null alignment and unclassified legs, giving an agent enough context to call the tool correctly and interpret results safely in either mode.

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 adds useful interaction semantics: it names the two modes, explains that explicit ticker/slug override topic mapping, and states that both modes run the identical token-overlap matcher with the same disclosures. It reinforces rather than radically extends the schema, but the added mode context is valuable.

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 first sentence names an exact resource and task: 'Cross-venue spread between Kalshi and Polymarket for the same resolving question.' The description then clarifies the two invocation modes, the output structure, and how it differs from a simple single-venue price lookup, making its 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?

The description gives clear when-to-use guidance: topic shortcuts for pre-mapped macro events, explicit ticker/slug for custom pairings, and a warning that pre-mapped does not mean tradeable and that gross spread is not a net edge. It does not explicitly name a sibling alternative or say when another tool should be used instead, so it stops short of full 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 already provide readOnlyHint, destructiveHint, idempotentHint. The description adds behavioral context beyond annotations: scoping to identifier, and the relationship with remember/forget. 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?

Three sentences: first states core function, second gives use case, third adds scope and pairing. No unnecessary words. Front-loaded with key info.

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

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

The description is complete for a simple tool with one optional parameter and clear annotations. It explains behavior with and without key, scope, and relationship to siblings. No missing elements.

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

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

Schema coverage is 100% with a clear description for the single optional 'key' parameter. The tool description adds context about omitting key to list all keys, reinforcing schema. Baseline 3 with extra context earns a 4.

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

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

The description clearly states the tool's purpose: 'Retrieve a value previously saved via remember, or list all saved keys (omit the key argument).' It uses specific verbs and resource, and distinguishes from sibling tools '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?

The description provides clear usage context: 'Use to look up context the agent stored earlier' with examples. It implicitly differentiates from siblings by pairing with remember and forget. However, it lacks explicit when-not-to-use guidance.

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

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

The description includes 'Set mark_read:true to flag returned events read', which indicates a write operation (modifying event state). However, the annotations declare readOnlyHint=true, suggesting no writes. This is a direct contradiction. The description is transparent about the behavior, but conflicts with the annotation, causing confusion.

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

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

The description is fairly concise, covering purpose, return content, parameters, and a usage hint in a few sentences. It is front-loaded with the main action. However, some information (like the alternative endpoint) could be considered secondary, but overall it 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?

No output schema is provided, but the description explains return values (source, citation_uri, raw payload). It covers all parameters with behavioral context, mentions polling suitability, and provides an alternative access method. For a tool with 5 optional parameters and no output schema, this is thorough.

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

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

Schema coverage is 100%, but the description adds significant value beyond the schema: it explains the effect of mark_read (so next call shows only newer events), provides an example for the type parameter ('sec_8k'), and clarifies that since expects an ISO timestamp. This enriches the parameter understanding.

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

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

The description clearly states the tool pulls fired events from a subscription feed, specifying the resource and action. It distinguishes itself by mentioning the feed's content (source, citation_uri, raw payload) and provides concrete usage examples (filtering by type and since). The purpose is specific and unambiguous.

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

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

The description mentions an alternative access method (GET endpoint for scripts/dashboards) and implies polling works, but does not explicitly compare with sibling tools or specify when to use this tool versus others like 'list_subscriptions' or 'subscribe'. The guidance is limited to the alternative endpoint, not direct usage against siblings.

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 multi-source fan-out (SEC, GDELT→GNews, USPTO), fallback behavior, and soft-failure for USPTO. Annotations already mark it as read-only and idempotent; description adds specific behavioral details beyond those hints.

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

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

Single dense paragraph with no wasted words. Front-loaded with example queries, then logically flows to sources, parameters, output, and sibling comparison. Every sentence serves a purpose.

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

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

Given no output schema, description adequately explains return structure (changes[] grouped by source, total_changes, citation URIs). Covers source behaviors, parameter options, and fallback logic. Missing details like rate limits are implicitly handled by fallback description.

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 value by explaining accepted 'since' formats (ISO date or relative like '7d') and showing example ticker/CIK for 'value', enhancing usability.

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 aggregates recent changes (SEC filings, news, patents) in one parallel call, with specific query examples like 'What's new with X'. It distinguishes from sibling entity_profile, which is for static profiles.

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

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

Provides explicit usage contexts (e.g., 'what happened to Z this week') and directs to entity_profile for static data. Could be more explicit about when not to use this tool, but the guidance is clear overall.

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 key behavioral traits beyond annotations: scoped by identifier, persistent for authenticated users, 24-hour retention for anonymous. Annotations indicate idempotentHint=true, and description implies overwriting behavior without contradiction.

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

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

Three sentences, no unnecessary words, front-loaded with core purpose, efficiently covers scope and pairing with siblings.

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

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

For a simple two-parameter tool with no output schema, the description covers storage scope, duration, and retrieval/deletion operations, making it self-contained and sufficient.

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

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

Schema coverage is 100% with clear parameter descriptions. Description adds modest context (examples for key patterns, value types) but does not significantly enhance understanding beyond the schema.

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

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

Description clearly states the tool's purpose: 'Save data the agent will need to reuse later', specific verb+resource (save data), and distinguishes from sibling tools 'recall' and 'forget' which are mentioned for retrieval and deletion.

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 provides examples. Mentions pairing with recall and forget but does not explicitly state when not to use, though it's implied.

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

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

Annotations already mark it read-only and idempotent; the description adds substantial behavioral detail: internal cascading through several lookup endpoints, graceful degradation when GLEIF/OpenFIGI are unavailable, and coverage of non-equity instruments and non-US issuers through ISIN. It also describes the drug citation format returned.

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 informative, but it contains a duplicated clause about non-equity instruments resolving, which is redundant. It is a long single block rather than organized, though the front-loaded query examples help.

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

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

With no output schema, the description explains return values (CIK, ticker, LEI, FIGI, RxCUI, brand, citation) and failure degradation for unavailable sources. It does not describe behavior for ambiguous or unresolvable names, a small but meaningful gap.

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

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

Schema coverage is 100%, so baseline is 3. The description enriches the value parameter with important context: accepted inputs include ISIN, and the entity-name-only rule prevents failed FIGI lookups on bonds. This goes beyond the schema's terse type 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 names a specific operation — resolving a user-spoken name to canonical/official identifiers — and lists the exact identifier types returned for both company and drug. It also gives concrete triggering queries ('find the CIK for…'), making its purpose unmistakable and distinct from siblings like entity_profile or compare_entities.

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

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

The instruction 'Use FIRST whenever you have a name but need an ID' provides a clear context for when to invoke the tool, and the value parameter guidance warns against sending full noun phrases. It does not explicitly name alternative tools or state when not to use it, so it falls just short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, indicating safe read behavior. The description adds value by detailing the internal process (calls ai_visibility_check, ranks, returns score, confidence, signal density) and the fact it probes multiple entities. 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 three sentences long, with the core action front-loaded: 'Compare AI visibility across multiple entities side-by-side.' Each sentence adds information without redundancy. It is efficient and well-structured.

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

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

The description explains what the tool returns (ranked list with score, confidence, signal density) and how it works (probes each entity). With no output schema, this is sufficient. It could mention ordering, but overall it provides enough context for an agent to understand inputs and outputs.

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 4 parameters have descriptions). The description adds context that 'entities' first entry is the subject, which is not explicit in schema. It also explains the overall workflow, adding value beyond the schema. Baseline 3 is raised due to this additional clarification.

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 action: 'Compare AI visibility across multiple entities side-by-side.' It specifies it probes each entity using ai_visibility_check, ranks by score, and surfaces most/least recognized. This distinguishes it from sibling tools like ai_visibility_check (single entity) and compare_entities (general comparison).

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

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

The description provides explicit use cases: 'Useful for competitive AI-marketing audits: "does Claude know about us as well as our competitors?"'. It implies when to use this tool (multi-entity comparison) but does not explicitly state when not to use or mention alternatives, though the sibling context provides that.

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 partial failure behavior, timing (5-30 seconds for bundlephobia first measurement), and that sources_failed will list timeouts. Adds context beyond annotations.

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

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

The description is detailed but front-loads the core purpose. Every sentence adds value, though slightly verbose.

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 lists return fields (summary block, per-advisory detail, links, alternative versions). Covers failure modes, ecosystem scope, and behavior. Highly 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?

The description adds meaning beyond the input schema: explains scoped packages are accepted, defaults to latest version, and ties parameters to the composite check context. Schema coverage is 100% but description enriches understanding.

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

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

The description clearly states it is a composite check for npm packages, covering license, advisories, version history, bundle size, and more. It distinguishes from siblings by specifying the ecosystem and what it replaces.

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: when an agent asks about safety, popularity, size, or cost of adding an npm package. Also provides alternatives 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 readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds that the tool is 'Keyless' (no auth required) and lists return fields (artist, date, medium, gallery location, image URL), providing useful behavioral context beyond annotations.

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

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

Three sentences with no wasted words. Front-loaded with purpose, then syntax, then return fields. 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 no output schema, the description adequately explains what the tool returns. It mentions collection size and keyless access. Minor omission: no mention of pagination, but limit parameter addresses this partially.

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 all parameters have descriptions. The description reinforces parameter usage with examples (e.g., artist:"Van Gogh") and notes default limit of 10 and max 25, adding value beyond the schema.

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

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

The description clearly states 'Search the Minneapolis Institute of Art collection (~90k objects)', which specifies the verb 'search' and the resource 'collection'. It distinguishes from siblings like get_artwork and search_within by focusing on free-text and ES field syntax across the full collection.

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 examples and explains acceptable syntax (free text or ES field syntax), implying usage for general collection search. However, it does not explicitly mention when to use this tool over siblings (e.g., search_within, get_artwork) or specify 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 provide readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds technical details: BGE-base-en embeddings, cosine similarity over 500-char windows, 200K char cap with truncation flag, and return structure (offsets, similarity scores). 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?

Single paragraph with front-loaded purpose: first sentence defines core function. Then use case, pairing, and technical details. Every sentence adds value, no wasted words.

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

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

Given the complexity (semantic search, truncation, offsets, grounding pairing), the description covers all essential aspects. No output schema exists, but the description explains return includes passages with offsets and similarity scores, which is sufficient.

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

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

Schema coverage is 100%, so baseline is 3. The description adds extra meaning: explains that 'text' is the document text, 'query' is natural-language with examples, and 'limit' has default and range. It also adds behavioral context about truncation.

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 'Semantic search INSIDE a fetched record' with a specific verb ('search inside') and resource ('record text'). It also distinguishes from siblings by mentioning pairing with ask_pipeworx_grounded.

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

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

Explicitly tells when to use: 'Use when the record is too big to cram into the prompt.' It also describes pairing with ask_pipeworx_grounded for grounding, providing 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?

Annotations (readOnlyHint=false, destructiveHint=false) indicate mutation but no destruction. The description adds significant behavioral context: requires OAuth, SMS caps, email verification, webhook signing, and auto-disable after 10 failures. 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 the primary purpose and return value. While it is lengthy, every sentence adds essential context, making it efficient despite 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 (3 parameters, nested objects, no output schema), the description covers return value, type details, delivery options, and constraints. It lacks error handling details but is otherwise comprehensive.

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 value beyond the schema by providing concrete JSON examples for each type and clarifying constraints like phone verification and SMS limits. This enriches agent understanding.

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

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

The description clearly states the tool creates a proactive monitoring subscription to a live-data event stream and returns the subscription id. It distinguishes from siblings by detailing specific subscription types and delivery channels, making the purpose unambiguous.

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

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

The description specifies when to use (e.g., for live-data event streams like 8-K filings or Polymarket edges) and prerequisites (Pipeworx OAuth account). It does not explicitly contrast with sibling tools like list_subscriptions or unsubscribe, but the context makes the differentiation clear.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds that it returns categorized examples with tool+argument shapes drawn from the live catalog, going beyond annotations.

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

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

The description is a single paragraph that is front-loaded with example queries, then states purpose, lists categories, and gives usage instructions. It packs a lot of information without being overly long, though it 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 the tool's role as an onboarding entry point, the description fully explains its behavior, output format (category-bucketed examples with tool+argument shapes), and two calling modes. With no output schema, the description adequately describes the return value.

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

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

The schema covers 100% of parameters (one optional). The description explains the effect of omitting vs providing the topic parameter and lists allowed values, adding meaning beyond the schema's description.

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

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

The description clearly states the tool returns example questions with exact tool+argument shapes, and provides example phrasings. It differentiates itself from siblings like ask_pipeworx by positioning itself as the onboarding entry point.

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' and explains how to call it with no arguments or with a topic. While it lacks explicit when-not-to-use, the guidance is clear and actionable.

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 ownership enforcement and soft-delete behavior beyond annotations. No contradiction with annotations. Adds critical details for safe invocation.

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

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

Two sentences, front-loaded with key action and constraints. No redundant words.

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

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

Given no output schema, the description adequately explains the side effect (deactivation, historical availability). No missing context for a single-param 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%, and the parameter 'id' is already described in the schema. The description adds no new semantic value beyond restating 'by id'.

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

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

Clearly states the action ('Cancel a subscription by id') with specific verb 'cancel' and resource 'subscription'. Distinguishes from sibling tools like 'subscribe' and 'list_subscriptions'.

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

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

Explains ownership enforcement and the effect (deactivation, not deletion). Provides context for when to use (only own subscriptions, historical events preserved) but lacks explicit alternatives.

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

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

The description richly discloses behavioral nuances beyond the annotations: the meaning of each verdict, the critical distinction that could_not_verify means the check did not happen and is not evidence, the unsupported meaning, and the fact that it replaces 4–6 sequential calls. This adds significant context about error semantics and fallback behavior that the annotations alone do not convey.

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

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

The description is longer than typical but every clause serves a purpose: trigger phrases, usage guidance, routing, return value semantics, and caller-important caveats. It is well-structured and front-loaded with the most actionable phrase, but the density and length prevent a perfect score for conciseness.

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

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

Given there is no output schema, the description fully explains what the tool returns: a verdict, grounded or structured actual value with citation, and reasoning. It also covers error handling (verification_error) and edge cases (unsupported), making the tool self-sufficient for an agent to understand inputs, outputs, and failure modes.

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

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

The schema has 100% coverage of both parameters (claim and tolerance_pct) with descriptive examples and constraints. The description adds contextual value by showing example claims and explaining the financial fast path with exact percent-delta math, but it does not meaningfully elaborate on tolerance_pct beyond the schema. Thus, baseline 3 is appropriate since the schema already handles 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 clearly identifies the tool's purpose: natural-language claim verification against authoritative sources, with specific trigger phrases like "fact check" and "verify the claim that." It distinguishes itself from sibling research tools by focusing on confirming/refuting factual claims and explicitly notes it replaces multi-step sequential calls, making its unique role clear.

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

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

The description explicitly states when to use the tool: "Use whenever the agent needs to check whether something a user said is factually correct." It also explains routing logic (SEC EDGAR for company-financial claims, grounded pipeline for other claims), providing clear context. However, it does not explicitly name alternatives or state when not to use this tool versus siblings, 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.