Dst Dk

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds beyond: explains default model (free), optional paid model via API key, and cost implications. It aligns with annotations and provides practical behavioral context.

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

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

The description is concise (6 lines), front-loaded with purpose, and every sentence adds value. It efficiently covers purpose, usage, parameters, and output format 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 4 parameters, no output schema, and moderate complexity, the description sufficiently covers key aspects: what it does, how to use it (default vs. paid), return format, and use cases. No gaps for an agent to invoke correctly.

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

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

Schema description coverage is 100%, so parameter semantics are well-documented. The description adds value by clarifying the default model for the 'models' parameter and the role of '_apiKey'. It doesn't explain 'entity' further but the schema already does.

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 multiple LLMs to score visibility of an entity (brand, product, topic) on a 0-100 scale. It specifies the verb ('probe'), resource ('LLMs'), and output ('score'). It distinguishes from siblings like 'ask_pipeworx' by focusing on visibility across models.

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 ('AI-marketing audits, pre-launch brand checks, competitive monitoring') and explains the two usage modes (free default vs. BYO key for Anthropic). However, it does not explicitly contrast with similar sibling tools like 'scan_competitor_ai_presence'.

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 establish read-only, idempotent, open-world behavior. The description adds meaningful non-obvious behavior: the tool is an automatic router that fills arguments and returns answers with stable pipeworx:// citation URIs, and it describes itself as a single fast answer before escalation. 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 longer than average but front-loads the critical 'prefer over web search' instruction and uses categorized lists and examples to keep the scope legible. Some lists are redundant with the trigger phrases, and the final escalation paragraph is a bit run-on, so it doesn't earn a 5.

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

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

With only one required string parameter and no output schema, the description supplies the essential invocation context: trigger phrasing, examples, citation-bearing return format, and clear escalation paths to sibling tools. Nothing an agent needs to select and call it correctly is missing.

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

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

Schema coverage is 100%; the schema documents the question field and its five aliases (q, text, input, query, prompt). The description itself adds no parameter-level detail, but none is needed since all parameters are aliases for the same natural-language string.

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 identifies the tool as a general factual question-answering router: it takes a natural-language question, routes it across thousands of Pipeworx tools/sources, and returns a structured answer with citation URIs. The description differentiates it from siblings like ask_pipeworx_grounded and deep_research, and from web search.

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 the agent to prefer this over web search for factual/current/historical data questions and lists trigger phrases and examples. It also gives conditional escalation: use ask_pipeworx_grounded for hallucination-resistant verbatim evidence, deep_research for broad multi-part questions, and notes that news queries are handled here.

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, the description discloses the experimental nature, the live candidate routing mechanism, the current absence of any active candidate with a dated retirement, the comparison against the stable router for merge decisions, and that there is no fallback since this is a complete router. This is exemplary transparency for a beta tool.

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

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

Four tight sentences, no filler, and the essential 'beta version' identity is front-loaded. The description then efficiently covers current state, usage, and the experimental caveat 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?

The description covers identity, relationship to the stable router, current active state, usage guidance, response shape via the ask_pipeworx comparison, and the key caveat that it is the experimental edge. Even without an output schema, an agent has enough context to call the tool correctly.

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

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

Schema coverage is 100% and the schema fully documents the question parameter and its aliases. The description adds no new parameter semantics, but none are needed because the schema already carries the meaning; the baseline of 3 is appropriate.

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

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

The description states this is the beta version of ask_pipeworx, an identical universal router with the same 5,798 tools, arguments, and response shape, differing only by candidate routing improvements. This clearly distinguishes it from the stable ask_pipeworx and ask_pipeworx_grounded among the siblings.

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

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

It explicitly instructs users to use it exactly like ask_pipeworx when they want the newest routing, and clarifies the current state (matches stable exactly) and that it is a full working router. It implicitly identifies stable ask_pipeworx as the alternative when experimental routing isn't wanted, though it stops short of an explicit when-not-to-use statement.

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

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

Annotations already mark it read-only, open-world, idempotent, and non-destructive; the description adds refusal semantics, evidence-quote behavior, factual-grounding guarantees, and the cost/performance tradeoff. No contradiction exists between the description and annotations.

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

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

Three dense, front-loaded sentences cover purpose, routing, output shape, refusal behavior, usage context, and cost tradeoff. Every sentence earns its place, and the length is justified by the high-stakes use cases and the need to distinguish from ask_pipeworx.

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

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

The description covers what the tool does, how it behaves, when to prefer it, what it returns, and why it costs more; the schema covers the only required parameter. With no output schema, the explicit return/refusal shape is especially valuable.

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

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

The input schema already provides 100% coverage for the required 'question' parameter, including aliases and natural-language guidance. The description does not add parameter-level syntax, but with full schema coverage a baseline of 3 is appropriate; no additional parameter meaning is needed.

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 identifies a grounded/evidence-based answer mode distinct from ask_pipeworx, with the core behavior of extracting answers only from fetched tool results. The description itemizes both success and refusal outputs, so an agent knows exactly what this tool is for.

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 it (answers that will be quoted, cited, or acted on; domains where invention is unacceptable) and when not to use it (casual lookups → ask_pipeworx). It also names the extra LLM-call cost as a concrete selection criterion relative to its sibling.

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 readOnly and idempotent annotations, the description details resolution process, classifiers, fan-out, response shapes, resolver contract, parent event extraction, news fields, safety mechanisms, and resolution-rule risk. This comprehensive disclosure adds significant value.

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

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

