Ecosystems

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

Annotations indicate readOnlyHint, openWorldHint, idempotentHint. The description adds context: probing behavior, scoring range, default model usage, API key handling for Anthropic, and return structure. No contradiction with annotations.

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

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

The description is concise, well-structured, and front-loaded. It conveys all essential information in a few sentences without 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 explains the return format (per-model {score, confidence, signals, raw_response} + combined view). It covers all parameters and behavior. Minor omission of rate limits or cost details for Anthropic calls, but still adequate.

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

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

Schema coverage is 100%, but the description adds meaning by specifying the default model (Workers AI Llama-3.3-70b), that _apiKey is passed directly to Anthropic, and that context helps disambiguate names. This goes beyond the schema definitions.

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 about a business/brand and scores visibility (0-100). It specifies the verb 'probe', the resource (LLMs), and outputs a score per model, distinguishing it from generic research tools in the sibling list.

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 default model and API key requirement for Anthropic, though it does not directly compare to sibling tools.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the tool's safety profile is clear. The description adds valuable behavioral context: it routes to 5,564 tools across 1,462 sources, fills arguments automatically, and returns structured answers with stable citation URIs. It also mentions the call is fast and works on every tier. The description does not contradict annotations in any way.

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

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

The description is front-loaded with a strong 'PREFER OVER WEB SEARCH' directive and a compact list of domains. It then provides usage rules and examples. A few extra clauses (e.g., 'START HERE for most questions') could be trimmed, but overall every sentence adds value and the structure is logical.

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 (routing to thousands of sources), the absence of an output schema, and the abundance of sibling tools, the description is remarkably complete. It covers purpose, when-to-use, alternatives, domain list, example queries, output format (structured with citations), and tier/performance notes. Nothing essential is missing.

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

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

The input schema has 100% coverage and provides aliases for the question parameter (q, text, input, query, prompt), which is well-described. The description does not need to add much here because the schema already documents the parameter thoroughly, but it reinforces the natural-language intent with many examples. The score is above baseline (3) because the description's domain examples and usage guidelines serve as implicit parameter context, effectively guiding the user on how to formulate 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 specifies a broad 'ask' verb that routes natural-language questions to a vast collection of verified data sources, covering many concrete domains (SEC filings, FDA, FRED, etc.). It clearly differentiates itself from siblings like ask_pipeworx_grounded and deep_research by stating when to use each, and from web search by explicitly preferring this tool for authoritative structured data.

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

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

The description provides extensive when-to-use guidance: it instructs the agent to prefer this tool over web search for factual questions, lists example triggers ('what is', 'look up', etc.), and explicitly names alternatives (ask_pipeworx_grounded for verbatim evidence, deep_research for broad multi-part questions). It also notes that for breaking news, this tool already covers live news feeds.

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, which cover safety and idempotency. The description adds valuable behavioral context: it is a full working router (not a fallback), it may host candidate routing improvements, and currently behaves identically to the stable router. This clarifies the ‘beta’ nature without contradicting annotations.

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

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

The description is a single paragraph of about four sentences, efficient and front-loaded with purpose and usage. It could be slightly more structured (e.g., bullet points or clearer separation of sections), but it remains concise and informative without wasted words.

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

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

Given the complexity of a router handling 5,564 tools, the description adequately covers the tool's identity, relationship to stable router, current operational state, and usage expectation. No output schema exists, but the description notes identical response shape to ask_pipeworx. The completeness is sufficient for an agent to understand and use this beta tool appropriately.

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

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

Schema description coverage is 100%, with each parameter alias documented (q, text, input, query, prompt, question). The description adds no additional meaning beyond what the schema provides. According to guidelines, baseline is 3 when coverage is high, and no extra semantics are contributed.

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

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

The description clearly identifies this tool as a beta version of ask_pipeworx, a universal router with identical tool inventory and arguments. It explicitly distinguishes itself from the stable router (ask_pipeworx) and the grounded variant (ask_pipeworx_grounded) by emphasizing the experimental routing edge. The verb 'ask_pipeworx_beta' is accurately described as a candidate testing 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 usage context: 'Use it exactly like ask_pipeworx when you want the newest routing' and explains current behavior (no active candidate, matches stable). It also mentions the evaluation purpose (results compared against stable router to decide merges). However, it doesn't explicitly state when not to use this tool (e.g., when stability is required), which is implied by the sibling naming.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive. The description adds significant behavioral context: returns explicit refusal reasons (not_in_source, no_tool_match, etc.), extracts answer only from tool result, and includes the return structure (answer, evidence, confidence, source, fetched_at, refusal_reason). 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 concise (5-6 sentences) and front-loaded with the core purpose. It efficiently covers process, return format, use cases, and cost trade-off without superfluous text. Every sentence earns its place.

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

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

Given the simple input schema (single question string, 6 aliases) and no output schema, the description fully compensates: it explains the extraction behavior, refusal reasons, return structure, and appropriate use cases. The agent has all necessary information to invoke the tool correctly and interpret results.

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

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

