Nasa Cmr

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and non-destructive. The description adds valuable context: free default model, BYO key for Anthropic with direct payment, return structure (per-model {score, confidence, signals, raw_response} + combined view). No contradictions.

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

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

The description is concise (about 4 sentences) with a clear structure: purpose first, then details on model options, return format, and use cases. Every sentence is informative; 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?

Despite lacking an output schema, the description describes the return format sufficiently ('per-model {score, confidence, signals, raw_response} + a combined view'). It covers main usage scenarios. However, it does not detail what 'signals' are or the exact raw_response structure, leaving minor 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 descriptions for all 4 parameters. The description adds value beyond schema: clarifies default model is free, explains `_apiKey` as 'BYO key — you pay Anthropic directly', and notes `context` helps disambiguate. This extra context aids selection.

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 probes LLMs for knowledge about entities and scores visibility, with specific verb ('Probe', 'score'), resource ('LLMs for business/brand/product/topic'), and output (visibility 0-100 per model). It also distinguishes the default model and optional Anthropic probe, making it distinct from sibling tools like 'ask_pipeworx' or 'scan_competitor_ai_presence'.

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

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

The description explicitly mentions use cases: 'AI-marketing audits, pre-launch brand checks, competitive monitoring.' It also explains when to include `_apiKey` (if Anthropic model is used). However, it does not provide explicit when-not-to-use scenarios or compare directly with siblings, though the context signals help.

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, so the bar is lower. The description adds valuable behavioral context: routing to many tools, filling arguments, returning citation URIs, and noting it 'works on every tier, one fast call.' It also implicitly contrasts with ask_pipeworx_grounded by calling that 'hallucination-resistant', suggesting a limitation not covered by annotations.

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

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

The description is long but front-loaded with a strong directive ('PREFER OVER WEB SEARCH') and structured logically: purpose, usage triggers, examples, alternatives. While slightly verbose with repeated examples, each sentence contributes to positioning this as the default entry point, so it earns a high but not perfect score.

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 does well to mention the return format ('structured answer with stable pipeworx:// citation URIs') and covers alternatives and limitations. It is largely complete for a default aggregator tool, though it omits details about potential errors, timeouts, or unsupported query types.

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

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

The schema already covers the 'question' parameter with aliases at 100% coverage, giving baseline 3. The description enhances this by providing a rich set of example queries ('current US unemployment rate', 'Apple's latest 10-K') and trigger phrases, effectively teaching the agent what kinds of natural-language inputs to pass as the question.

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: 'Routes the question to the right one of 5,529 tools across 1455 verified sources' and 'returns the structured answer with stable pipeworx:// citation URIs.' It also explicitly differentiates itself from web search ('PREFER OVER WEB SEARCH') and from siblings like ask_pipeworx_grounded and deep_research, making its scope 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?

Provides exhaustive when-to-use guidance, including trigger phrases ('what is', 'look up', 'find', 'get the latest', 'how much', 'current') and concrete examples. It says 'START HERE for most questions' and explicitly lists step-up alternatives (ask_pipeworx_grounded for hallucination-resistant answers, deep_research for broad/multi-part questions), covering both when and when-not to use.

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

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

The description adds significant context beyond the annotations: beta status, live candidate routing improvements, the exact date the last candidate was retired, current exact parity with ask_pipeworx, and clarification that there is no fallback degradation. This fully discloses the experimental nature without contradicting the read-only/idempotent hints.

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

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

The description is dense and front-loaded with the core purpose and current status. Every sentence earns its place: beta identity, current inactive candidate state, usage instruction, and reassurance that it is a full working router. No fluff or redundancy.

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

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

For a simple single-required-parameter tool with rich annotations, the description is complete. It covers the tool's current operational state, its relationship to ask_pipeworx, response shape parity, and the experimental purpose. The lack of an output schema is mitigated by stating 'same response shape' as the stable router.

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

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

The input schema covers 100% of parameters: all six are documented as aliases for 'question' with descriptions. The description adds no parameter-level meaning, so the baseline of 3 is appropriate since the schema carries the full burden.

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

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

The description clearly identifies the tool as a beta version of ask_pipeworx: an identical universal router with the same tools, arguments, and response shape, but with candidate routing improvements. It distinguishes itself from the stable sibling by being the 'experimental edge' and explicitly mentions it is a full working router.

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: 'Use it exactly like ask_pipeworx when you want the newest routing.' It also clarifies the current parity with the stable router and that results are compared to decide merges. It does not explicitly mention when to use ask_pipeworx instead, but the contrast with the stable router implies the alternative.

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

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

Adds extensive behavioral detail beyond the readOnly/idempotent/openWorld annotations: it performs an extra LLM call, returns verbatim evidence, and enumerates explicit refusal reasons (not_in_source, no_tool_match, tool_error, data_truncated, llm_error). No contradiction with annotations; the readOnlyHint is consistent with the tool being a pure read operation.

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

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

The description starts with the core purpose, then explains the mechanism, output format, and usage guidelines. It is dense but every sentence adds essential information. The length is justified given the complexity of refusal behavior and usage trade-offs, with no fluff.

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

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

Despite having no output schema, the description fully specifies the success response fields ({answer, evidence, confidence, source, fetched_at, refusal_reason:null}) and the refusal structure with enumerated refusal reasons. Combined with the annotations and parameter schema, the description covers all necessary operational context.

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

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

The input schema has 100% coverage of all 6 parameters (all aliases for the single 'question' field) with descriptions. The description adds that the input is a natural language question but does not introduce new semantics beyond the schema. Thus baseline 3 for high schema coverage.

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

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

The description clearly states the tool is a 'hallucination-resistant answer mode' for high-stakes reads, and distinguishes it from sibling ask_pipeworx by emphasizing extraction from tool results only. The verb 'extract' plus the specified output structure make the function 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?

Explicitly provides when-to-use scenarios (financial verdicts, legal claims, medical lookups, public statements) and when-not-to-use (casual lookups, prefer ask_pipeworx). Also notes the cost trade-off of one extra LLM call, giving clear selection criteria.

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, and idempotentHint, but the description adds extensive behavioral context: resolver contract, parent event extraction, news fallback handling, safety short-circuits for low-confidence matches, closed market handling, spread warnings, and resolution-rule risk. This far exceeds what annotations provide, and there is no contradiction.

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

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

The description is extremely verbose, running many paragraphs with detailed examples, classifiers, and edge cases. While comprehensive, it lacks conciseness; an AI agent would benefit from a more front-loaded summary with optional deep details. The first sentence is good, but subsequent details are extensive.

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, no output schema, many edge cases), the description is remarkably complete. It covers input formats, classification, fan-out examples, response shapes, resolver confidence handling, parent events, news fields, safety mechanisms, spread warnings, and resolution-rule risk. Everything an agent needs to use and interpret results is present.

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

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