The description is long but well-structured with sections and bullet points, making it scannable. Every sentence adds value, though some brevity could be improved for agent processing.

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, no output schema, and 3 parameters, the description covers returns in detail, edge cases (low confidence, closed markets, wide spreads), and resolution risks. It is complete and self-contained.

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

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

The description explains each parameter beyond the schema: market can be slug/URL/question, depth has quick/thorough, include_raw explains default and use cases. Schema coverage is 100%, but description provides essential context.

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

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

The description clearly states the tool researches Polymarket bets by pulling Pipeworx data, specifying input types and outputs. It distinguishes from siblings by focusing on a single bet research use case ('should I bet on X'), unlike edge or arbitrage tools.

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

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

The description explicitly says 'Use for should I bet on X, what does the data say about Y, or is there edge in Z', providing clear context. It lacks explicit when-not-to-use or alternative tool references, but the sibling list and examples imply differentiation.

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

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

Discloses data sources (SEC EDGAR/XBRL for companies, FAERS for drugs), handling of off-calendar fiscal years, sorting by primary metric, and return format (paired data + citation URIs). No contradiction with readOnlyHint, openWorldHint, idempotentHint, or destructiveHint.

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 dense paragraph front-loaded with common trigger phrases and the core purpose. Every sentence adds information, though it could be broken into 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?

With 2 params and no output schema, description covers what data is returned (paired data, citation URIs) and sorting behavior. Missing details on freshness guarantees or error conditions, but sufficient for typical use.

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

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

Schema coverage is 100% (both params described), baseline 3. Description adds value by explaining how 'type' determines data source and giving examples for 'values' (tickers/CIKs or drug names).

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 'side-by-side comparison of 2–5 companies or drugs' and lists trigger phrases like 'Compare X and Y' and 'head to head.' It distinguishes itself from sibling tools like 'entity_profile' by saying 'ALWAYS PREFER over sequential single-pack lookups.'

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

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

Clear when-to-use guidance: 'when comparing entities' with examples. Explicitly states preference over sequential lookups and implies not for single entities due to minItems=2.

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

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

The description goes far beyond the readOnly/openWorld/idempotent annotations: it discloses the account/paywall requirement, the parallel decomposition execution model, the exact return packet contents (verbatim evidence, confidence, source, fetched_at, citation URI, gaps[]), the contradictions[] scans for deeper depths, semantic excerpting behavior, and expected latency. No annotation 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 long and dense, which is justified by the tool's complexity, but it is not as tightly written as the best examples. It front-loads the account requirement and primary purpose, and organizes details coherently, though some phrasing is convoluted and could be trimmed without loss of meaning.

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

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

There is no output schema, so the description carries the full burden of explaining return values—it does, in detail: findings packet, confidence, source, citations, gaps[], contradictions[], hop field. It also covers prerequisites, errors/fallback (ask_pipeworx), and timing, making the tool fully understandable for correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents question and depth well. The description adds some operational context (deep research is paid, standard default, multi-step resolution in one call) but does not materially expand on what each parameter means beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description states a specific verb and resource: 'Grounded multi-source research across Pipeworx's 1517 STRUCTURED data sources' in one call. It explicitly contrasts with open-web search and distinguishes from ask_pipeworx ('For a single lookup use ask_pipeworx instead'), making its unique niche unmistakable.

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

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

Gives clear when-to-use guidance: 'Best for broad/multi-part questions over structured data' with concrete example questions. It also provides a specific exclusion: 'If you are not signed in, use ask_pipeworx instead' and 'For a single lookup use ask_pipeworx instead.'

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well-covered. The description adds valuable behavioral nuance: explains that counts are registered residents at the FIRST DAY of each quarter, so '2026Q2' is a 1 April snapshot, not a quarterly average. Also notes it's keyless (no auth needed). This contextualizes the tool's semantics beyond the annotations.

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

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

The description is dense but efficient — roughly four sentences covering purpose, source, trigger phrases, and a semantic caveat. It front-loads the core purpose and data source. Could trim the quoted query phrases slightly but each earns its place for agent routing.

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 zero-required-param, single-optional-param tool with strong annotations and 100% schema coverage, the description is quite complete. It covers source, purpose, trigger conditions, temporal semantics, and alternative tools. The only gap is not describing the output/return format of the trend data, though no output schema exists to compensate — but given the tool's simplicity, this is acceptable.

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 only parameter (quarters) has a clear description in the schema itself ('How many recent quarters to include in the trend, 1-40, default 8'). The description adds a small but useful detail that 'the headline figure is always the newest', clarifying the relationship between the trend parameter and the main output. This meets the baseline for high schema coverage.

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

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