Schema description coverage is 100% (all 6 parameters have descriptions explaining they are aliases for 'question'). The description mentions 'Accepts query, q, prompt, text, input as aliases' but essentially repeats what the schema already states. Baseline 3 because the schema does the heavy lifting; the description adds no new parameter semantics beyond restating aliases.

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: 'Hallucination-resistant answer mode for high-stakes reads.' It explains the process (routing, extracting answer from tool result) and distinguishes from its sibling ask_pipeworx, which is for casual lookups. The verb 'extract' and resource 'answer' are specific and well-defined.

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

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

Explicitly specifies when to use: 'whenever an answer will be quoted, cited, or acted on, and the agent must not invent facts (financial verdicts, legal claims, medical lookups, public statements).' It also provides a when-not-to-use: 'prefer ask_pipeworx for casual lookups' and notes the cost trade-off ('costs one extra LLM call'). The alternative tool is named.

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 details behavioral traits beyond what annotations provide. It explains low-confidence resolution short-circuiting, closed/dead market handling, wide-spread market warnings, resolution-rule risk parsing, and parent event extraction. Annotations only indicate readOnlyHint, openWorldHint, idempotentHint, and non-destructive; the description adds critical operational details.

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

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

The description is very long (several paragraphs) and contains a large amount of detail. While the front-loading is good (purpose in first sentence), the length may overwhelm some agents. It could benefit from structuring with headings or bullet points for easier parsing.

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

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

Given the tool's complexity (multiple classifiers, fan-outs, response shapes, edge cases) and absence of output schema, the description covers all necessary aspects: resolver contract, parent extractor, news fields, safety mechanisms, and resolution-rule risk. It is complete for an agent to understand usage and 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?

Schema coverage is 100%, so baseline is 3. The description adds meaningful context: the 'market' parameter can be a slug, URL, or question text; 'depth' is explained with shortcut examples; 'include_raw' is described with its impact on response size. This goes beyond the schema's brief 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: 'Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call.' It specifies inputs (slug, URL, text) and outputs (evidence packet, market-vs-model comparison). The verb 'Research' and resource 'Polymarket bet' are specific, and the tool is distinguishable from siblings like polymarket_arbitrage and polymarket_edges which focus on different aspects.

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

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

The description provides explicit use cases: 'Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z".' It also gives examples of fan-out based on classifier. However, it does not explicitly state when NOT to use this tool or mention alternatives among sibling tools, which would improve 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, openWorldHint, idempotentHint true. Description adds specific behavior: for company type, it explains data sources (SEC EDGAR/XBRL) and handling of off-calendar fiscal years; for drug type, it lists FAERS counts, FDA approvals, trials; also notes sorting and citation URIs.

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. While not extremely concise, every sentence adds value. Could be slightly more structured (e.g., separate sections for company vs drug), but still efficient.

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

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

Despite no output schema, the description explicitly states return format ('paired data + pipeworx:// citation URIs per entity') and sorting behavior. Covers both entity types adequately, making the tool fully understandable.

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 both parameters. Description adds concrete examples (tickers for company, drug names), constraints (2–5 items), and explains how each type is used, significantly augmenting the schema.

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

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

The description states 'side-by-side comparison of 2–5 companies or drugs' with multiple example queries ('compare X and Y', 'X vs Y', 'rank these companies'), clearly distinguishing it from siblings like entity_profile or resolve_entity.

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

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

Explicitly says 'ALWAYS PREFER over sequential single-pack lookups when comparing entities' and quantifies efficiency ('Replaces 8–15 sequential lookups'), providing clear when-to-use guidance.

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

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

Description discloses multiple behavioral traits beyond annotations: account requirement (free vs paid), parallel decomposition across 5,564 tools, return format (findings with gaps, contradictions, hop fields), semantic excerpting, expected latency (15-90s), and that certain topics yield empty gaps. Annotations already confirm read-only/open-world/idempotent, and description aligns 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?

Description is lengthy but well-structured, front-loading critical prerequisites (account required) and core differentiators. Every sentence adds information, though it could be slightly more streamlined for rapid parsing. Still, it is effective and not wasteful.

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

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

Given the tool's complexity (1462 sources, 5564 sub-tools, multiple depth modes), the description is remarkably complete. It explains the output format in detail (findings packet with fields like evidence, confidence, source, citation, gaps, contradictions), return behavior per depth, and handling of large records. No output schema is needed given this clarity.

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

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

Schema coverage is 100%, but description adds significant value: for depth it explains facet counts, hop behavior, and feature differences per level; for question it clarifies that broad/multi-part queries are intended. This goes well beyond the schema's basic descriptions.

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

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