Schema coverage is 100% with descriptions for all 3 parameters. The description adds significant value beyond the schema by explaining the market input can be a slug, URL, or question text, and elaborating on depth ('quick' vs 'thorough') and include_raw behavior (summaries vs full payloads). This enriches the agent's understanding.

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

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

The description clearly states the tool researches a Polymarket bet by pulling Pipeworx data. It specifies the action (research) and resource (Polymarket bet data) but does not explicitly differentiate from sibling tools like polymarket_arbitrage or polymarket_edges, which could also be used for related queries.

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

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

The description provides clear use cases ('should I bet on X', 'what does the data say about Y') and explains behavior for low-confidence matches and closed markets. However, it does not explicitly state when not to use this tool or compare it to alternatives like ask_pipeworx, which reduces guidance completeness.

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

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

Annotations declare readOnly, openWorld, idempotent, and non-destructive. The description adds significant detail: pulls latest 10-K data, handles off-calendar fiscal years, results sorted by primary metric, returns paired data with citation URIs. No contradiction with annotations.

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

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

The description is compact yet dense with information. It front-loads the purpose with example queries, then details behavior. Every sentence earns its place; no wasted words.

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

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

Given no output schema, the description adequately covers return format (paired data + citation URIs) and behavior (sorted results). It addresses the complexity of two entity types with different data sources. Comprehensive for its purpose.

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

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

Schema coverage is 100% with both parameters described. The description adds meaning: explains the enum of 'company' vs 'drug', specifies that values must be 2-5 tickers/CIKs or drug names, and clarifies what each type returns (financial metrics vs counts). This goes 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 performs side-by-side comparison of 2-5 entities (companies or drugs) with example queries like 'compare X and Y' and 'rank these companies'. It specifies the data sources (SEC EDGAR/XBRL for companies, FAERS/FDA/trials for drugs) and distinguishes from sequential lookups.

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

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

The description explicitly says 'ALWAYS PREFER over sequential single-pack lookups when comparing entities' and provides trigger phrases. It doesn't explicitly mention when not to use, but the preference is clear. Could be more explicit about alternative tools for single entities, but contextual completeness is high.

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 extensive behavioral detail beyond the annotations: decomposition into facets, parallel routing, findings packet structure (verbatim evidence + confidence, citations), gaps[] for unanswered facets, contradictions[] for standard/thorough, semantic excerpting, latency expectations, and the conditionality of citation_uri. No contradiction with readOnly/openWorld/idempotent 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 account requirement and the core purpose, then logically progresses through usage guidelines, behavioral details, and timing. It is long and occasionally repeats concepts (e.g., contradictions[] appears in multiple places), but for a tool with this complexity, most sentences earn their place; minor redundancy keeps it from a 5.

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

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

Given the tool's complexity, absence of an output schema, and rich annotations, the description is remarkably complete. It covers the findings packet, gaps[] behavior, contradictions[], citation resolvability, depth semantics, expected latency, account tier requirements, and sibling tool differentiation. This provides enough context to correctly select and invoke the tool.

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

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

While the schema already covers 100% of parameter descriptions, the description enriches depth's enum with concrete facet counts (quick=3, standard=5, thorough=8), payment requirement for thorough, follow-up hop behavior, and gap recovery. It also explains that question accepts broad natural language and that decomposition is the point. This goes beyond schema, making parameter semantics clear and actionable.

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

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