The description states a specific verb+resource ('Denmark's total population in ONE call, from Statistics Denmark, table FOLK1A') and clearly distinguishes itself from siblings (list_tables/get_data for breakdowns). It's unambiguous about what it returns and the source.

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 query phrases that should trigger this tool ('PREFER for...'), and explicitly says to use list_tables/get_data for breakdowns by region, age, sex, or marital status. This gives the agent clear when-to-use and 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 cover safety (readOnlyHint=true, idempotentHint=true, destructiveHint=false). Description adds value by detailing output: 'Returns the top-N most relevant tools with names, descriptions, and full input schemas ... ready to call directly'. 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?

Description is concise: three sentences covering purpose, usage context, and output. Front-loaded with key action. 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?

Covers main aspects: purpose, usage, output format, and when to use. Could mention default limit value (20) or that limit is optional, but overall sufficient for a discovery tool with no output schema.

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

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

Input schema has 100% coverage with full descriptions for all parameters. Description does not add new parameter-level details beyond listing example domains, which is useful but not critical. 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 explicitly states 'Find tools by describing the data or task', with a specific verb and resource. It distinguishes itself from siblings by positioning as a discovery meta-tool, e.g., '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?

Clearly states when to use: 'Use when you need to browse, search, look up, or discover what tools exist for: [list]'. Also advises to 'Call this FIRST' when exploring many tools, implicitly guiding against using when specific tool is known.

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, and the description adds substantial context: cross-source fan-out, sources_used/sources_failed semantics, USPTO sunset soft-fail behavior, GDELT→GNews fallback, and the meaning of empty sections. There is 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 long, but almost every clause earns its place given the tool's complexity. The opening is front-loaded with examples and the core directive, and the return sections are enumerated compactly. It sacrifices brevity for completeness without becoming padded.

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

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

For a complex tool with no output schema, the description thoroughly covers inputs, return sections, source fallbacks, error/edge-case behavior, and parameter semantics. An agent has enough context to invoke it correctly and interpret results 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 coverage is 100%, and the description still adds meaningful semantics: type accepts 'company' or 'ticker' interchangeably, value can be a zero-padded CIK or a name resolved via SEC EDGAR, and private companies yield resolved:false with a notes line rather than a failure.

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

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

The description opens with concrete user-phrasing examples and defines the tool as a 'full cross-source profile of a US public company in ONE parallel call.' It clearly distinguishes this from single-pack SEC/XBRL/news lookups and from sibling tools like resolve_entity or compare_entities by its holistic profile mission.

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

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

It explicitly states when to prefer this tool ('ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view'), specifies accepted input forms (ticker, CIK, company name), and explains expected behavior for private companies. This gives an agent actionable selection criteria.

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

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

Annotations already provide destructiveHint and idempotentHint. The description adds context about clearing sensitive data but doesn't elaborate on additional traits like persistence or confirmation behavior.

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

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

Two sentences, front-loaded with purpose, followed by usage guidance and sibling reference. No filler.

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

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

For a simple single-parameter destructive tool with annotations, the description adequately covers purpose, usage context, and relationships. No output schema exists, so no need to explain return values.

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 describes the 'key' parameter. The description only says 'by key', which adds no extra semantic value beyond the schema.

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

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

The description clearly states the action ('Delete') and the resource ('a previously stored memory by key'). It distinguishes sibling tools by pairing with 'remember' and 'recall'.

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

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

Explicitly states when to use: 'when context is stale, the task is done, or you want to clear sensitive data'. Also mentions pairing with 'remember' and 'recall' for completeness.

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

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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds value by detailing what the tool does: 'Fetches the page, extracts title/description/key links, and emits the standard llms.txt markdown format.' No contradiction with annotations.

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

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

The description is three sentences, front-loaded with the primary action and purpose. Every sentence provides necessary context with no filler.

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

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

Given the tool's low complexity (2 params, no output schema), the description sufficiently explains the output as a 'single text blob ready to drop at site-root/llms.txt' and mentions the extraction process. No missing details for an agent to use it.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds minimal meaning beyond schema for 'url' (implies fetching) but does not elaborate on 'max_links' beyond what is already in the schema description.

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

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

The description clearly states the verb 'Generate' and the resource 'llms.txt file for any URL'. It specifies the purpose for AI crawlers and the output format, which distinguishes it from sibling tools as no sibling appears to generate llms.txt.

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 concrete use cases (getting a client's site indexed, drafting for own project, auditing competitor) but does not explicitly state when not to use it or mention alternatives. The context is clear enough for selection.

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

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

Adds useful behavioral context beyond annotations (readOnlyHint, etc.), such as aggregation of omitted variables and format details. No contradiction with annotations.

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

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

Efficient single paragraph of 3 sentences, front-loaded with main purpose. No redundant or unnecessary information.

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

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

Covers parameter usage and format options well. Lacks details on error handling or return structure, but given no output schema and rich annotations, adequate for typical usage.

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

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

Adds meaning beyond schema by explaining variable value patterns (single id, array, '*') and aggregation semantics. Schema already has 100% description coverage, so baseline 3; description adds extra value.

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 'Pull data from a table' with specific verb and resource. It distinguishes from sibling tools like table_info (metadata) and list_tables (listing tables) by focusing on data retrieval.

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

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

Provides clear context on when to use: provide tableId and variables map. Explains format options and behavior for omitted variables. However, lacks explicit when-not-to-use or comparisons 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 declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds behavioral context about hierarchical navigation (drilling into children, expanding subtree) beyond what annotations provide, without contradicting them.

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

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

The description is two sentences, each serving a purpose: first introduces the tool's function, second explains parameter usage. No extraneous words, well-structured and front-loaded.

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

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

Given the tool has 3 optional parameters and no output schema, the description adequately explains how to browse the tree. It does not describe the return format, but that is acceptable for a browsing tool where output is implied. Slight improvement could include mention of what is returned (list of subjects).

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

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

With 100% schema coverage, the description adds marginal value over the schema's parameter descriptions. The examples and clarifications (e.g., 'Omit for the top-level tree') are helpful but not essential given the schema already documents each 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 uses a specific verb 'Browse' and identifies the resource 'Statistics Denmark subject tree'. It gives examples of usage, distinguishing it from sibling tools that do other tasks like research, alerts, or table info.

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

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

The description clearly explains how to use parameters: omit subjects for top-level, pass an id to drill into children, set recursive for full subtree. It does not explicitly state when not to use or mention alternatives, but the context is clear.

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

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

Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds value by specifying the return fields and clarifying that only active subscriptions are listed by default, with an option to include inactive ones. 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?

Two sentences, no wasted words. Purpose is front-loaded, and the guidance is 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?

For a simple list tool with one optional boolean parameter, the description covers the purpose, return fields, and usage context. No output schema exists, but the return fields are listed. Completely 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% and the parameter include_inactive is well-documented in the schema. The description implicitly references it by mentioning 'active subscriptions' but does not add new meaning beyond the schema. Baseline of 3 applies.

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

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

The description clearly states the tool lists the caller's active subscriptions and enumerates the return fields (id, type, params, etc.). It distinguishes itself from sibling tools like subscribe and unsubscribe by focusing on listing.

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

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

Provides explicit guidance: 'Use this to review what you're monitoring before adding more or to find an id to cancel.' This tells the agent when to use it, though it doesn't mention when not to use it.

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

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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds transparency about return fields (table ids, titles, period range, variable names), which is valuable beyond annotations.

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

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

The description is a single, well-structured sentence that covers purpose, filters, and return value, with no wasted words.

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

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

Given no output schema, the description adequately specifies the return fields and hints at integration with other tools. Minor omission: pagination or limits not mentioned.

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

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

Schema has 100% coverage with good descriptions. The description restates filter options but does not add new semantic meaning beyond the schema.

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

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

The description clearly states 'List/search available tables' with specific filtering options and return fields. It distinguishes from sibling tools like table_info and get_data by naming them for subsequent 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?

The description provides clear context for use: discover tables to then use table_info or get_data. It mentions filtering options but lacks explicit when-not-to-use or exclusion criteria.

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

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

Even though annotations are all false, the description discloses significant behavioral traits: the claim_token workflow, rate limiting (5 per identifier per day), cost (free, no quota), and the team's daily digest review. It explains what happens when filing without an account and how to read status later. This goes well beyond the annotations with no contradiction.

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

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

The description is longer than typical, but every sentence serves a purpose: purpose, usage, scope, content rules, token workflow, SLA, rate limit, and cost. It is front-loaded with the core purpose and logically structured. A few minor redundancies with the schema (claim_token) prevent a perfect score.

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

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

Given the tool's moderate complexity (4 params, nested object, no output schema), the description covers purpose, usage scope, parameter behavior, return mechanism (claim_token), rate limit, and cost. It lacks explicit details about what a successful response looks like when an account is present, but it provides enough operational context to use the tool correctly.

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

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

Schema coverage is 100% with detailed parameter descriptions, so the baseline is 3. The description adds extra semantic guidance on message content ('don't paste the end-user's prompt') and clarifies the claim_token usage flow ('Filing without an account returns a claim_token; pass it back later'). Though some information overlaps with schema, the added guidance elevates it.

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

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

The description clearly states the tool's action: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It defines specific feedback categories (bug, feature, praise) and explicitly limits scope to Pipeworx tools, distinguishing it from sibling tools like ask_pipeworx. The verb, resource, and scope are specific and unambiguous.

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

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

The description provides explicit when-to-use scenarios: 'Use when a tool returns wrong/stale data (bug), when a tool you wish existed isn't in the catalog (feature/data_gap), or when something worked surprisingly well (praise).' It also gives clear exclusion guidance: for tools from other MCP servers, 'file it with that server instead.' It even explains how to identify Pipeworx tools, making usage criteria 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 already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds caching details (5min-1h) and states no PII, which adds value beyond annotations.

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

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

Two clear paragraphs. First sentence is a precise summary. Second paragraph lists use cases. No unnecessary words. Well-structured.

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

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

Single parameter fully described. Return values explicitly stated (top tools, packs, total call volume). Caching behavior explained. No output schema needed given simplicity.

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

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

Schema covers 100% of parameters with an enum and description. The description elaborates on window behavior ('shorter windows surface what's hot right now; longer windows show steady-state demand'), adding context.

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

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

The description clearly states the tool returns 'top tools, top packs, and total call volume' over a window. It distinguishes from siblings like 'discover_tools' and 'ask_pipeworx' by focusing on aggregated trending 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?

Explicitly lists three specific use cases for when to use the tool. Does not mention when not to use it or name alternatives, but the use cases provide clear guidance.

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

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

Annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint) are non-contradictory. The description goes beyond by detailing internal behaviors: fill check against CLOB depth, semantic anchor (Jaccard similarity >=0.30), partition filter (placeholder fraction >20% returns null), and the partition_check condition (sum >3pp triggers signal). No contradictions.

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

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

The description is well-structured and front-loaded: first sentence states purpose, then bullet-like sections for modes, semantic anchor, partition filter, fill check. It is somewhat dense but each sentence adds value. Could be slightly more concise, but overall effective.

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

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

Given no output schema, the description explains response structure: opportunities[] with fields and partition_check details. It covers multiple modes, filtering, and edge cases. However, it lacks full specification of the trending_scan response for no-args mode and doesn't mention error handling or empty results. Still fairly 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?

With 100% schema coverage, baseline is 3, but the description adds significant value: explains the difference between event and topic modes, gives example values for event slugs and seed questions, and clarifies that event mode uses full Polymarket URLs. This goes well 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 finds arbitrage opportunities on Polymarket via monotonicity violations and partition-sum checks. It distinguishes three modes (trending_scan, event, topic) with specific use cases, and the purpose is distinct from sibling tools like polymarket_edges and polymarket_fill_risk.

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

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

The description provides explicit when-to-use guidance: 'Call with NO args for a trending_scan... pass event for... pass topic for...'. It recommends event mode for specific markets, explains cross-event mode catches patterns single-event misses, and warns when not to trade ('do not trade it' when fill check fails). It also references polymarket_fill_risk for custom sizing.

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

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

Annotations already declare readOnlyHint and idempotentHint, but the description adds extensive behavioral detail: model families, caching policy (1h KV-level), diagnostic output, and special handling of Fed bets. 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 lengthy but well-structured, front-loading the main purpose and then detailing segments and knobs in a logical order. Every sentence serves a purpose, though it could be slightly more concise without losing information.

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

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

Despite lacking an output schema, the description compensates by thoroughly explaining the response structure, segments, diagnostics, and caching. For a tool with 9 parameters and complex output, the description is complete and actionable.

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

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

Schema descriptions cover 100% of parameters, so baseline is 3. The description adds value by explaining the purpose of certain parameters in context (e.g., min_partition_leg_kelly for partition arbs, slippage_pp fee context), exceeding what the schema alone provides.

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

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

The description clearly states the tool scans Polymarket markets and returns opportunities where Pipeworx data disagrees with market price. It uses specific verbs ('scan', 'return') and resource ('Polymarket markets'), and distinguishes from siblings by focusing on edge detection and opportunity discovery.

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

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

The description provides clear usage context, stating it is built for 'what should I bet on today' and mentions tradeable-edge knobs. It does not explicitly exclude or compare to sibling tools like polymarket_arbitrage, but the context is sufficient for an agent to decide when to use this tool.

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

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint false. The description adds substantial behavioral context: data is from daily snapshots, bounded by 60-day TTL, decay from daily closes, snapshot gaps allowed. 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?

Description is detailed but well-structured: summary, args, response breakdown, limitations. Slightly lengthy but each 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?

Even without output schema, the description explains the full response structure (tracked, expired, snapshot_dates) and limitations (TTL, snapshot gaps). Complete for the 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 covers 100% of parameters with descriptions. Description adds default values, clamp range for days, and valid window families, going 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 'how long has this edge existed and is it shrinking?' and distinguishes itself from siblings like polymarket_edges by focusing on historical persistence.

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 when to use: when needing historical persistence analysis. It contrasts with alternatives implicitly (e.g., polymarket_edges for current edges) but lacks explicit 'when not to use' guidance.

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

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

Annotations confirm readOnly, openWorld, idempotent, not destructive. Description adds context about the check nature and warns of risks like partial fills and unhedged positions. 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?

Long but well-structured with clear sections (SINGLE-MARKET, BASKET). Front-loaded with core purpose. Every sentence adds value, though could be slightly tighter.

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

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

Covers both modes, describes return fields, explains risks (thin books, partial fills, forced directional risk). No output schema, but description is sufficient for an agent to understand and invoke correctly.

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

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

Schema description coverage is 100%, but description adds significant meaning: default values, interpretation of size_usd in each mode, auto side detection for basket. Goes 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 it checks 'realizable-vs-theoretical edge against live CLOB order-book depth' and distinguishes between single-market and basket modes, with specific return fields. It differentiates from sibling tools like polymarket_arbitrage and polymarket_edges.

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

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

Explicitly says 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500'. Explains why (theoretical overround not capturable, partial fills lead to unhedged 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?

Annotations already mark readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description goes far beyond this by explaining pairing verification limits, compatibility codes, temporal alignment null semantics, unclassified-leg handling, fee disclosures, and skipped-cross counters. This is exemplary behavioral disclosure for a complex comparison tool.

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

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

The description is long, but nearly every sentence carries needed behavioral or safety detail for a complex cross-venue tool. It is front-loaded with a clear one-line purpose and uses explicit labels like TWO MODES, RESPONSE, and SAFETY FIELDS, though it could be tightened with more structured bullets. It earns a 4 rather than 5 due to length.

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

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

With no output schema, the description carries the full burden of explaining return values, and it does so thoroughly: leg-by-leg prices, top_spreads_pp, compatibility_warning, compatibility_codes[], temporal_alignment, fees_note, and skipped counters are all described. For a tool with three optional parameters and this much behavioral complexity, 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?

Schema coverage is 100%, so the baseline is 3 even without parameter details in the description. The description still adds meaning by explaining how the three parameters interact: topic shortcuts auto-fetch events, explicit ticker/slug overrides the mapped side, and both modes run the same token-overlap matcher. This goes beyond the schema's 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 first sentence names a specific verb and resource: it reports a cross-venue spread between Kalshi and Polymarket for the same resolving question. It then outlines two distinct invocation modes (topic shortcuts vs. explicit ticker/slug), making it easy to tell apart from sibling tools like polymarket_arbitrage or polymarket_edges.

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

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

The description gives clear, concrete context for when to use each mode: 'topic' for 10 pre-mapped macros, and explicit kalshi_event_ticker + polymarket_event_slug for custom pairings. It also warns that most pre-mapped topics currently return compatibility_warning, setting expectations. It does not explicitly name alternatives or exclusion conditions, but the mode guidance is strong enough for an agent to select it correctly.

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

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

Annotations already declare readOnly, idempotent, non-destructive. Description adds scoping by identifier and behavior of omitting key. Adds moderate value beyond annotations.

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

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

Three sentences, front-loaded with purpose. Every sentence adds value, no fluff.

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

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

For a simple read-only tool with comprehensive schema and annotations, the description covers usage, scope, and pairing with siblings 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 coverage is 100% and already documents the 'key' parameter and omitting to list all keys. Description repeats this information, adding little 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?

Clearly states the tool retrieves a saved value or lists keys, with specific verb 'retrieve' and resource 'memory key'. Distinguishes from siblings 'remember' and 'forget' by naming 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 says to use for looking up stored context (ticker, address, notes) without re-deriving. Does not explicitly mention when not to use, but the context and sibling names imply 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 readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds behavioral details (mark_read side-effect, return fields, polling suitability) beyond annotations, with 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?

Two sentences, front-loaded with purpose. The second sentence is long but packs useful details. No wasted words, though could be split 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?

No output schema, but description describes return fields (source, citation_uri, payload), mentions filtering and mark_read behavior, and notes the HTTP alternative. Missing pagination handling but covers key aspects for a read-only tool.

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

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

Schema coverage is 100% and schema descriptions are good. The description adds usage context for type, since, and mark_read, but does not mention limit or unread_only explicitly. Baseline 3 applies; slight added value keeps it at 3.

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

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

The description uses a specific verb 'Pull' and resource 'fired events from your subscription feed', clearly stating what it does. It distinguishes from siblings like 'list_subscriptions' by focusing on reading alert events.

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 filtering by type/since, using mark_read to manage read state, and notes that polling is fine. Mentions an alternative HTTP endpoint, but does not explicitly contrast with sibling tools or state when not to use this tool.

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

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

The description adds significant behavioral details beyond annotations: it fans out to multiple external APIs (SEC EDGAR, GDELT→GNews fallback, USPTO), explains fallback logic, notes potential soft-failures (USPTO API sunset), and describes return structure (changes[] grouped by source, total_changes, citation URIs). Annotations already indicate read-only, idempotent, and non-destructive behavior, so the description adds valuable context.

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

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

The description is front-loaded with example queries and is well-structured, but it is a dense paragraph. Every sentence adds value, so it is concise for the amount of information conveyed.

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 thoroughly explains the return structure and tool behavior. It covers all necessary aspects for correct invocation and understanding, including fallbacks and limitations.

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 value by clarifying that 'since' accepts ISO dates or relative shorthand with examples like '7d', '30d', '1y', and that 'value' can be a ticker or zero-padded CIK. This enhances understanding 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 explicitly states the tool provides a change feed for a company in a time window, fanning out to multiple sources. It differentiates from sibling tool 'entity_profile' by specifying that tool is for static profiles. This is a specific verb+resource with clear scope.

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

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

The description gives explicit usage examples like 'What's new with X' and advises when to use the alternative 'entity_profile' for static profile queries. It provides clear context for when to invoke this tool versus others.

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

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

Description adds context beyond annotations: storage as key-value pair scoped by identifier, persistence details (authenticated users permanent, anonymous 24h). Annotations indicate idempotent and non-destructive, 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?

Concise and well-structured: first sentence defines core purpose, followed by usage context, then storage details and persistence differences. Every sentence adds value 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?

For a simple key-value store with 2 required parameters, description covers all necessary context: when to use, how it stores, persistence, and sibling tools. No output schema needed for such a basic operation.

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 key and value. Description adds examples of typical keys (e.g., 'subject_property') which provide context but are not critical. 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 clearly states the tool saves data for reuse across conversations/sessions, with specific use cases (resolved ticker, address, preference, research subject). It distinguishes from siblings (recall, forget) and provides clear verb+resource purpose.

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

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

Explicit guidance on when to use: 'when you discover something worth carrying forward' to avoid re-lookup. Mentions pairing with recall and forget, and differentiates persistence for authenticated vs anonymous sessions.

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 read-only and idempotent, and the description adds substantial behavioral context: internal cascading lookups, graceful degradation when GLEIF/OpenFIGI are unavailable, explicit `unresolved` reporting, and returning `figi_candidates` when a name is ambiguous. These are genuinely useful beyond the annotation hints.

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

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

The description is dense and long, but it front-loads the primary purpose and usage instruction. While some sentences are verbose and could be tightened, virtually every clause adds a necessary edge case or supported-type detail for a non-trivial tool.

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

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

Given the tool's complexity and lack of output schema, the description covers inputs, supported types, resolved identifiers, source systems, ambiguity behavior, unresolved results, and degradation scenarios. An agent has enough information to invoke it correctly and anticipate the shape of results.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds significant semantic value for the `value` parameter. It clarifies the input should be the entity name only, warns against including full noun phrases for bonds, and gives concrete examples across ticker, CIK, ISIN, drug brand, and generic names.

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

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

The description states a clear, specific purpose: resolve a user-spoken name to the canonical identifiers other tools need. It enumerates concrete example user questions and supported entity types (company and drug), which distinguishes it from likely siblings like entity_profile and compare_entities.

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

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

The description explicitly says to use this tool whenever you have a name but need an ID, and front-loads that guidance with realistic phrasings. It does not explicitly name alternative tools or state when not to use it, but the context is clear enough for an agent to route correctly.

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=false. The description adds behavioral details: probes each entity, ranks by score, returns ranked list with score, confidence, signal density. 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?

Two sentences, front-loaded with the primary action ('Compare AI visibility across multiple entities side-by-side'), no wasted words. Efficient structure.

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

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

No output schema, but description explains return format (ranked list with score, confidence, signal density). Specifies entity count range (2-8). Does not detail exact output structure or error cases, but adequate for the 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?

100% schema coverage with descriptions. The description adds that first entity is treated as 'subject' for narrative, rest as competitors, and 'context' disambiguates common names, providing value beyond the schema.

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

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

The description clearly states it compares AI visibility across multiple entities side-by-side, probes with ai_visibility_check, ranks by score, and surfaces most/least recognized. It distinguishes from sibling tools like ai_visibility_check (single entity) and compare_entities.

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

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

The description includes an explicit use case ('competitive AI-marketing audits') and a concrete example question. It implies when to use but doesn't explicitly state when not to use or provide alternatives, though 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, idempotentHint, and destructiveHint=false. The description adds valuable behavioral context about partial failures (graceful degradation, 5-30s timeout for bundlephobia first measurement, sources_failed listing). 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 packed with essential information in a single paragraph. It is front-loaded with purpose and efficiently covers usage, behavior, and output. Slightly dense but well-structured and non-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 (composite call to two external services), the description is thorough. It details the return fields, mentions partial failure behavior, and ecosystem scope. With high schema coverage and annotations, the description adds sufficient context for the agent to understand inputs, outputs, and edge cases.

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

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

Schema coverage is 100%, so baseline is 3. The description adds that scoped packages (e.g., '@types/node') are accepted for the 'package' parameter, which goes beyond the schema description. This minor addition justifies a score above baseline.

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

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

The description clearly defines a composite check combining deps.dev and bundlephobia for npm packages, answering specific user questions about safety, popularity, and size. It distinguishes from sibling tools by explicitly stating it is for npm only, with alternatives for other ecosystems.

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 ('is X safe/popular/small' or 'what does adding lodash cost me') and when not to (non-npm ecosystems fall under deps.dev:version directly). Provides clear context for agent decision-making.

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

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

Discloses technical details beyond annotations: uses BGE-base-en embeddings, cosine similarity over 500-char overlapping windows, 200K char limit with truncation and flagging, and each passage includes character offsets for verification. No contradiction with annotations.

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

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

Two succinct sentences: first covers purpose and when-to-use, second details implementation and limits. Every sentence provides essential information 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?

For a tool with 3 parameters and no output schema, the description fully explains input constraints, search mechanics, and output characteristics (passages with offsets and scores), making it actionable 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 descriptions for all three parameters. The description adds value by specifying the 200K char limit with truncation behavior for 'text', providing natural-language query examples for 'query', and stating default and range for 'limit', which goes beyond the schema.

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

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

Description states 'Semantic search INSIDE a fetched record' with concrete examples like SEC 10-K body and article, clearly identifying the action and resource. It distinguishes itself by noting it pairs with ask_pipeworx_grounded.

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

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

Explicit usage context: 'Use when the record is too big to cram into the prompt — search_within saves context, returns only the passages that matter.' Also mentions alternative: 'Pairs with ask_pipeworx_grounded: fetch with the gateway, ground over the relevant passages.'

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 contradicts the 'idempotentHint: true' annotation by implying each call creates a new subscription ('Returns the new subscription id'), suggesting non-idempotent behavior. Also, no mention of idempotency in description, causing inconsistency.

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 front-loaded with purpose and organized with examples. While dense, it remains efficient and well-structured, though slightly long; still earns its length.

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

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

Given the tool's complexity (multiple types, nested delivery params, no output schema), the description is exceptionally complete: covers auth requirements, all type-specific filters, delivery channels, rate limits, webhook verification, and account prerequisites.

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

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

Schema coverage is 100%, baseline 3. Description adds significant value: explains each subscription type's params structure, delivery validation rules, rate limits, and webhook signing details, enhancing the schema's information.

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 verb ('Create'), resource ('proactive monitoring subscription'), and action ('subscribes to live-data event stream'). It specifies return of subscription ID and distinguishes from siblings like 'list_subscriptions' 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?

Description provides clear context for when to use (proactive monitoring) and enumerates supported types with examples. However, it does not explicitly state when not to use or direct to alternatives like 'recent_alerts' for manual pulling.

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. Description adds valuable context: returns live catalog examples, cross-category spread, and no side effects. No contradictions.

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

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

Front-loaded with example queries, then clear explanation. Slightly verbose but every sentence adds value. Good structure for an onboarding tool.

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

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

Given the tool's role as an onboarding entry point among many siblings, the description is complete. It explains what it returns, when to use, and how to use the parameter. No output schema needed.

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

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

Schema coverage is 100%. Description adds meaning beyond schema by listing possible topic values (finance, pharma, etc.) and explaining the effect of omitting the parameter. Provides usage examples.

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

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

Description explicitly states it is the onboarding entry point for a new agent, listing example user queries and explaining it returns category-bucketed example questions with tool+argument shapes. Clearly distinguishes from siblings like ask_pipeworx which are for actual queries.

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

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

States 'Use this FIRST when you do not yet know what Pipeworx can do' and explains when to pass topic vs omit. Could be more explicit about when not to use, but the directive is clear and practical.

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 value by explaining the output includes variable codes and value ids, and reinforces the read-only nature by saying 'metadata'. No contradictions.

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

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

Two sentences: the first defines the output, the second gives a key usage instruction. Extremely concise and front-loaded with important information.

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

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

For a simple metadata tool with full schema coverage and rich annotations, the description covers the return content and usage context completely. No output schema is needed because the description explains what is returned.

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 does not add significant detail beyond the schema's parameter descriptions; it only gives example values in examples.

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

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

The description clearly states the tool returns metadata (title, unit, last updated, variables list) and explicitly positions it as a prerequisite for get_data, distinguishing it from that sibling tool.

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

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

The description explicitly tells the agent to use this tool before get_data to learn variable codes and value ids, providing clear context. It does not list when not to use it, but the guidance is sufficient.

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

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

Discloses that the row is deactivated (not deleted) and historical events remain available via recent_alerts, adding behavioral context beyond annotations. Also mentions ownership enforcement. 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 purpose, followed by behavioral detail. No wasted words. Highly concise and well-structured.

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

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

Covers purpose, ownership, and deactivation behavior. For a simple 1-param tool, this is sufficient. Lacks mention of return value or error cases, but given no output schema and single parameter, it's fairly complete.

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

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

Schema coverage is 100% and description references 'by id' which matches schema. Description adds no extra parameter details beyond what schema provides, so baseline of 3 applies.

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

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

Description clearly states the tool cancels a subscription by id. The verb 'cancel' is specific and resource is well-defined, distinguishing it from sibling tools like 'subscribe' and 'list_subscriptions'.

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

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

Explicitly states ownership enforcement: 'you can only cancel your own subscriptions.' This provides clear context for when to use. However, it does not mention alternatives or when not to use, slightly reducing score.

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

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

Even with annotations (readOnlyHint, openWorldHint, idempotentHint), the description adds substantial behavioral context: the dual routing paths (SEC EDGAR vs. grounded pipeline), the complete verdict list, the crucial caveat that could_not_verify is not evidence and carries verification_error, and the meaning of unsupported. This goes far beyond the annotations and helps callers interpret results correctly.

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

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

The description is longer than the minimal ideal, but every sentence packs information: examples, routing logic, return values, and a critical caller-facing warning. It is well-structured with a clear progression from user intent to implementation to output semantics. It could be tightened slightly, but it is 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?

With no output schema, the description carries the burden of explaining return behavior. It does so thoroughly: it lists the six verdicts, describes the value with citation, mentions reasoning, and clarifies error semantics for could_not_verify vs unsupported. It also covers the two input modes (implicit tolerance vs. explicit override). This is complete for a tool of this complexity.

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

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

Schema description coverage is 100% for both parameters, so the baseline is 3. The description adds some useful context about tolerance_pct (e.g., 'set 1–2 for hallucination detection' and 'default implied by wording, capped at 5'), but this is a behavioral nuance rather than a fundamental semantic addition. The schema already explains what the parameters do.

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 the specific verb-phrase 'natural-language claim verification against authoritative sources' and gives multiple natural-language triggers ("fact check", "verify the claim that…"). It also details the structured SEC EDGAR path for company-financial claims and a fallback grounded pipeline for other claims, making its scope and differentiation from sibling tools clear.

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

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

It explicitly states when to use the tool: 'Use whenever the agent needs to check whether something a user said is factually correct.' It also explains that it replaces 4–6 sequential calls, which implies a preference over manual multi-step pipelines. However, it lacks explicit 'when not to use' or alternative tool names, so it misses the top score.

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