The description clearly states the tool performs 'Grounded multi-source research across Pipeworx's 1462 STRUCTURED data sources in ONE call.' It distinguishes itself from siblings like ask_pipeworx (single lookup) and explicitly notes it is not open-web search, with examples of appropriate use cases.

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 this tool vs alternatives: use ask_pipeworx for single lookups or breaking news, and use ask_pipeworx if not signed in. It also explains the three depth levels and their trade-offs, helping agents choose appropriately.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and the description aligns with these by stating it returns tool definitions and is a discovery action. No contradictions or unstated behavioral traits.

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 slightly lengthy but well-structured: first sentence defines purpose, then usage context, then return details. Every sentence adds value, though some redundancy in listing domains could be trimmed.

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 fully explains what is returned (names, descriptions, full schemas) and that results are callable directly. Covers all necessary context for an agent to use the tool effectively.

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

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

Schema coverage is 100% with descriptions for each parameter. The description adds value by listing alias parameters ('Accepts task, q, description, search') and providing examples, going beyond the schema.

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

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

The description clearly states the tool's verb ('Find tools by describing the data or task'), lists specific domains, and explains what it returns (top-N tools with schemas). It explicitly distinguishes from siblings by advising 'Call this FIRST when you have many tools available'.

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

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

The description provides clear usage context ('Use when you need to browse, search, look up, or discover what tools exist') and a strong recommendation ('Call this FIRST'). It lacks explicit when-not-to-use or alternatives, but the guidance is sufficient for an AI agent.

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

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

Annotations already declare readOnlyHint, openWorldHint, etc. Description adds context: parallel fan-out, return fields (cik, filings, fundamentals, patents, news, LEI), and notes patents may soft-fail due to API sunset.

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

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

Description is a single dense paragraph; while it front-loads examples, it could benefit from bullet points or structured sections for readability.

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

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

Given no output schema, description thoroughly explains return contents and sources. Covers limitations (patents sunset, names not supported) and provides sufficient context for agent to use tool effectively.

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

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

Schema coverage is 100%, but description adds meaning: type is restricted to 'company', value must be ticker or zero-padded CIK, and names not supported. Provides clear guidance 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 tool returns a full cross-source profile for a US public company, with examples like 'tell me about X' and mentions of multiple data sources. Differentiates from resolve_entity which handles names.

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 lookups' when holistic view is needed. Also advises using resolve_entity first if only a name is available.

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 idempotentHint=true. The description adds no new behavioral details beyond confirming deletion by key; no mention of side effects, error handling, or scope of deletion.

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 efficient sentences convey purpose, usage guidelines, and related tools. No fluff, 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?

For a simple delete-by-key tool with good annotations and schema, the description covers the basics adequately. Could mention behavior if key does not exist, but overall sufficient.

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

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

Schema coverage is 100% with parameter description 'Memory key to delete'. The description adds no additional semantics beyond what the schema provides, so 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 uses specific verb 'Delete' and resource 'memory by key', clearly differentiating from siblings 'remember' and 'recall' by stating it is the deletion counterpart.

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

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

Explicitly states when to use: when context is stale, task done, or to clear sensitive data. Also names companion tools ('remember' and 'recall'), providing alternatives and context.

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

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

Annotations already indicate safe, read-only, idempotent behavior. The description adds that it fetches the page, extracts title/description/key links, and emits standard markdown, aligning with annotations. It does not contradict and provides useful context beyond annotations.

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

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

The description is concise: two sentences plus a bullet list of use cases. It front-loads the core action and uses no unnecessary words.

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

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

Given the rich annotations and full schema coverage, the description covers the tool's purpose, parameters, and output format ('single text blob'). It adequately explains the return value since no output schema is provided.

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%. The description enhances both parameters: gives an example for URL and specifies default and max for max_links, adding value 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 generates a 'production-ready llms.txt file' for any URL, specifying the resource and action. It differentiates from siblings by focusing on llms.txt generation for AI crawlers, distinct from other visibility or analysis 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 lists explicit use cases: client site indexing, personal project drafting, competitor auditing. However, it does not specify when NOT to use or provide alternatives, though the context is clear enough.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable context: 'Keyless' (no authentication needed) and 'Works across 100+ registries'. This goes beyond what annotations provide, but the bar is lower due to rich annotations. No contradictions.

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

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

The description is two sentences, front-loaded with the main purpose, and includes essential scope and authentication info. Every word 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?

The description fully covers the tool's purpose, parameters, scope, and auth requirements. Although there is no output schema, the description lists the specific metadata fields returned, providing sufficient completeness for agent invocation.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds useful commentary: scopes/slashes are handled automatically for 'name', and for 'registry' it suggests using 'list_registries'. This enhances understanding beyond the schema alone.

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

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