The description clearly states the tool performs 'Grounded multi-source research across Pipeworx's 1455 STRUCTURED data sources' in one call, decomposing questions into facets and routing to tools in parallel. It explicitly distinguishes from open-web search and contrasts with sibling tools like ask_pipeworx for single lookups or breaking news.

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 ('Best for broad/multi-part questions over structured data') and when not to ('For a single lookup use ask_pipeworx', 'For BREAKING or colloquial CURRENT-NEWS... prefer ask_pipeworx'). Also mentions account requirement and alternative for unsigned users, giving clear decision guidance.

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

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

Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds valuable behavioral context by stating that results include full input schemas with examples and are 'ready to call directly, no second schema lookup needed.' 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 well-structured and concise, starting with purpose, then usage guidance, then return details. Every sentence adds value, and examples are included. No unnecessary text.

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 100% schema coverage, no output schema, and simple annotations, the description covers the tool's purpose, when to use it, and return format. It includes relevant examples and mentions aliases. Slightly more detail on ranking or ordering could improve it, but overall 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 the schema already documents all parameters. The description does not add significant meaning beyond the schema; it mentions query aliases and limit default but repeats existing info. Baseline 3 applies.

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

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

The description clearly states 'Find tools by describing the data or task' with a specific verb and resource. It differentiates from sibling tools by focusing on discovery rather than specific tasks like research or alerts.

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 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' This provides clear when-to-use context, though it does not explicitly list 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?

Beyond annotations (read-only, idempotent), description details fan-out across multiple sources, soft-fail for patents (USPTO sunset), and 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?

Extremely concise single paragraph front-loaded with example queries. Every sentence adds value with no redundancy.

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

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

Given complexity (multiple data sources, no output schema), description fully covers what is returned, limitations (only US public companies, patent soft-fail), and prerequisite (name resolution). Agent has sufficient context to use correctly.

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

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

Schema coverage is 100%, providing baseline of 3. Description adds extra meaning: confirms 'type' only supports 'company', and for 'value' explains names not supported, directing to resolve_entity. This adds value beyond schema.

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

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

Description clearly states 'full cross-source profile of a US public company in ONE parallel call' with specific verbs like 'tell me about', 'research', 'brief me on'. It distinguishes from chaining single-pack lookups by explicitly preferring this tool for holistic views.

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

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

Explicitly says 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups' and provides alternative instructions: 'use resolve_entity first' for names. Also states when not to use names directly.

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

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

Annotations already indicate destructiveHint=true and readOnlyHint=false. Description only restates deletion without adding behavioral context like effects on non-existent keys or side effects.

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, 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?

For a simple delete tool with clear schema and annotations, the description is complete. No output schema needed.

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 no extra meaning beyond the schema's 'Memory key to delete'.

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

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

Description clearly states it deletes a memory by key, but doesn't explicitly differentiate from siblings like 'remember' or 'recall', though 'pair with remember and recall' implies its role.

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 scenarios: stale context, task done, clear sensitive data. Also mentions pairing with remember and recall, guiding alternative choices.

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 behavioral details (fetches page, extracts title/description/key links, emits standard markdown) that go beyond annotations, fully disclosing the tool's actions. No contradiction.

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

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

The description is a single, well-structured paragraph with three sentences. It front-loads the main purpose, and every sentence contributes essential information. No redundancy or wordiness.

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

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

Given the tool's simplicity (2 parameters, no output schema, rich annotations), the description fully covers input, output, and use cases. It explains the output format and provides multiple usage scenarios, making it complete.

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

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

Schema coverage is 100%, and the description does not add significant meaning beyond the parameter descriptions. It mentions URL and max_links implicitly but does not provide examples or additional constraints. Baseline 3 is appropriate.

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

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

The description clearly states it generates a production-ready llms.txt file for any URL, specifying the action (generate), resource (llms.txt file), and output format. It distinguishes from siblings as no other sibling tool performs similar generation.

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

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