The description clearly states the verb 'Get' and resource 'package's open metadata' with a specific list of fields (description, homepage, repository, etc.). It is specific about what it retrieves. However, there is a sibling tool 'lookup_package' that may have similar functionality, and the description does not explicitly differentiate from it, slightly reducing clarity.

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 broad usage context: works across 100+ registries and requires no key. However, it does not give explicit guidance on when to use this tool versus alternatives (e.g., 'lookup_package'), nor does it mention any prerequisites or limitations. Usage is implied but not fully explicit.

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 and idempotent behavior. The description adds useful context beyond annotations by specifying 'Keyless' access and the output includes ecosystem and package counts, though it doesn't detail output structure.

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

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

Two concise sentences with no redundancy: first sentence explains the action and examples, second adds a key access note. Every part earns its place.

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

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

For a parameterless list tool, the description covers the purpose, output content, and access requirement. It lacks details on ordering or pagination but is sufficient for simple 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?

The tool has zero parameters and schema coverage is 100%. The description adds value by indicating what the response contains (ecosystem and package counts), compensating for the lack of output 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 lists package registries with their ecosystem and package counts, providing specific examples (npm, PyPI, etc.) and distinguishing it from sibling tools like get_package or lookup_package.

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 a simple list operation and mentions 'Keyless' (no authentication), but does not explicitly state when to use this tool versus alternatives or provide exclusions.

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

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

Annotations already indicate readOnlyHint and idempotentHint. The description adds some context about returned fields and the include_inactive parameter, but nothing beyond what is already clear from annotations and schema.

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 (two sentences) with the core purpose first, then usage guidance. No unnecessary words.

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

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

Given no output schema, the description lists the returned fields. It covers the parameter and usage. For a simple read-only tool with strong annotations, this is sufficiently 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% for the single parameter. The description does not add extra meaning beyond what the schema already provides, 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?

The description clearly states the tool lists the caller's active subscriptions, specifies the returned fields, and 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?

The description provides explicit use cases: reviewing what you're monitoring before adding more or finding an id to cancel. It does not explicitly mention alternatives but implies context.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds 'Keyless' implying no auth needed, which is useful but minimal. 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?

Two sentences front-loaded with the main purpose, followed by a clarifying sentence and a one-word behavioral note. 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?

Adequate for a simple tool: mentions both parameters and return type (records), but lacks detail on record structure since no output schema. Also unclear if both params can be omitted.

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

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

Schema coverage is 100% so parameters are already documented. Description merely restates that it uses purl or repository_url without adding new semantics beyond the schema.

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

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

The description clearly states it looks up every registry a package or repository is published to via purl or repository URL. It distinguishes from siblings like get_package and list_registries by emphasizing cross-registry lookup.

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 for finding registries for a given package but does not explicitly state when to use vs alternatives like scan_dependency or get_package. No exclusions or when-not-to-use guidance.

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

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

Annotations provide only generic false flags, so the description carries the transparency burden. It discloses rate limiting (5 per identifier per day), the claim_token lifecycle, quota-free usage, and that feedback is read daily. It also clarifies it cannot fix issues from other servers, which sets accurate expectations.

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

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

Although the description is lengthy, every sentence earns its place: purpose, use cases, exclusions, token flow, rate limits, and content expectations. The first sentence front-loads the core action, and no information is redundant.

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

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

With no output schema, the description still explains the key return behavior (claim_token and follow-up) and covers scope, exclusions, rate limits, and content guidance. It is sufficiently complete for an agent to decide when and how to invoke this tool correctly.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds meaning beyond the schema by explaining the claim_token flow ('Filing without an account returns a claim_token; pass it back later') and by advising to describe issues in terms of Pipeworx tools rather than pasting end-user prompts, supplementing the message field guidance.

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

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

The description opens with 'Tell the Pipeworx team something is broken, missing, or needs to exist,' which clearly states the verb, resource, and scope. It explicitly enumerates feedback types and distinguishes from sibling tools by limiting scope to tools served by this Pipeworx connection.

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

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

The description gives explicit when-to-use conditions (bug, feature/data_gap, praise) and when-not-to-use (tools from other MCP servers), including the alternative of filing with that other server. It further clarifies identification: 'Not sure? Pipeworx tool names are the ones this connection lists.'

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 safe read-only behavior (readOnlyHint, idempotentHint, etc.). Description adds valuable context: self-aggregating signal from CF analytics-engine, no PII, caching details (5min-1h). This exceeds what annotations provide.

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

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

Front-loaded with the main output, followed by use cases and implementation details. Every sentence adds value. Could be slightly tighter but remains clear and structured.

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

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

Despite lacking an output schema, the description adequately describes the return data (top tools, top packs, call volume) and caching behavior. Sufficient for a simple read-only analytics tool with one optional parameter.

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

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

Schema coverage is 100%, so baseline is 3. Description adds extra semantic nuance by explaining that shorter windows surface current trends while longer windows show steady-state demand, going beyond the enum 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 it returns top tools, top packs, and total call volume over a recent window, using specific verbs and resources. Uniquely identifies its purpose among many sibling tools.

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

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

Explicitly lists three concrete use cases for when to use the tool. Does not provide negative guidance or alternatives, but the use cases are specific and actionable.

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

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