The description provides explicit use cases (getting a client's site indexed, drafting for own project, auditing competitor) but lacks explicit guidance on when not to use or alternatives. Given diverse siblings, the context is clear enough.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, indicating a safe, idempotent read operation. The description adds value by specifying the exact metadata fields returned, surpassing the annotation-only baseline.

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

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

The description is two concise sentences. The first sentence front-loads the purpose and output, the second adds a key usage note. Every word is necessary and there is no redundancy.

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

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

Given the tool's simplicity (single parameter, no output schema, and comprehensive annotations), the description is complete. It covers what it returns, how to identify the collection, and the keyless nature. No additional information is needed for effective use.

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

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

Schema coverage is 100% for the single parameter 'concept_id', with a clear description and example. The description adds context by mentioning that the ID can be obtained via search_collections, providing guidance beyond the schema definition.

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 metadata for a single NASA Earth-science collection using a CMR concept ID. It lists specific fields (summary, DOI, spatial coverage, etc.) and notes it's keyless, which distinguishes it from sibling tools like search_collections that return multiple collections.

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 usage when you have a known concept ID and want detailed metadata, but it does not explicitly state when to use this tool versus alternatives like search_collections. The 'keyless' hint is helpful but not a full guideline on context or exclusions.

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

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

Annotations already declare readOnlyHint and destructiveHint. Description adds value by specifying return fields and scope ('caller's active subscriptions'), complementing annotations 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?

Two concise sentences front-loaded with purpose. No redundant words. Efficiently covers purpose, return fields, and usage.

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

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

Given low complexity (one optional boolean param, no output schema), the description fully covers purpose, scope, return fields, and usage context. 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 include_inactive described. Description does not add extra meaning beyond the schema, so baseline score of 3 is appropriate.

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

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

Clearly states it lists the caller's active subscriptions and specifies the returned fields. Distinguishes from sibling tools like subscribe and unsubscribe.

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

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

Explicitly mentions when to use: review before adding more or to find an id to cancel. No explicit when-not but context is sufficient.

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

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

Annotations provide only false hints, leaving the description to disclose behaviors. It adds valuable context: rate limiting ('Rate-limited to 5 per identifier per day'), cost ('Free; doesn't count against your tool-call quota'), and the claim_token workflow including that filing without an account returns a token and passing it back later reads resolution status.

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 dense single paragraph but every sentence carries essential information: purpose, use cases, exclusions, content guidance, token flow, rate limit, and cost. It is front-loaded with the primary action. A slightly more structured layout (bullets or short paragraphs) would improve scannability, but it remains efficient and non-redundant.

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

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

Despite having no output schema, the description fully covers the tool's purpose, usage triggers, exclusions, claim_token lifecycle, rate limiting, and content guidance. It explains what happens when filing without an account (returns claim_token) and how to retrieve status later. The richness of this description makes the tool fully understandable and actionable.

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

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

Schema already has 100% parameter descriptions, so baseline is 3. The description adds meaningful usage semantics beyond the schema: instructs to 'describe the issue in terms of Pipeworx tools/packs — don't paste the end-user's prompt' for the message field, and demonstrates how to use claim_token with the syntax 'pipeworx_feedback({claim_token:"pwfb_…"})'.

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

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

The description opens with a specific verb and resource: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It immediately distinguishes this feedback tool from the sibling research/search tools by its unique purpose of reporting issues or praise about Pipeworx tools.

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

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

The description provides explicit 'when to use' guidance with enumerated cases: 'Use when a tool returns wrong/stale data (bug), when a tool you wish existed isn't in the catalog (feature/data_gap), or when something worked surprisingly well (praise).' It also states a clear when-not and alternative: 'ONLY for tools served by this Pipeworx connection... file it with that server instead.'

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds non-obvious behavioral details: data source ('CF analytics-engine'), no PII, caching (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?

Every sentence serves a purpose: core functionality in first sentence, then bulleted use cases, then data source note. No filler, 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?

Given one optional parameter, strong annotations, and no output schema, the description fully covers purpose, usage guidance, data source, caching, and privacy. No gaps for this complexity level.

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 already explains the 'window' parameter well. The tool description only mentions windows in the opening sentence, adding no further 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 the verb ('returns') and the resource ('top tools, top packs, total call volume' on Pipeworx). It differentiates from siblings like 'discover_tools' by focusing on aggregate call trends of other agents, not on searching or querying specific 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 lists three explicit use cases (discovering hot data sources, confirming canonical tool, seeing alignment) without mentioning when not to use it. While no explicit exclusion is given, the use cases are specific enough to guide selection.

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

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

The description goes well beyond annotations, detailing the partition check, fill check against live CLOB depth, semantic anchor similarity requirement, and partition filter. It fully discloses the tool's operational behavior without contradicting annotations (readOnlyHint, idempotentHint, etc.).

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 with a clear front-load of the main modes, but it is somewhat verbose with extensive detail. While every sentence adds value, it could be slightly more concise without losing essential information.

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

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

Despite lacking an output schema, the description thoroughly explains the response structure, including fields like opportunities, partition_check, and fill check details. It also covers edge cases (placeholder filters, similarity threshold, thin legs). The tool is well-integrated with sibling tools for further actions.

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

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

Schema coverage is 100%, and the description adds significant value by explaining each parameter's usage (event slug or URL, topic as seed question), mode behavior, and constraints like Jaccard similarity for topic mode. This enriches the bare schema descriptions.

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

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

The description clearly states the tool finds arbitrage opportunities via monotonicity violations and partition-sum checks. It distinguishes three modes: no args (trending scan), event mode, and topic mode, each with examples, making it easy to understand what the tool does and how to invoke it.

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 top markets, event for specific market, topic for cross-event scanning) and mentions using polymarket_fill_risk for custom sizing. However, it does not directly contrast with other sibling tools like polymarket_edges, so there is room for improvement.

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 extensively discloses behaviors beyond annotations: caching (1h KV cache keyed on knobs), response structure with diagnostics and segments, special handling of Fed bets, and details on Kelly fraction behavior for partition arbs. This fully compensates for the already informative annotations, with 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 but well-structured, using clear segmentation and front-loading the purpose. However, it is somewhat lengthy with exhaustive details on model families and thresholds, which could be trimmed for brevity without losing essential information.

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

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

Given the tool has 9 optional parameters and no output schema, the description fully covers response structure (segments, fields like edge_pp_net, diagnostics), caching behavior, and knob usage. It leaves no critical gaps for an agent to understand input/output and operational behavior.

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

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

With 100% schema coverage, the description adds significant meaning: provides default values and rationale for slippage_pp, explains why min_kelly does not filter partition arbs and how min_partition_leg_kelly works, and gives illustrative examples for filters like min_liquidity and max_spread_pp.

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 'Scan top Polymarket markets and return opportunities where Pipeworx data disagrees with market price.' It specifies the resource (top Polymarket markets) and action (scan and return opportunities), distinguishing from sibling tools like polymarket_arbitrage by focusing on disagreement detection.

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

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

The description identifies the use case: 'Built for 'what should I bet on today' — agents discover opportunities without paging hundreds of markets.' It also explains tradeable-edge knobs for filtering, providing context for tool usage. However, it does not explicitly mention when not to use or provide alternatives among sibling tools, slightly reducing clarity.

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 and idempotent behavior. The description adds extensive behavioral details: response structure (tracked, expired, snapshot_dates), field semantics (trend, decay_pp_per_day signed by trade direction), snapshot gaps due to cache-miss, and TTL limits. It provides more than expected.

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 question and written in a clear, narrative style. It includes some illustrative examples that add length but enhance understanding. Could be slightly more concise, but structure is good.

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

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

No output schema exists, so the description covers return values thoroughly (tracked, expired, snapshot_dates with field descriptions). It also addresses limits, data recency, and sign conventions. It lacks mention of pagination or max items, but is largely complete.

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

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

Schema coverage is 100%, so the schema itself documents parameters. The description adds useful context by clarifying 'days' as lookback and 'window' as snapshot family, and states defaults. It supplements rather than repeats 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 purpose: edge persistence and decay telemetry from daily snapshots. It explicitly answers the key question 'how long has this edge existed and is it shrinking?' and distinguishes between fresh and old edges, implying differentiation from sibling tools 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 provides context on when to use this tool (to assess edge history and decay) and contrasts different edge ages. It includes LIMITS explaining history depth and data sources. However, it lacks explicit statements about alternatives or 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 provide readOnlyHint and idempotentHint. The description adds significant behavioral context: detailed return fields for both modes (e.g., top_of_book, slippage_pp, capture_ratio, thin_legs), and explains the risk of unhedged directional positions from partial fills. 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 detailed but well-structured with clear sections (SINGLE-MARKET, BASKET) and bullet points. Every sentence adds value, though slightly lengthy; 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 (two modes, many return fields, no output schema), the description is thorough. It covers purpose, prerequisites, return values, edge cases (partial fills), and usage context. No gaps remain for an agent to understand invocation.

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

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

Schema coverage is 100%, baseline 3. The description adds meaning beyond schema: explains side default 'auto' for basket, size_usd interpretation differs per mode (spend vs. target proceeds vs. settlement notional), and market/event exclusivity requirements. This elevates it 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 performs a 'Realizable-vs-theoretical edge check against live CLOB order-book depth' and distinguishes between single-market and basket modes. It provides specific verbs and resources, and contrasts with 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?

Explicit guidance: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500.' It warns against partial basket fills and clarifies when not to use it, providing clear context versus alternatives.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds significant behavioral context: two modes, safety fields (compatibility_warning, temporal_alignment, skipped counters), and the realistic caveat that real spreads are rarer than shortcuts suggest. 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 relatively long but well-structured with labeled sections (TWO MODES, RESPONSE, SAFETY FIELDS). It front-loads the core purpose and uses clear formatting. Could be slightly trimmed, but remains highly informative.

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

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

No output schema exists, so the description must explain return values. It does so comprehensively: leg-by-leg prices, spread array with top_spreads_pp, compatibility_warning conditions, temporal_alignment, and skipped counters. This is complete for a complex tool.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining the 10 topic shortcut values, the effect of overriding with explicit tickers, and the response fields that relate to parameters. It goes 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 computes cross-venue spreads between Kalshi and Polymarket for the same resolving question. It names two distinct modes (topic shortcuts and explicit pairing), which distinguishes it from other arbitrage or edge tools like polymarket_arbitrage or 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 explains when to use each mode and warns that most pre-mapped topics return compatibility warnings, and that unaligned temporal periods make spreads meaningless. It does not explicitly list when not to use or alternatives, but the warnings serve as implicit guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds scoping detail (identifier-based) and pairing behavior, which are valuable beyond annotations.

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

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

Two sentences with no waste. Purpose is front-loaded, and every sentence adds value (purpose, usage, scoping, pairing).

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

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

For a simple read-only tool with good annotations and schema, the description provides complete context: purpose, usage, scoping, and how it relates 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 one parameter 'key'. Description clarifies that omitting 'key' lists all keys, adding meaning beyond the schema description.

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

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

The description clearly states the tool retrieves values saved via 'remember' or lists all keys when omitted. It specifies the verb and resource, and distinguishes from siblings like '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?

Provides context on when to use (look up stored context) and mentions pairing with remember/forget. However, does not explicitly state when not to use it or mention alternatives.

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

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

The description discloses that 'set mark_read:true to flag returned events read so the next call only shows newer ones,' which implies a side effect (state change). This contradicts the annotation readOnlyHint: true, which asserts no side effects. The contradiction is flagged.

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 front-loads the main action and then provides details and usage guidance. Every sentence adds value, and there is no redundant or overly verbose content.

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

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

The description covers the tool's purpose, return fields, filtering, and a usage note about polling vs HTTP. It lacks explanation of unread_only and limit behavior, but given the schema fills those gaps, it is mostly complete. The contradiction with mark_read reduces completeness slightly.

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

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

With schema coverage at 100%, baseline is 3. The description adds meaning beyond the schema by clarifying the filter type example ('sec_8k') and the effect of mark_read. However, it omits discussion of unread_only and limit, which are explained in the schema.

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

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

The description clearly states 'Pull fired events from your subscription feed', specifying the resource (subscription feed) and the action (pull). It details the returned fields (source, citation_uri, raw payload) and filtering options, distinguishing it from sibling tools like list_subscriptions or recall.

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

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

The description advises that 'Polls work fine' and provides an alternative HTTP endpoint for scripts/dashboards, giving the agent context on when to use this tool versus other access methods. However, it does not explicitly compare to sibling tools or state 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 indicate read-only, idempotent, non-destructive behavior. Description adds rich details: fan-out to SEC EDGAR, GDELT→GNews fallback, USPTO soft-fail, return structure with grouped changes 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?

Dense but well-organized: front-loaded with examples, then technical details, then alternative tool mention. Every sentence serves a 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?

Given no output schema, the description thoroughly covers input parameters, behavior (parallel calls, fallback, soft-fail), and output structure. It addresses edge cases like USPTO sunset and GNews fallback, making it self-contained.

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

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

Schema coverage is 100% with descriptions, but description adds contextual examples (ticker vs CIK for value, relative date shorthand) and explains the type enum limitation. This enhances understanding beyond the schema.

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

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

Description explicitly states the tool provides a change feed for a company in a time window. It gives concrete query examples ('What's new with X') and distinguishes from sibling tool entity_profile by specifying its use for static profiles regardless of time window.

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?

Includes clear when-to-use guidance with example queries and directs users to entity_profile for static profiles. Also provides parameter usage tips, such as recommending '30d' or '1m' for typical monitoring.

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

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

Annotations provide idempotentHint and destructiveHint. Description adds key-value scoping, persistence duration (24h for anonymous, persistent for authenticated), and pairing with other tools. 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?

Five sentences, no fluff. First sentence defines purpose, second gives usage context, third explains persistence, fourth mentions companion tools. Efficient 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?

For a simple key-value write tool, description covers purpose, usage, persistence, and partners. No output schema needed. Complete for agent to select and invoke correctly.

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

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

Schema has 100% parameter description coverage. Description adds semantic examples like 'subject_property' and 'target_ticker', enhancing meaning beyond schema descriptions.

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

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

Clearly states the tool saves data for later reuse, with specific examples (ticker, address, preference). Distinguishes from siblings like 'recall' and 'forget' by explicitly naming them as complementary 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 with concrete examples of what to store. Mentions pairing with recall and forget. Lacks explicit 'when not to use' but covers context well.

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 and idempotent, but the description adds substantial behavioral detail beyond that: it cascades through several lookup endpoints, degrades gracefully when GLEIF/OpenFIGI are unavailable, labels identifiers with their source, and reports unresolved identifiers explicitly under `unresolved`. 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 compact given the tool's complexity. It opens with concrete example queries, states the purpose in one sentence, then uses a SUPPORTED TYPES section for detail. Each clause earns its place, though the density of information (ownership, sourcing, degradation) makes it slightly heavy. Still, structure and front-loading are effective.

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

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

The tool is complex (two entity types, multiple identifier sources, cascading lookups) without an output schema. The description fully covers input flexibility, output fields (CIK, LEI, FIGI, RxCUI, ingredient, brand, unresolved list), and error behavior (graceful degradation). It also explains why resolution replaces multiple manual lookups, giving total context for invocation.

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

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

Schema coverage is 100% (both type and value are described), so baseline is 3. The description adds value by explaining the full meaning of each parameter per type: for company, value can be ticker, CIK, or name; for drug, brand or generic. It also details what outputs arise from those parameters, enriching the bare schema descriptions.

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

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

The description clearly states the tool resolves user-spoken names to canonical identifiers, with specific verb phrases like 'resolve a user-spoken NAME to the canonical/official identifiers.' It also enumerates supported types (company, drug) and the exact IDs returned (CIK, LEI, FIGI, RxCUI), making it unmistakable what the tool does and differentiating it from sibling tools 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 description gives explicit usage guidance: 'Use FIRST whenever you have a name but need an ID.' It also provides a rich set of example queries ('What's the ticker for…' / 'find the CIK for…') and states it replaces 2-3 manual lookups. However, it does not explicitly list exclusions or contrast with specific alternative tools, 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 readOnly, openWorld, idempotent, and non-destructive behavior. The description adds context about the ranking, output fields (score, confidence, signal density), and the ordering semantics (first entity as subject). No contradictions.

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

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

Two sentences: first states purpose and action, second gives use case and output format. Efficient and front-loaded with key information. 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?

Despite no output schema, the description specifies the return format (ranked list with score, confidence, signal density per entity). All parameters are covered in schema and description. Complexities like probe behavior and ordering are addressed. Complete for the tool's purpose.

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

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

Schema description coverage is 100%, so the description's contribution is moderate. It adds meaning by stating that the first entity is treated as the 'subject' for narrative, and clarifies the roles of models, _apiKey, and context beyond the schema descriptions.

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

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

The description clearly states the tool's purpose: comparing AI visibility across multiple entities side-by-side, probing with ai_visibility_check, ranking by score, and returning which is most/least recognized. It distinguishes from sibling ai_visibility_check by focusing on multiple entities and ranking.

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

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

The description provides a clear use case (competitive AI-marketing audits) and an example question. It mentions the underlying tool ai_visibility_check, allowing inference of when to use this vs. single-entity probe. However, it does not explicitly state when not to use or list alternative tools.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds behavioral context: fans out across two sources, bundlephobia's first measurement can take 5-30s, partial failures degrade gracefully with sources_failed listing timeouts. No contradiction with annotations.

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

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

The description is a single paragraph but packs a lot of information efficiently. It front-loads the purpose and key features. Could benefit from bullet points for readability, but remains concise and clear.

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

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

No output schema exists, yet the description fully details the return value: summary block with specific fields, per-advisory detail, links, and alternative versions. It also covers failure modes, ecosystem scope, and graceful degradation. 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% with clear descriptions. The description adds that scoped packages are accepted and that version defaults to latest when omitted, which is useful but not strictly necessary given schema clarity. Slight improvement over 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: a composite check for 'should I add this npm package to my project' in one call, covering license, advisories, version history, bundle size, and ESM/tree-shake support. It distinguishes from siblings by specifying the NPM ecosystem focus and listing specific data sources (deps.dev and bundlephobia).

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 when to use: when agent asks 'is X safe/popular/small' or 'what does adding lodash cost me'. It also notes ecosystem limitations (NPM only in v1) and how to handle other ecosystems (deps.dev:version directly). Provides guidance on partial failures and timeouts.

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

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

Annotations already indicate read-only, idempotent, and open-world behavior. The description adds valuable context: the tool is keyless, sorted by usage, and covers ~10k collections, enhancing beyond annotations 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?

Two sentences efficiently convey purpose, scope, and key behavioral traits (keyless, sorted). No superfluous information; front-loaded with the core action.

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

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

Given no output schema, the description could mention return format (e.g., list of collection metadata). However, it sufficiently covers search intent, filters, and key constraints, making it largely complete for the agent.

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

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

Schema coverage is 100%, so the description need not repeat parameter details. It lists filter types (keyword, platform, etc.) in the purpose statement, which provides context but does not add meaning beyond schema descriptions.

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

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

The description clearly states the tool searches NASA's CMR for dataset collections by multiple criteria (keyword, platform, instrument, time, bounding box), specifying the resource and action. This distinguishes it from siblings like search_granules.

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

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

The description provides context on sorting and keyless access but does not explicitly state when to use this tool versus alternatives like search_granules or search_within. Usage guidance is implied but not definitive.

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, non-destructive, idempotent. The description adds behavioral traits: newest-first ordering, what fields are returned, and the 'Keyless' claim. No contradictions.

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

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

Two sentences, front-loaded with primary action and result fields. Every word contributes meaning. No fluff.

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

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

Given no output schema, the description still informs about return details (timestamps, file size, URLs). Combined with rich annotations and filter options, it is complete for a list tool.

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

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

Schema coverage is 100% with detailed descriptions. The description adds value by mentioning filter types (time range, bounding box) and guiding users to get collection IDs from search_collections, which compensates for high schema coverage.

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

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

The description clearly states the tool lists individual data files (granules) of a NASA collection, newest first, with specific fields like timestamps, file size, and download URLs. It distinguishes from the sibling 'search_collections' tool by specifying granule-level vs collection-level.

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 for granule data filtering by time/bounding box. 'Keyless' hints at no auth barriers. While no explicit 'when not to use' is given, the sibling context (e.g., search_collections) provides clear differentiation.

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

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

Beyond annotations (readOnlyHint, idempotentHint, etc.), description adds details: uses BGE-base-en embeddings, cosine similarity over 500-char overlapping windows, 200K char cap with truncation, and passage offsets for verification. 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?

Three sentences front-loading purpose, then usage, then technical details. Every sentence adds distinct value with no redundancy.

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

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

No output schema exists, but description explains return (top-N passages with offsets and scores). Covers input constraints (200K chars), embedding mechanism, and pairing advice. Complete for a search tool.

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

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

Schema coverage is 100%, so baseline is 3. Description adds value by explaining 'text' as 'the text you already pulled' with examples and cap info, and 'query' with natural-language examples. 'limit' is less elaborated but acceptable.

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 specific verbs (search, inside), resource (record), and examples (SEC 10-K, article). It distinguishes from sibling tools 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 states when to use: 'when the record is too big to cram into the prompt' and explains benefit (saves context, returns relevant passages). Mentions pairing with ask_pipeworx_grounded but lacks explicit when-not-to-use or comprehensive alternative list.

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

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

Annotations indicate a non-read-only, potentially open-world, idempotent, non-destructive operation. Description adds crucial details: requires OAuth account, returns new subscription ID, 10/day SMS cap, phone verification requirement, webhook signing and auto-disable on failure. 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?

Front-loaded with purpose, then organized by parameter type, using clear formatting. Somewhat long, but all information earns its place given the complexity of subscription types and delivery channels.

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 3 parameters, nested objects, multiple types, and no output schema, the description covers return value, prerequisites, examples, limits, verification steps, and webhook signature mechanics, leaving no obvious 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 significantly enriches each parameter: explains enum values with concrete examples, provides type-specific parameter formats for each subscription type, and details delivery channel options including SMS limits, email validation, and webhook HMAC signing.

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

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

Clearly states it creates a subscription to a live-data event stream and returns the subscription ID. Distinguishes from siblings like unsubscribe and list_subscriptions by focusing on creation.

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

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

Provides clear context including required Pipeworx OAuth account and that anonymous/BYO users cannot persist subscriptions. Gives extensive type-specific examples and delivery options. Does not explicitly state when not to use or name alternative tools, but the context is sufficient for most agents.

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, openWorld, and idempotent behavior. The description adds detailed behavioral context: it returns category-bucketed example questions with exact tool and argument shapes drawn from a live catalog. 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 informative but somewhat lengthy, with a dense parenthetical list. It is front-loaded with example queries, but could be slightly more streamlined 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?

Despite the lack of an output schema, the description fully explains the return value: category-bucketed example questions with tool and argument shapes. It covers purpose, usage, and parameter details, making it complete for this meta-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 input schema has 100% coverage for the single optional parameter. The description adds value by listing acceptable topic values and explaining the default behavior when omitted, going beyond the schema's brief 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 explicitly states the tool's role as the onboarding entry point for understanding what Pipeworx can do. It provides specific example user queries and explains the output structure, clearly distinguishing it from sibling tools by recommending its use first.

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 guidance on when to use this tool: when the agent is new and doesn't know what Pipeworx can do. It also suggests using it to learn how to call meta-tools. However, it does not explicitly state when not to use it, though the context makes it obvious.

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 behavioral detail beyond annotations: 'The row is deactivated (not deleted) so its historical events stay available via recent_alerts'. Annotations already provide idempotentHint and non-destructive hint.

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 action, no wasted words. Every sentence adds value.

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

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

Complete for a simple tool with one parameter and no output schema. Covers purpose, ownership, behavioral effect, and parameter source.

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 parameter 'id'. Description does not add further semantics beyond what the schema provides, so baseline 3 is appropriate.

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

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

Clearly states 'Cancel a subscription by id', specifying the action and resource, and distinguishes from siblings like 'subscribe' and 'list_subscriptions'.

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

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

Provides clear context with 'Ownership is enforced — you can only cancel your own subscriptions', implying when to use and ownership constraint, though no 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?

Beyond the readOnlyHint/openWorldHint annotations, the description discloses key behavioral traits: the two-path routing (structured vs. grounded), the verdict taxonomy, and critically the distinction between could_not_verify (check did not happen, carries verification_error) and unsupported (no source exists). It even warns callers not to treat could_not_verify as evidence for or against the claim — valuable operational detail.

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

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

Although longer than a typical description, every sentence earns its place: trigger phrases, usage guidance, routing detail, return values, and failure-mode caveats are all packed in without redundancy. The description is front-loaded with the most important information (what the tool does) and then layers details in a logical order.

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

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

Given no output schema, the description thoroughly explains the return value (verdict types, actual value with citation, reasoning) and the failure semantics. It covers both the financial and non-financial paths, the tolerance behavior, and the distinction between could_not_verify and unsupported, making the tool fully actionable without additional documentation.

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

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

The schema already documents both parameters with 100% coverage, so the baseline is 3. The description adds meaningful context beyond the schema: tolerance_pct overrides the claim-wording tolerance, defaults to implied wording capped at 5, and is recommended at 1–2 for hallucination detection. The claim examples also clarify the expected natural-language format.

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

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

The description clearly identifies the tool as natural-language claim verification against authoritative sources, with specific trigger phrases ('fact check', 'verify the claim that…') and a distinct verdict output. It differentiates from sibling tools by explicitly describing the structured SEC EDGAR/XBRL fast path for financial claims and a grounded pipeline for all other claims, even noting it replaces 4–6 sequential calls.

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') and provides concrete example triggers. It does not explicitly name sibling tools or state when not to use it, but the routing logic (financial vs. other factual claims) gives strong contextual guidance.

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