Annotations indicate readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. The description adds extensive behavioral context: monotonicity checks, partition sum ≈1, Jaccard similarity >=0.30 for cross-event, placeholder filter, fill check against live CLOB depth, and when not to trade. 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 thoroughly informative but somewhat lengthy, with dense technical detail. It is well-structured with labeled sections for event mode, topic mode, fill check, etc. Minor conciseness improvements possible (e.g., moving threshold details out), but overall effective and front-loaded with purpose.

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

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

The tool is complex with multiple modes and no output schema. The description provides a near-complete picture of return structure (opportunities[], partition_check with fields, fill check results) and references related tool for sizing. It compensates fully for the lack of output schema with detailed behavioral descriptions.

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%, baseline 3. However, the description enriches parameter meaning significantly: explains what each mode does, provides example event slugs and topic seeds, notes that URLs are accepted, and details what outputs (partition_check, fill check) are generated per parameter.

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 on Polymarket via monotonicity violations + partition-sum checks'. The verb 'Find' and resource 'arbitrage opportunities on Polymarket' are specific. It distinguishes from siblings like polymarket_edges and polymarket_fill_risk by detailing its unique arbitrage detection approach.

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 each calling mode: no args for trending scan, 'event' for single-event partition check, 'topic' for cross-event scanning. It also explains when to avoid trading (realizable_edge_pp ≤ 0) and directs to polymarket_fill_risk for custom sizing, providing clear alternatives.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds extensive behavioral context: caching (1h at KV level), detailed model methodologies (crypto_price, news_momentum, partition_overround, concentrated_longshot), filters (placeholder-slug, partition thresholds), and diagnostic outputs. 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 very long and dense, with walls of text. While it is front-loaded with the main purpose, the excessive detail in a single paragraph makes it hard to parse quickly. Could be more concise.

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

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

Given the tool's complexity (multiple segments, knobs, diagnostics), the description covers everything needed: explains each model family, output structure, tradeable-edge knobs, and diagnostic fields. No output schema exists, but the response structure is fully described.

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

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

Schema coverage is 100% with good parameter descriptions. The description adds extra context for some parameters (e.g., min_partition_leg_kelly explains its distinct behavior), but the baseline is 3 due to high schema coverage. The additional value is marginal.

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

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

The description clearly states the tool scans top Polymarket markets and returns opportunities where Pipeworx data disagrees with market price. It specifies the verb 'scan' and resource, and the purpose is distinct from sibling tools like polymarket_arbitrage.

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 it's 'built for what should I bet on today' and that agents can discover opportunities without paging hundreds of markets. However, it does not explicitly compare with siblings 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 declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description goes beyond by detailing the response structure (tracked[], expired[], snapshot_dates[]), trends, decay rates, and data limits such as the 60-day snapshot TTL.

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

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

The description is dense but well-organized: purpose, usage, parameter details, response format, and limitations. Every sentence adds value, though it is lengthy.

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

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

Given no output schema, the description fully explains the return objects (tracked, expired, snapshot_dates) and their fields, along with limitations. No gaps 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?

Input schema covers 100% of parameters with descriptions. The description adds minimal extra context (e.g., clamping range), which aligns with baseline 3 for high schema coverage. No significant new meaning beyond schema.

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

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

The description clearly states the tool's purpose: 'Edge persistence and decay telemetry built from daily polymarket_edges snapshots.' It answers the specific question of how long an edge has existed and whether it is shrinking, distinguishing it 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 differentiate between a fresh wide edge and a 3-week-old wide edge. It doesn't explicitly state when not to use it or name alternatives, but the context implies its unique value over polymarket_edges.

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 extensively discloses behavior: walks order book ladder, returns fill details, slippage, verdict, per-leg details for baskets, thin legs, forced directional risk. Annotations confirm read-only, idempotent, non-destructive; description aligns and enriches 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?

Description is long but well-organized with capitalized sections and bullet lists. Every sentence adds value, but could be slightly more concise without losing critical details.

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

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

No output schema; description compensates by detailing all return fields for both modes. Covers edge cases (thin legs, forced directional risk) and contextual pitfalls. Complete for an AI agent to use effectively.

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

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

Schema coverage 100%. Description adds significant meaning: explains market vs event modes, side defaults, size_usd interpretation for buys vs sells and singles vs baskets. Goes well 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?

Description clearly states the tool checks realizable vs theoretical edge against live CLOB order book depth. It details two modes (single-market and basket) and lists specific outputs, distinguishing it from related tools.

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

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

Explicit guidance: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500.' Explains why (theoretical overround on thin books is not capturable, partial basket fills create directional risk).

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

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

Beyond annotations (readOnlyHint, idempotentHint, destructiveHint=false), the description extensively details behavioral traits: compatibility_warning triggers, temporal_alignment field, skipped_cross_type/subtype counters, and matched_pairs interpretation. 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?

Well-structured with clear section headers (TWO MODES, RESPONSE, SAFETY FIELDS) and bold emphasis. Every sentence adds value, though slightly verbose for an AI; still efficient and scannable.

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

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

Given the complexity of cross-venue matching and no output schema, the description comprehensively explains response fields, edge cases (compatibility warnings, temporal misalignment), and limitations. Sufficient for an AI agent to understand behavior and interpret results.

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

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

Schema descriptions cover each parameter (100% coverage), but the description adds significant context: topic values as a list, overriding behavior of explicit fields, and mode selection. Enhances understanding beyond schema alone.

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

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

The description clearly states the tool computes cross-venue spread between Kalshi and Polymarket for the same resolving question, immediately distinguishing it from sibling tools like polymarket_arbitrage. It specifies two modes (topic shortcuts or explicit tickers) and explains the output format.

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

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

Provides explicit guidance on when to use each mode and warns that pre-mapped topics often return compatibility_warnings, cautioning against assuming tradeability. Lacks explicit 'when not to use' but covers key contexts.

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 idempotentHint. Description adds that omitting key lists all saved keys, and that data is scoped to the agent's identifier. 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 efficient sentences front-loaded with the main action. First sentence defines the operation, second provides use context and scoping. No redundancy or 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 low complexity (1 optional param, no output schema) and rich annotations, the description covers purpose, usage, linking with siblings, and scoping. It is fully adequate for an agent to understand and invoke the tool.

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

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

Schema coverage is 100% with a clear description of the 'key' parameter. The description essentially restates the schema: 'omit the key argument' to list all keys. 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 retrieves a value saved via 'remember' or lists all keys if key is omitted. It gives concrete examples (ticker, address, notes) and contrasts with sibling tools 'remember' and 'forget'.

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

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

Explicitly says when to use: to look up context stored earlier without re-deriving. Mentions scoping and pairing with remember/forget. Does not state explicit negatives, but usage is well contextualized.

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

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

Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds valuable behavioral details: it explains that setting mark_read:true flags events as read, affecting subsequent calls (consuming behavior). It also mentions that the feed is persisted and describes the return structure. No contradictions with annotations.

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

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

The description is compact (about 5 sentences) and front-loaded with the core purpose. The mention of the alternative API URL is a slight tangent but still useful context. No repetitive or filler content. A near-perfect balance of brevity and informativeness.

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 5 optional parameters, no output schema, and simple return structure, the description covers the essential aspects: what is returned, how to filter, and the side-effect of mark_read. It could mention pagination limits or ordering (e.g., newest first), but these are implicitly handled by the 'most recent' phrasing and the 'limit' param. Overall, it provides sufficient context 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?

The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds extra meaning by explaining the effect of mark_read ('so the next call only shows newer ones') and clarifying that 'since' refers to fired_at time. It also gives examples for type ('sec_8k') and notes the default limit. This goes beyond the schema's bare 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 begins with a clear action verb ('Pull') and specifies the resource ('fired events from your subscription feed'), making the tool's purpose immediately obvious. It also enumerates key return fields (source, citation_uri, raw event payload) and filter options, distinguishing it from generic listing 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 some context by noting that polls work fine and offering an alternative access method (direct API URL), which helps decide when to use the tool. However, it does not explicitly state when to prefer this tool over sibling tools like list_subscriptions or subscribe, nor does it give clear 'when not to use' guidance.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. Description adds details about fan-out to multiple sources, fallback mechanism, and return structure. Lacks some specifics on rate limits or error handling.

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

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

Well-structured: front-loaded with example queries, then explanation of behavior, sources, return format, and sibling comparison. Each sentence adds value; could be slightly more concise but overall efficient.

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?

Describes multi-source fan-out, fallback, return structure, and citation URIs. Missing pagination or result limits, but given openWorldHint, it's adequate. No output schema, so description covers key outputs sufficiently.

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

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

Schema covers 100% of parameters with descriptions. Description adds examples and best practices for 'since' (e.g., 'Use "30d" or "1m" for typical monitoring') and explains 'value' accepts ticker or CIK. Adds marginal but useful nuance 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?

The description explicitly states it provides a 'change feed for a company in the last N days/weeks/months in ONE parallel call' and contrasts with sibling entity_profile, which is for static profiles. Example queries clearly indicate intended use.

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?

Describes when to use (e.g., 'latest on Y', 'what happened to Z') and explicitly recommends entity_profile for static profiles. Covers fallback logic (GDELT→GNews) and soft-fail for USPTO.

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

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

Discloses key behavioral traits: key-value pair scoped by identifier, persistence difference between authenticated (permanent) and anonymous (24 hours). Annotations provide idempotentHint true, which is consistent. No contradictions, but could mention idempotency explicitly.

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

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

Four sentences that are information-dense without being wordy. Front-loaded with purpose and usage. Slightly redundant with examples, but overall efficient.

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 store tool with no output schema, the description covers purpose, usage, and persistence behavior adequately. Lacks mention of return value or error cases, but these are 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 already has 100% coverage with clear parameter descriptions. Description adds context about scoping by identifier but does not significantly extend parameter meaning beyond schema. 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?

Description uses specific verb 'Save' and resource 'data' to be reused later, with clear scoping (across conversations or sessions). It distinguishes itself from sibling tools like 'recall' and 'forget' by stating it is paired with them.

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

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

Explicitly states when to use ('when you discover something worth carrying forward') and mentions alternatives ('Pair with recall to retrieve later, forget to delete'). Provides concrete examples of what to store.

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

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

Beyond the annotations (read-only, idempotent), the description discloses rich behavioral details: it cascades through several lookup endpoints, degrades gracefully when GLEIF/OpenFIGI are unavailable, explicitly lists unresolved identifiers under an `unresolved` field, and labels every identifier with its source. This greatly exceeds what annotations alone convey.

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

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

The description is long but front-loaded with immediate use cases and structured by entity type. Although it contains some verbose phrasing (e.g., 'cross-source identity spine'), every section adds value regarding supported types, identifiers, sources, or fallback behavior. It is appropriately detailed for a tool with this complexity, but could be tightened slightly.

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

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

Given the tool's complexity (two entity types, multiple identifiers, external sources, error handling) and the absence of an output schema, the description is remarkably complete. It covers what identifiers are returned, their provenance, how unresolved items are handled, and graceful degradation—so the agent knows exactly what to expect from the call.

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 significantly enriches parameter meaning: it explains the 'type' enum values ('company' vs 'drug') and the 'value' parameter accepts ticker, CIK, ISIN, or company name for company, plus brand/generic for drug. It even gives an ISIN example and describes the resolution logic, going far beyond the schema's short 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/official identifiers, with a specific verb ('resolve') and resource ('NAME to identifiers'). It lists concrete example queries and explicitly distinguishes its role ('Use FIRST whenever you have a name but need an ID'), contrasting it with sibling tools that operate on already-resolved 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 provides explicit when-to-use guidance: 'Use FIRST whenever you have a name but need an ID.' It also explains that it replaces 2-3 manual lookups. However, it does not name specific alternative tools or give when-not-to-use scenarios, so it falls short of a full 5.

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

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

Annotations already declare read-only and idempotent nature. The description adds valuable behavioral details: it calls ai_visibility_check internally, ranks results, and returns a ranked list with score, confidence, and signal density. Also notes optional API key requirement for anthropic model.

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

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

Four sentences that efficiently convey purpose, process, use case, and output. No redundancy, each 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?

Despite no output schema, the description explicitly states what is returned (ranked list with score, confidence, signal density). Combined with complete parameter documentation, the tool is well-specified for an AI 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% with detailed parameter descriptions. The tool description adds minimal extra meaning (e.g., treatment of first entity as subject) beyond what the schema provides. Baseline of 3 is appropriate.

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

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

Description clearly states the tool compares AI visibility across multiple entities, using specific verbs like 'compare', 'probes', 'ranks', and 'surfaces'. It distinguishes itself from siblings like ai_visibility_check (single entity) by focusing on multiple entities side-by-side.

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?

Description explicitly positions the tool for competitive AI-marketing audits with a concrete example question. While it doesn't list when not to use it, the context makes the intended use clear and distinct from single-entity probes.

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, non-destructive. Description adds key behavioral details: partial failures from bundlephobia timing out (5-30s), graceful degradation with sources_failed field, and the comprehensive return structure.

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

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

Single, well-organized paragraph that front-loads purpose and key features. Information-dense but efficient, with minimal redundancy. Loses one point for not using bullet points or sections to improve scanability.

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 fully enumerates return fields (summary block, advisory details, links, alternatives) and explains partial failure behavior. Complete for a composite tool with external dependencies.

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 for both parameters. The description reinforces that scoped packages are accepted and version defaults to latest, but adds no new meaning beyond the schema. 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 defines the tool as a composite npm package evaluation across deps.dev and bundlephobia, answering questions about safety, popularity, and size. It distinguishes itself from sibling tools by specifying its unique multi-source aggregation.

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

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

Explicitly tells when to use ('is X safe / popular / small') and scopes to npm ecosystem, noting that other ecosystems fall under a different tool (deps.dev:version directly). Provides clear context for 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 provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. The description adds significant behavioral details: BGE-base-en embeddings, cosine similarity, 500-char overlapping windows, 200K char cap, returned passages with offsets and scores. 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 a tight single paragraph with no wasted words. It front-loads the purpose, then usage, then technical details. 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?

Despite no output schema, the description explains return values (top-N passages with offsets and scores), technical implementation (embeddings, window size), and limitations (200K char cap, truncation). It is complete for the tool's complexity.

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

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

Schema coverage is 100%, so baseline is 3. The description adds extra context: for 'text' it gives max ~200K chars, for 'limit' it specifies 1-20 range and default 5, and for 'query' it provides examples. This adds value 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 'Semantic search INSIDE a fetched record' and explains the use case (when the record is too big for the prompt). It distinguishes from sibling tool ask_pipeworx_grounded by describing a complementary workflow.

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

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

Explicitly tells when to use ('when the record is too big to cram into the prompt'), provides a pairing instruction with ask_pipeworx_grounded, and notes the input cap (200K chars, truncated and flagged). This gives clear context and alternatives.

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

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

The description adds significant behavioral context beyond annotations: idempotentHint is disclosed via 'Returns the new subscription id' and details like phone verification, 10/day SMS cap, and webhook auto-disable after 10 failures. This complements the annotations effectively.

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

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

The description is dense but well-structured, using examples and conditionals. However, it could be slightly more concise or broken into subsections for readability.

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

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

The description covers return value, prerequisites, supported types, and delivery details. Missing error handling or failure scenarios, but overall complete for a creation tool without output schema.

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

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

Despite 100% schema coverage, the description adds rich semantics: examples for type and params (e.g., 'sec_8k: items:["5.02"] = officer change'), delivery channel constraints (phone verification, webhook signing), and type-specific filters. This greatly aids agent understanding.

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

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

The description clearly states the tool's purpose: 'Create a proactive monitoring subscription to a live-data event stream. Returns the new subscription id.' This distinguishes it from siblings like 'unsubscribe' and 'list_subscriptions'.

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

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

The description provides clear context for use: requires a Pipeworx OAuth account, lists supported types with examples, and details delivery channels. However, it does not explicitly state when not to use this tool or compare it to 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 provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds that it's an onboarding entry point, returns example questions with tool shapes, and supports topic filtering. 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?

One long sentence carries all information but is not overly verbose. Could be broken into bullet points, but it's still efficient and front-loaded with purpose.

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

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

Given no output schema, description explains exactly what is returned (category-bucketed examples with tool+argument shapes). Covers enough context for an onboarding tool with one optional parameter.

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

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

Schema coverage is 100% with one optional parameter described. Description adds context that topic can be values like 'finance', 'pharma', etc., and explains its effect on focus, going beyond the schema.

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

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

Description clearly states the tool is for onboarding, answering questions like 'What can I ask Pipeworx?' and returns category-bucketed example questions. It distinguishes from siblings like ask_pipeworx by positioning itself as the first call for exploration.

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

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

Explicitly says 'Use this FIRST when you do not yet know what Pipeworx can do for you, or to learn how to call the meta-tools.' This provides clear when-to-use guidance and implies alternatives.

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

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

Discloses key behaviors beyond annotations: ownership check, deactivation instead of deletion, and preservation of historical data. No contradiction with annotations.

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

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

Two sentences, front-loaded with the core action, no unnecessary words. Each sentence serves a purpose.

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

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

For a simple tool with one parameter and no output schema, the description covers purpose, constraints, side effects, and relation to other tools completely.

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

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

Schema covers 100% of parameter details, so description adds no extra semantic value. 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 the verb 'cancel' and resource 'subscription by id'. Distinguishes from siblings like 'subscribe' and 'list_subscriptions' by specifying the action and constraints.

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 ownership enforcement and that the row is deactivated (not deleted), guiding when to use and what happens. Lacks explicit alternatives for full deletion, but context is clear.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, but the description adds substantial behavioral detail: the SEC EDGAR/XBRL fast path vs grounded pipeline, the verdict enum, citation format, and critical caller guidance about 'could_not_verify' vs 'unsupported' to prevent misinterpretation of failure states. This goes well 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?

While the description is relatively long, every sentence earns its place: trigger phrases, routing logic, return contract, caller caveat, and call-count benefit. It is front-loaded with purpose and contains no fluff or repetition of schema fields.

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

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

Despite having no output schema, the description fully specifies the return contract (verdict, value, citation, reasoning) and handles edge cases like 'could_not_verify' and 'unsupported.' It covers both financial and non-financial claim types, explains fallback behavior, and provides enough detail for an agent to invoke the tool correctly.

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

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

The schema covers both parameters at 100%, but the description adds actionable semantics beyond that: for tolerance_pct, it explains how to override the implied tolerance, suggests 1-2 for hallucination detection, and states the default is capped at 5. It also provides concrete example claims for the claim parameter, so the description meaningfully enriches the schema.

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

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

The description starts with explicit trigger phrases ('Is it true that…', 'fact check', 'verify the claim that…') and clearly states the tool performs 'natural-language claim verification against authoritative sources.' It distinguishes itself from sibling research/lookup tools by focusing on fact-checking with a defined verdict set and a mention of structured financial data vs grounded fallback.

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 guidance: 'Use whenever the agent needs to check whether something a user said is factually correct.' It also explains the routing for financial vs other claims, but it doesn't explicitly name sibling alternatives or state when not to use the tool, so it stops 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.