Clinicaltrials

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

Annotations indicate read-only, open-world, idempotent, non-destructive. The description discloses that Anthropic calls require a BYO key and you pay Anthropic directly, adding behavioral context beyond annotations.

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

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

The description is front-loaded with the main action and detailed but not overly long. Every sentence adds value.

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

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

Despite no output schema, the description details return format (per-model object with score, confidence, signals, raw_response) and covers all parameters adequately.

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 3. The description adds value by explaining the API key passthrough and the context parameter's purpose, going 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 it probes LLMs for knowledge about a business/brand, scores visibility (0-100), and returns per-model results. It distinguishes from siblings like 'scan_competitor_ai_presence' by specifying the scoring and multiple model support.

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

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

The description explains default model (Workers AI free), optional Anthropic via API key, and use cases (AI-marketing audits, pre-launch checks). It lacks explicit when-not-to-use but context is clear.

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

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

Annotations already declare read-only, open-world, and idempotent behavior. The description adds context on routing to sub-tools and returning stable citation URIs, which goes beyond the annotations. No contradiction with the annotations is present.

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 excessively long, repetitive, and not front-loaded. It starts with a directive ('PREFER OVER WEB SEARCH') rather than a concise purpose, repeats similar phrases (e.g., 'START HERE', 'STEP UP ONLY WHEN NEEDED'), and includes many domain examples that could be condensed. It lacks a clear, scannable 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?

Given the tool's broad router nature, the description covers its core behavior (routing, filling arguments, returning answers with citations) and provides alternatives. It does not specify output format beyond citing URIs, but that is acceptable without an output schema. The context provided is sufficient for an agent to decide when and how 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 coverage is 100% with descriptions for all alias parameters. The tool description prose does not add any additional parameter information; it only mentions that it 'fills arguments' for sub-tools, which is unrelated to its own parameters. Per the rubric, since schema coverage is high, baseline is 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 clearly states the tool's function: routing questions to specialized tools and returning structured answers with citation URIs. It also differentiates from siblings like ask_pipeworx_grounded and deep_research by mentioning when to step up. However, the scope is broad and the description mixes usage instructions with purpose, slightly diluting clarity.

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

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

Explicitly instructs to prefer this tool over web search for most factual questions, and clearly identifies alternatives for specific cases (grounded for hallucination-resistant answers, deep_research for broad/multi-part questions). Includes examples of appropriate queries, leaving no ambiguity about when to use it.

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

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

Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds meaningful behavioral context: it is a live experimental router with candidate improvements, results are compared against the stable router, and it is fully functional. This goes beyond the annotations 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 front-loaded with the beta designation and core identity, but it includes extraneous details like the exact retirement date of the last candidate (2026-07-26) which adds noise. It is a bit long for what it conveys, but the key facts are presented first.

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 as a universal router with 5,724 tools, the description conveys it is fully functional and identical to ask_pipeworx, with the same response shape. It does not provide an explicit example, but the reference to the stable tool and the absence of an output schema are adequately handled by stating it matches ask_pipeworx exactly. The experimental nature and comparison behavior are clearly communicated.

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

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

Schema coverage is 100%, and the description adds no parameter-specific details beyond saying it shares the same arguments as ask_pipeworx. The schema already documents all six parameters and their aliases, so the description provides no additional value for parameter understanding.

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

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

The description explicitly states it is a beta version of ask_pipeworx, a universal router with identical capabilities, and clarifies its role as the experimental edge. It distinguishes itself from the stable ask_pipeworx and names the sibling, leaving no ambiguity about what the tool does.

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

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

It provides clear guidance: 'Use it exactly like ask_pipeworx when you want the newest routing.' This implies the stable version is the alternative, but it doesn't explicitly say when to prefer the stable one or mention ask_pipeworx_grounded. The experimental nature is stated, giving sufficient context for choosing between this and the stable 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?

While annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior, the description adds substantial behavioral detail: exact success and refusal response shapes, all refusal reason enums, sourcing constraints, and the cost tradeoff. 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 dense but each sentence earns its place: purpose, routing mechanism, return contract, refusal reasons, use cases, and cost tradeoff. It is front-loaded with the defining trait and structured so an agent can quickly extract key facts.

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

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

Despite having no output schema, the description fully specifies the return format on success and failure, including refusal reason values. It covers when to use, when not to use, and the relationship to ask_pipeworx, making it complete for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100% — the schema fully documents the question parameter and all aliases. The description adds no parameter-level meaning beyond the schema, so a 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 purpose: 'Hallucination-resistant answer mode for high-stakes reads' that extracts answers only from tool results. It clearly distinguishes itself from the sibling ask_pipeworx by emphasizing evidence, refusal behavior, and high-stakes usage.

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 direction: use when 'an answer will be quoted, cited, or acted on' and the agent must not invent facts, and 'prefer ask_pipeworx for casual lookups.' It also contrasts with ask_pipeworx via the extra LLM call cost.

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 annotations, detailing resolution confidence handling, closed market behavior, wide spread handling, cancellation rule parsing, and response structure. No contradictions with annotations.

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

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

The description is thorough but verbose; it includes structured sections (RESOLVER CONTRACT, PARENT_EVENT, etc.) which aid readability, but could be condensed without losing clarity.

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

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

Given the tool's complexity, the description covers all conceivable scenarios: input types, evidence fan-out, edge cases (low confidence, closed markets, wide spreads), and output shapes. No gaps remain.

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

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

Schema coverage is 100%, but the description adds valuable context: examples for market input, depth parameter with quick/thorough explanation, and include_raw with size guidance. This significantly aids correct parameter usage.

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

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

The description clearly states it researches Polymarket bets by pulling Pipeworx data, with specific input types (slug, URL, question text). The purpose is unmistakable and directly addresses user intents like 'should I bet on X'.

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 contexts are provided ('should I bet on X', 'what does the data say about Y'). While it doesn't explicitly mention when not to use or name alternatives, the guidance is clear and sufficient.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, and the description adds behavioral details: pulls latest 10-K data with off-calendar handling for companies, FAERS and FDA data for drugs, and results sorted by primary metric. 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 well-structured with front-loaded examples and concise sentences. Every sentence adds value, covering usage, data sources, and behavior 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 the tool has 2 params and no output schema, the description fully explains return data, sorting, and citation URIs. It is complete for the agent to understand input and expected output.

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

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

Schema coverage is 100% but description adds meaning: explains what data is returned for 'company' (revenue, net income, cash, debt) and 'drug' (adverse events, approval counts, trials). This goes beyond the enum values.

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

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

The description clearly states it performs side-by-side comparison of 2-5 companies or drugs, using explicit verbs like 'compare' and examples such as 'which is bigger / better'. It distinguishes itself from sibling tools like entity_profile and sequential lookups.

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

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

The description explicitly instructs 'ALWAYS PREFER over sequential single-pack lookups' and provides example queries. It also differentiates usage for company vs. drug types, giving clear context for when to invoke.

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 read-only, open-world, idempotent, non-destructive behavior. The description adds useful context: dates are sponsor-entered, may be estimated or revised, and are not guaranteed data readouts, conference presentations, or regulatory events. This goes beyond the annotations and helps calibrate expectations.

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

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

Two sentences: the first states the core function, the second provides an important interpretative caveat. No filler, no repetition of schema details, and the most action-relevant information is 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?

For a tool with 9 parameters, no output schema, and many clinical-trial siblings, the description gives the essential purpose and an important caveat, but it does not provide routing guidance against sibling tools or explain what the returned trials contain. The schema covers parameter mechanics, but the description alone leaves some contextual gaps for an agent deciding between this and related ct_* tools.

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

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

Schema description coverage is 56%, with descriptions for query, sponsor, date range, and sponsor_match. The description adds semantic weight to the date/event parameters by clarifying that these are sponsor-entered planning signals that may be revised, but it does not meaningfully explain limit, phase, or status parameters. It contributes some value but does not fully compensate for the un-described parameters.

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

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

States a specific verb and resource: finding trials with sponsor-entered primary-completion or study-completion dates within a window. The caveat about planning signals versus confirmed readouts/conference/regulatory events helps distinguish it from event-focused sibling tools, even though no sibling is named.

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 this tool is for planning-signal date windows and warns against treating the dates as guaranteed events, but it does not explicitly say when to use this tool versus alternatives like ct_search or ct_results_summary. No named alternative or exclusion condition is provided.

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

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

Annotations already declare readOnly/openWorld/idempotent, so the description adds valuable nuance: counts use the registered lead-sponsor field, the registry cannot compute true rankings, and the tool does not establish asset ownership or pipeline value. It also warns against fabricating a candidate list, which is critical behavioral disclosure beyond structured 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?

Four sentences with no filler: the first defines function, second gives a concrete use case, third covers exclusion and alternative, fourth discloses caveats. Every sentence earns its place, and key info is 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?

For a tool with 5 parameters and no output schema, the description covers the return shape (matching counts, ranked comparison, study sample), scope (lead-sponsor field), limitations (no registry group-by), and data semantics (no ownership/pipeline implications). This is fully complete for an agent to invoke and interpret the tool confidently.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning by clarifying that filters are 'identical' across all sponsors, and that the output includes a 'ranked comparison' and 'small study sample'—which maps to sample_limit. This goes beyond the schema's per-parameter descriptions, earning a 4.

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

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

The description opens with a specific verb ('Compare') and precise resource ('2–5 NAMED lead sponsors on ClinicalTrials.gov') under identical filters, immediately distinguishing it from sibling tools like ct_search or ct_sponsor_activity. The example question ('who has more recruiting Phase 3 obesity trials, Novo Nordisk or Eli Lilly?') further anchors the 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?

It explicitly states when to use the tool ('Use for questions like...') and when not to ('For an open... who are the TOP sponsors... with no names given... NEVER invent...'), providing a clear alternative (offer to compare named sponsors). This is exemplary guidance on tool 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?

Annotations already declare readOnly, openWorld, and idempotent hints. The description adds crucial interpretive context: 'The output reflects a bounded registry sample, not market share, scientific differentiation, or an exhaustive private pipeline.' This clarifies the openWorldHint and helps agents avoid misinterpreting results.

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

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

Two well-structured sentences: the first front-loads the verb and purpose, the second provides a necessary caveat. No redundant information, direct and efficient.

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

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

Given 5 parameters, no output schema, and 0% per-parameter coverage, the description is incomplete. It lacks explanation of sample_size, whether phase/status are filters, and the shape of the output. The caveat is valuable but does not compensate for these gaps.

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

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

Schema has 5 parameters with 0% description coverage. The description explains condition (required) and intervention (optional), but leaves phase, status, and sample_size unexplained. The phrase 'across sponsors, phases, statuses, and interventions' may refer to output grouping rather than input filters, creating ambiguity for agents.

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

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

The description clearly states the tool's function: 'Map registered interventional trials for a condition and optional intervention across sponsors, phases, statuses, and interventions.' The verb 'map' and explicit resource/dimensions distinguish it from siblings like ct_count_by_condition or ct_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?

The description provides clear context for when to use the tool: when you need a landscape overview of trials for a condition/intervention across sponsors, phases, statuses, and interventions. It does not explicitly name alternatives or exclusion criteria, but the focus on competitive landscape mapping implies its use case.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds value by detailing the output shape (breakdown by status and phase) and the effect of filters on the output, which goes beyond what the annotations provide.

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

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

The description is three sentences, front-loaded with the core action ('Count clinical trials...'), followed by usage context and filter behavior. No word is wasted; every sentence adds useful 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?

With an output schema present, the description doesn't need to detail return values. It covers purpose, usage, and filter behavior. Minor gaps: it doesn't specify how simultaneous status and phase filters interact or what happens when no trials match, but these are edge cases likely covered by the 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?

Schema coverage is 100%, so the baseline is 3. The description adds extra semantics by explaining that status/phase are filters that change the response to a single total without breakdown, contextualizing the condition parameter as the primary grouping entity. This enhances 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 uses a specific verb ('Count'), explicitly names the resource ('clinical trials'), and specifies the breakdown by recruitment status and trial phase. This clearly distinguishes it from sibling tools like ct_search or ct_get_study, which retrieve individual trials rather than aggregate counts.

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 a clear use case: 'Use for landscape questions about how much trial activity a disease has and where it sits in development.' It also explains the behavior of filtering ('Filtering by status or phase returns the filtered total without the breakdown'). While it doesn't explicitly name alternative tools, the context is sufficient to guide appropriate use.

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

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

The annotations already cover safety traits (read-only, idempotent, non-destructive). The description adds valuable behavioral context by clarifying that flags are mechanical review hints and not predictions of recruitment success, trial failure, or data timing. This goes beyond the annotations and helps prevent misinterpretation.

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 with no filler. The core action and criteria are front-loaded, and the interpretative caveat is separated into its own sentence. Every word earns its place.

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

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

For a read-only tool with no required parameters, the description gives enough to understand the purpose and avoid misreading flags. However, with no output schema, the agent still lacks a clear picture of what a 'routed' result looks like and how to express the enrollment/status/date criteria in a query.

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

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

With schema coverage at only 40%, the description needed to explain the actual parameters, but it does not clarify limit, phase, query, or how to specify the enrollment/status/date criteria it mentions. The description adds little operational detail beyond the schema's existing definitions.

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

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

The description states a specific action ('route') and resource ('active trials for enrollment follow-up'), with clear criteria such as registry status, enrollment type, dates, last update, and site counts. It is clear about the tool's function, though it does not explicitly distinguish it from sibling clinical-trial 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 phrase 'for enrollment follow-up' implies a use case, and the caveat that flags are mechanical hints provides some guidance on how to interpret output. However, there is no explicit statement about when to prefer this tool over alternatives like ct_search or ct_sponsor_activity.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that the tool returns specific fields (protocol, eligibility, etc.), which is consistent and provides additional transparency about the output without contradicting annotations.

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

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

The description is a single sentence that front-loads the purpose and concisely lists return contents. Every part is informative with no extraneous words.

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

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

Given the simple input schema with one parameter, comprehensive annotations, and the existence of an output schema, the description covers all necessary aspects: what it does, how to use it, and 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 description coverage is 100% with a clear param description. The tool description adds a matching example ('NCT04567890') but provides no new semantic meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description uses a specific verb ('Get') and resource ('full trial details by NCT ID'), clearly differentiating from siblings like ct_search (which is for searching) and ct_trials_by_location (filtered by location). It also lists the types of data returned.

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 when to use this tool (when you have an NCT ID and need full details). While it doesn't explicitly exclude alternative tools or states when not to use it, the sibling context makes the usage intent 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 read-only, idempotent, open-world, non-destructive behavior. Description adds details: total_count verifies exact window size, all three dates returned, sorting by chosen event date. 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?

Single paragraph with front-loaded purpose, logical flow from events to parameters to return structure to examples. Every sentence adds value, no redundancy or fluff. Efficiently packs substantial 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 all key aspects: event types, parameter usage, return fields, example scenarios. Could mention pagination or error cases, but given output schema exists and annotations are rich, the description is sufficiently complete for an AI agent to use correctly.

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

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

Schema descriptions cover all 6 parameters (100% coverage). Description adds significant value: explains date_type event volumes and deliberate selection, clarifies since/until window bounding, and notes limit vs total_count distinction. Goes well beyond schema alone.

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

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

The description clearly states the tool tracks recent ClinicalTrials.gov activity by event class, with explicit distinctions between three recency events and their volumes. It differentiates itself from siblings like ct_search or ct_count_by_condition by focusing on date-windowed activity tracking.

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 concrete use cases ('new trials registered this week', 'trials that posted results in the last month') and explains when to use each date_type. Does not explicitly name sibling alternatives or state when not to use, but the examples make the context 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 cover the read-only, non-destructive nature. The description adds context about the scope of data included and includes a caveat that registry results are not an FDA conclusion, peer review, or investment recommendation, which goes beyond what annotations convey.

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

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

The description is two sentences with no unnecessary words. The phrasing 'Project posted' is slightly awkward, but the content is focused and front-loaded with the tool's purpose.

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

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

With no output schema and only two parameters, the description provides a solid overview of the returned data categories and a caveat. It lacks details about pagination or how max_outcomes affects results, but overall it is sufficiently complete 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?

The schema already describes max_outcomes, while nct_id has no description (50% coverage). The description's phrase 'for one NCT ID' indirectly clarifies nct_id's purpose but provides no format details or further constraint. This is adequate but not fully compensating for the missing 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 explicitly states the tool retrieves ClinicalTrials.gov results for one NCT ID and enumerates the content (registered endpoints, outcome measures, statistical analyses, adverse-event counts). This clearly distinguishes it from sibling tools like ct_search or ct_get_study by focusing on posted results for a single trial.

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?

No guidance is provided on when to use this tool versus alternatives such as ct_get_study or ct_search. The description implies usage for retrieving result summaries, but it lacks explicit exclusions, prerequisites, or references to sibling tools.

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

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

Annotations already declare read-only, idempotent, non-destructive behavior. The description adds the return field set (NCT IDs, titles, status, enrollment, sponsor) and the query normalization behavior (conversational framing stripped, echoed as query_used), which sets useful expectations. 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 dense sentences with front-loaded purpose, concrete usage examples, an explicit alternative, and a concise return summary. Every sentence earns its place 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?

For a read-only search tool with a rich output schema, fully documented parameters, and annotations covering safety, the description leaves no critical gaps. It also covers query normalization and sponsor matching behavior, making the tool easy 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 coverage is 100% with rich descriptions for every parameter, including enums, union syntax, default limit, and sponsor_match semantics. The main description adds example phrasings but does not meaningfully go beyond what the schema already provides, so 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 opens with a specific verb and resource ('Search ClinicalTrials.gov for clinical trials') and immediately scopes the search dimensions (keyword, condition, drug/therapy, status, phase). It also distinguishes itself from ct_get_study, so an agent can select it correctly without opening the schema.

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

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

Explicitly says 'Use for' with concrete query examples like 'clinical trials for <disease/drug>' and named-trial lookup, and directs full design/results queries to ct_get_study. This gives the agent clear when-to-use guidance and names an alternative.

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

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

Annotations already cover read-only, open-world, idempotent, and non-destructive behavior. The description adds valuable context beyond those annotations: registry activity is not necessarily a corporate disclosure or material event, and the date window is described as verifiable. This helps an agent avoid overstating the significance of results.

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

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

The description is two sentences with no filler. The core function is front-loaded, and the second sentence adds an important caveat about materiality. Every phrase earns its place.

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

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

For a tool with 6 parameters, 2 enums, and no output schema, the description is functional but sparse. It does not describe return values, the distinction between date_type values, or sponsor_match behavior, though the schema covers sponsor_match. It is adequate but leaves noticeable gaps in context.

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

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

Schema description coverage is low at 33%, and the description partially compensates by mapping event types (newly registered studies, first-posted results, study updates) to the date_type concept and date window to since/until. However, it says nothing about limit, sponsor_match, formats, or defaults; sponsor and sponsor_match details are left to the schema.

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

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

The description clearly states the tool's purpose: tracking a sponsor's newly registered studies, first-posted results, or study updates within a verifiable date window. It names the resource and activity types specifically, but it does not explicitly differentiate this tool from similar sibling tools like ct_recent_updates or ct_sponsor_trials.

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 the use case: monitoring sponsor registry activity within a date range, and the caveat about registry activity not being a corporate disclosure or material event gives some interpretive guidance. However, it does not explicitly state when to use this tool vs. alternatives, nor does it mention exclusions.

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

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

The description explicitly discloses that the summary comes from a bounded relevance-ranked sample while still reporting the full matching count, which is important behavior beyond the annotations. It also adds a meaningful interpretive caveat that registration does not imply ownership, probability of success, or commercial value. No contradiction with the readOnly/openWorld/idempotent annotations.

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

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

Two sentences with no filler: the first states the action and scope, the second adds a necessary caveat. The most important distinguishing behavior (bounded sample, full count) is front-loaded and clearly expressed.

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 gives enough context for an agent to understand what the tool returns: a portfolio summary grouped by key dimensions, based on a sample, plus the full matching count. It also covers the key interpretation limitation. It could be slightly stronger by clarifying parameter value formats and explicitly differentiating from similar sponsor-related siblings, but it is largely complete for a read-only summarization 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 description coverage is only 40%, so the description carries some responsibility for parameter meaning. It clarifies the sample behavior and grouping dimensions, but it does not explain valid values or formats for phase, status, or sample_size beyond what the property names already suggest. The sponsor and sponsor_match parameters are already documented in the schema.

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

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

The description opens with a specific verb and resource: 'Summarize a sponsor’s ClinicalTrials.gov portfolio' and names the exact grouping dimensions (phase, status, condition, intervention). It also distinguishes the tool from a generic search/list tool by describing the bounded relevance-ranked sample and the full matching count.

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 usage context is inferable: use it when you need a portfolio-level summary rather than individual trial results. However, it never explicitly says when to prefer this over sibling tools like ct_sponsor_trials, ct_compare_sponsors, or ct_sponsor_activity, nor does it name any exclusion conditions.

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 operation safe/read-only/idempotent, so the description adds useful behavior beyond them: matching is against the registered LEAD sponsor, collaborator trials are excluded by default, and sponsor_match_field indicates which role matched. This is meaningful, non-obvious 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?

Three sentences, each earning its place: action/target, output/purpose, and the critical edge-case behavior. It is front-loaded and concise without omitting needed nuance.

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 5 parameters, output schema present, and strong annotations, the description covers purpose, output fields, and the most important matching edge case. It lacks explicit alternative-routing or pagination/rate details, but those are secondary to correct invocation for this 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 description coverage is 100%, so the schema already documents all parameters, defaults, and enum choices. The narrative description adds context around sponsor_match's inclusion/exclusion behavior but doesn't need to compensate for schema gaps.

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 action ('List'), a resource ('trials a company LEADS on ClinicalTrials.gov'), and the key scope (registered lead-sponsor field). It clearly distinguishes this from generalized trial search or collaborator-focused 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?

It gives clear context: use to map a company's research pipeline by lead-sponsor status/phase/conditions, and it explicitly notes the exclusion of collaborator-run trials unless sponsor_match asks. It doesn't name sibling alternatives explicitly, but the matching-behavior guidance is strong.

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

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

Annotations already declare readOnly, openWorld, idempotent hints. Description adds return fields (NCT id, title, status, etc.) without contradicting, providing full transparency.

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

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

Two sentences with high information density, front-loaded with primary purpose, and no unnecessary words.

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

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

Covers all relevant aspects: input modes, filtering, return values, and sibling tool references. Complete despite 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?

Schema coverage is 100%, and description adds usage patterns (condition+location OR lat+lon+radius, status defaults to RECRUITING) that go beyond individual parameter 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 clinical trials near a location, with specific verb-resource combo 'Find clinical trials near a LOCATION' and differentiates from siblings ct_search and ct_get_study.

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 prefer over web search, gives examples, and tells when to use alternatives (ct_search for keyword-only, ct_get_study for single trial).

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

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

Annotations declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds rich behavioral context beyond these: account/auth requirements incl. paid-plan gate for 'thorough', latency expectations (15-60s, up to ~90s), the gaps[] never-invented guarantee, contradictions[] flagging, per-finding hop and citation_uri fields, semantically-excerpted (not head-truncated) record handling, and depth-dependent second-hop behavior. This substantially enriches what the annotations alone convey.

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

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

The description is extremely long and dense, packing many distinct pieces of information. It is front-loaded with the critical auth requirement, which is good. However, the density makes it hard to parse quickly, and several clauses (e.g., the detailed citation_uri explanation, the excerpting detail, the latency figures) could be tightened without losing meaning. It earns its length with unique content but would benefit from trimming.

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 correctly carries the return-format burden and covers it thoroughly: findings packet with verbatim evidence, confidence, source, fetched_at, stable pipeworx:// citation, explicit gaps[], contradictions[] for standard/thorough, hop field, and resolvable citation_uri semantics. It also covers auth, latency, depth semantics, and sibling routing. Nothing an agent needs to invoke it correctly or interpret its output 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% with the depth enum fully described in the schema. The description adds value by mapping depth levels to behavioral outcomes: 'depth:"standard" re-angles unanswered gaps (gap recovery); depth:"thorough" additionally chases the best leads'. For the question parameter, it clarifies that broad/multi-part natural language is expected. This goes slightly beyond the schema's own descriptions without being redundant.

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 1497 STRUCTURED data sources... in ONE call') and explicitly distinguishes itself from open-web search ('this is NOT open-web search'). It also differentiates from the sibling ask_pipeworx by describing the single-call parallel-decomposition mechanism. An agent can clearly tell what this tool does and how it differs from alternatives.

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

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

Provides explicit when-to-use guidance ('Best for broad/multi-part questions over structured data') and when-not-to-use with named alternatives ('For a single lookup use ask_pipeworx', 'For BREAKING or colloquial CURRENT-NEWS... prefer ask_pipeworx'). It explains why the alternative is better ('routes to live news APIs'). No inference is required — the routing conditions are fully spelled out.

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 (readOnlyHint, idempotentHint, destructiveHint), the description adds that the tool returns 'top-N most relevant tools with names, descriptions, and full input schemas (with curated examples) — each result is ready to call directly.' This clarifies the output format and readiness for subsequent calls.

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 somewhat lengthy but well-structured: it starts with the core purpose, then lists use cases, explains the return value, and ends with usage guidance. Every sentence adds value, so it earns a 4.

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

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

Given the tool has 6 parameters (1 required) and no output schema, the description is comprehensive: it covers when to use, what it returns, parameter aliases, and examples. This fully compensates for the missing 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?

With 100% schema coverage, the baseline is 3. The description adds value by listing alias parameters (q, task, search, description) and providing natural language examples for the query field, making the parameter's usage clearer.

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

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

The description clearly states the tool's purpose: 'Find tools by describing the data or task.' It lists specific use cases (SEC filings, financials, etc.) and distinguishes itself from sibling tools by being the one to call first for tool 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 explicitly advises 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' It provides clear guidance on when to use, though it doesn't explicitly state when not to use.

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

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

Annotations already indicate readOnly, openWorld, idempotent, non-destructive. The description adds significant behavioral context: fans across multiple sources, returns specific data fields (CIK, filings, fundamentals, patents, news, LEI), notes that patents source may sunset May 2025 and soft-fails, and mentions fallback from GDELT to GNews. No contradictions.

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

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

The description is relatively long but every sentence adds value. It front-loads example queries and key usage advice. Minor redundancy in listing data sources could be trimmed, but overall efficient for the information density.

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 only two simple parameters and no output schema, the description adequately explains what the tool returns (with specific fields and limitations) and edge cases (patents sunset, name not supported). It is complete enough for an AI agent to use correctly.

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

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

Schema coverage is 100% with descriptions. The description adds value by providing concrete examples ('AAPL', '0000320193'), clarifying that names are not supported, and explaining that type is currently limited to 'company'. This goes beyond schema alone.

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

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

The description clearly states it creates a full cross-source profile of a US public company in one parallel call, with specific examples ('tell me about X', 'research Acme'). It distinguishes from siblings like resolve_entity by noting names are not supported, and from other tools by emphasizing it should be preferred over chaining single-source lookups.

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

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

The description explicitly says 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups' and advises using resolve_entity if only a name is available. This provides 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 declare destructiveHint=true and idempotentHint=true. The description adds that the tool deletes memories saved earlier, which is consistent but doesn't provide additional behavioral context like behavior on missing keys or side effects.

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

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

Two concise sentences with no waste. The purpose is stated first, followed by usage guidance. Every word serves a purpose.

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

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

For a simple 1-parameter tool with no output schema, the description is mostly complete. However, it does not mention behavior when the key does not exist (though idempotentHint implies safe operation). An additional sentence about expected behavior for missing keys would make it fully 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?

The input schema covers 100% of parameters, describing 'key' as 'Memory key to delete'. The description adds no further semantic detail beyond what is already in the schema, meeting the baseline.

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

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

The description clearly states the action ('delete'), the resource ('previously stored memory'), and the means ('by key'). It distinguishes from sibling tools 'remember' and 'recall' by explicitly pairing with them.

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

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

Provides explicit usage scenarios (stale context, task completion, clearing sensitive data) and suggests pairing with 'remember' and 'recall', giving clear guidance on when and with what alternatives to use.

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

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

Annotations indicate readOnlyHint, idempotentHint, and non-destructive behavior. The description adds value by explaining the extraction process (fetches, extracts title/description/key links) and output format, which complements the annotations. No contradiction found.

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, with the purpose stated first, followed by details. Every sentence adds value, and there is no unnecessary information. The structure is well-suited for quick comprehension.

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 low parameter count (2), no output schema, and no nested objects, the description covers all necessary aspects: purpose, behavior, output format, and usage examples. It is fully adequate for an agent to use the tool correctly.

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

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

Schema description coverage is 100%, and the schema already explains both parameters (url, max_links) with defaults and limits. The description adds minimal extra detail (e.g., 'default 25, max 50') which is already in the schema. Baseline 3 is appropriate as the schema does the heavy lifting.

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

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

The description clearly states the tool generates a production-ready llms.txt file for any URL, specifying the output format and concrete use cases. It distinguishes itself from sibling tools like 'scan_competitor_ai_presence' by focusing specifically on generating the standard llms.txt format.

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

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

The description lists three explicit use cases (getting a client's site indexed, drafting for own project, auditing competitor indexing), which helps the agent decide when to use this tool. However, it does not explicitly state when not to use it or mention alternatives, leaving some room for improvement.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds contextual details about the scope (caller's subscriptions) and the specific return fields, which is useful for agent understanding.

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, each with a distinct purpose: state functionality, list return fields, provide usage guidance. 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?

Given the tool's simplicity, the description covers the purpose, return format, and usage context. No missing information for an agent to use this tool effectively.

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

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

The schema already fully describes the single optional parameter with 100% coverage. The description does not add additional parameter semantics beyond implying the default behavior of listing active subscriptions.

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

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

The description clearly states it lists the caller's active subscriptions and enumerates return fields. This differentiates it from sibling tools like subscribe and unsubscribe.

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

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

The description provides explicit use cases: reviewing monitoring before adding more and finding an id to cancel. This guides the agent on when to use this tool versus its siblings.

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

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

The description goes well beyond the sparse annotations. It discloses the claim_token lifecycle (filing without an account returns a token; passing it back reads status), rate limits (5 per identifier per day), free usage, and that the team reads digests daily. It also advises not to paste end-user prompts, which is a behavioral trait not captured anywhere else.

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

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

The description is dense and front-loaded with the primary purpose. It is longer than a typical two-sentence description but every sentence adds relevant detail (conditions, exclusions, token flow, rate limit). A couple of sentences ('The team reads digests daily...') are motivational rather than strictly operational, but they do not detract from usefulness.

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

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

Despite having no output schema, the description fully explains what the tool returns: a claim_token when filing without an account, and status/resolution when using that token. It covers all input types (bug, feature, data_gap, praise), specifies exclusions, and gives lifecycle instructions. For a feedback tool with four optional parameters, this is complete.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful context around claim_token usage ('pass it back later as pipeworx_feedback({claim_token:"pwfb_…"})') and emphasizes message specificity, but the schema already describes the parameters well. The slight extra guidance on the feedback workflow justifies a 4.

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

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

The description opens with a specific verb and resource: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It clearly distinguishes this from any generic feedback tool by restricting to 'tools served by this Pipeworx connection' and contrasting with other MCP servers. The listed uses (bug, feature, data_gap, praise) make the purpose unmistakable.

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

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

Explicit when-to-use guidance is provided: 'Use when a tool returns wrong/stale data (bug), when a tool you wish existed isn't in the catalog (feature/data_gap), or when something worked surprisingly well (praise).' It also states when NOT to use it by directing feedback for other servers elsewhere, and how to identify Pipeworx tools. This is clear and actionable.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds that data is derived from CF analytics-engine, no PII, and cached 5min-1h, providing useful behavioral context beyond annotations.

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

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

Concise and well-structured with front-loaded key info and bullet-like use cases. 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?

Given the tool's simplicity (1 optional param, no output schema, clear annotations), the description covers return values, data source, and caching. Adequately 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% (window param fully described). Description adds meaningful context about shorter vs longer windows, which helps the agent choose the right parameter 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?

The description clearly states the verb 'returns' and the resource 'top tools, top packs, and total call volume' over a window. It distinguishes from siblings like ask_pipeworx by focusing on trending/usage data.

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

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

Three explicit use cases are provided, helping the agent decide when to use the tool. It does not explicitly state when not to use, but the context is clear enough.

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

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

Annotations indicate readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds detailed behavior: semantic anchor with Jaccard similarity, partition filter for placeholder slugs, fill check against CLOB depth with realizable_edge_pp <=0 meaning 'do not trade'. 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 verbose but well-structured with clear sections and bold headings. It provides comprehensive information without redundancy, earning a 4 for its balance of detail and organization.

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

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

Given the tool's complexity (two modes, fill check, partition filter, semantic anchor) and the absence of an output schema, the description explains the return structure (opportunities[], partition_check) and trade signals thoroughly. It feels 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 coverage is 100% (baseline 3). The description adds value by explaining the types of values (event slugs, Polymarket URLs, seed questions) and what happens when each parameter is used, including the trending scan with no args. This goes beyond the schema descriptions, meriting a 4.

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

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

The description clearly states the tool's purpose: finding arbitrage opportunities via monotonicity violations and partition-sum checks on Polymarket. It distinguishes two modes (event and topic) and differentiates 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 explicitly explains when to use each mode: 'Call with NO args for a trending_scan', 'event (recommended for a specific market)', and 'topic (for cross-event scanning)'. It also describes the scenario where cross-event mode is beneficial over single-event mode.

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

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

The description extensively discloses behavioral traits beyond the annotations: details three model families, caching behavior (1h KV-level, keyed on knobs), response structure with diagnostics, and limitations (e.g., Fed bets excluded). No contradiction with readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false.

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

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

The description is thorough but lengthy; it front-loads the purpose and then details model families and parameters in a structured way. While every sentence adds value, some users might find it dense. Overall, well-organized for the complexity.

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

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

Given no output schema and the tool's complexity, the description fully covers input parameters, response top-level fields, diagnostics for empty segments, and edge case handling (e.g., placeholder filters, Fed bets). It compensates for missing output schema by explaining return structure inline.

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 each parameter described. The description adds value by explaining how parameters like min_kelly, min_edge_pp, and min_partition_leg_kelly interact with the ranking and filtering logic, and provides guidance on defaults (e.g., slippage_pp rationale). Slightly above baseline.

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

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

The description clearly states the tool scans Polymarket markets for discrepancies between Pipeworx data and market prices, framed as a 'what should I bet on today' discovery agent. It distinguishes itself from sibling tools like polymarket_arbitrage and polymarket_edge_tracker by focusing on opportunity discovery across multiple model families.

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 context for when to use the tool (discovering opportunities without paging markets) and includes caveats (e.g., Fed bets unreliable, placeholder slugs skipped). However, it does not explicitly contrast with siblings or state when not to use it.

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

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

The description provides extensive behavioral context beyond annotations: snapshot frequency, TTL limits, decay computation method (daily closes non-intraday), and response structure. This fully informs the agent of operational characteristics.

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

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

The description is dense and informative, front-loading the core purpose. All sentences add value, but the lack of bullet points or structured formatting slightly reduces 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?

Without an output schema, the description fully covers return fields (tracked, expired, snapshot_dates), their meanings, and important caveats (TTL, not intraday). No gaps remain.

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

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

Schema coverage is 100% with detailed descriptions for both parameters. The description adds minor context (e.g., days default 14 max 30, window default '1wk') but mostly reinforces schema information, not significantly extending 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 tracks edge persistence and decay over time using daily snapshots. It contrasts a fresh vs old edge, making the purpose concrete. This distinguishes it from sibling tools like polymarket_edges which likely provide current edge data.

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

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

The description explains when to use the tool (to assess edge longevity) and gives insight into the response structure (tracked vs expired). However, it does not explicitly compare to alternatives or state when not to use.

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

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

Annotations indicate readOnly, idempotent, non-destructive. Description adds extensive behavioral context: walking the order book ladder, returning fill metrics, warning about partial basket fills converting arb into directional risk (dominant loss mode). 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?

Information-dense with clear structure (labels, sections). Front-loaded purpose and requirements. Slightly verbose but each sentence adds value. Efficient for the complexity.

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

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

Despite no output schema, description thoroughly documents return values (top_of_book, vwap_fill_price, slippage, verdict, etc.) and basket-specific outputs (capture_ratio, profit, thin_legs, forced_directional_risk). Covers edge cases and warnings, making it self-contained.

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

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

Schema coverage is 100% (baseline 3). Description adds value beyond schema by explaining size interpretation for basket (settlement notional per leg), default side auto-selection logic, and behavior for each parameter in both modes.

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 checks realizable vs theoretical edge against order book depth. Distinguishes between single-market and basket modes. Explicitly differentiates from siblings like polymarket_arbitrage and polymarket_edges by specifying when to use this tool (before acting on arb signals or trades above ~$500).

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

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

Provides explicit when-to-use guidance: before arb signals or trades above ~$500. Describes required parameters (market or event) with mode-specific instructions. Lacks explicit when-not-to-use statements, but context is clear enough.

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

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

Despite already having readOnlyHint, openWorldHint, idempotentHint, and destructiveHint annotations, the description adds extensive behavioral context: compatibility_codes semantics, temporal_alignment null meaning, pairing_unverified caveats, fee schedule omission, skipped comparison counters, and the explicit statement that legs with unknown metric_type or match_subtype are never paired. It is an exemplary level of disclosure beyond what annotations provide, with no contradictions.

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

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

The description is long, but every sentence earns its place given the complexity of the matching logic and the absence of an output schema. It is front-loaded with the core purpose, then flows through modes, response shape, safety fields, codes, and caveats in a logical structure. There is no filler or tautology; the length is proportional to the information an agent needs.

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 bears full responsibility for explaining return values, and it does so comprehensively: raw probabilities, matched spread entries, per-entry flags, compatibility fields, skipped/unclassified placements, temporal alignment object, fees note, and skipped counters are all described. It also explains ambiguous semantics like null temporal_alignment and the meaning of compatibility_codes, leaving virtually no gap an agent would need to guess about.

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

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

Schema coverage is 100%, but the description substantially enriches parameter understanding. It explains that `topic` is a pre-mapped macro shortcut with the full list of values, and that `kalshi_event_ticker` and `polymarket_event_slug` override the topic-mapped side for custom pairings. This override precedence and mode interaction is not present in the schema descriptions themselves.

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

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

The description opens with a precise statement of what the tool computes: the cross-venue spread between Kalshi and Polymarket for the same resolving question. It immediately distinguishes itself from Polymarket-only sibling tools and explains the 2-25pp market phenomenon that motivates the tool. The term 'spread' plus the named venues and outcome comparison make the purpose unmistakable.

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

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

The description clearly explains two modes — `topic` shortcuts versus explicit `kalshi_event_ticker` + `polymarket_event_slug` — and states that both run the identical matcher, so custom pairings are supported without behavioral differences. It also gives practical guidance that most pre-mapped topics currently return compatibility warnings and that pre-mapped is not the same as tradeable. However, it does not explicitly discuss when to use this tool versus its sibling tools like polymarket_arbitrage or polymarket_edges.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds scoping and pairing details, enhancing transparency 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, each carrying distinct information. Front-loaded with the primary action. 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 only one optional parameter and no output schema, the description covers retrieval behavior, listing mode, use cases, scoping, and paired tools. Complete for the tool's complexity.

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

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

Schema description coverage is 100%. Description restates the key parameter's usage but adds no new format or constraint details beyond the schema. Adequate but not enriched.

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

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

Description uses a specific verb ('retrieve') and resource ('value previously saved via remember'), and clearly distinguishes from sibling tools like 'remember' and 'forget' by stating the pairing.

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 ('to look up context') and the scoping mechanism. Could mention when not to use, but the description is clear enough for an agent.

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

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

Description describes mutating behavior (mark_read:true flags events as read), but annotations declare readOnlyHint=true, creating a direct contradiction between tool's advertised read-only nature and actual state-changing capability.

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 concise sentences, front-loaded with purpose. Every sentence adds useful 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?

Covers return fields (source, citation_uri, payload), filtering, state change via mark_read, polling suitability, and alternative access for scripts. All key behaviors explained despite 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?

Schema coverage is 100%, so baseline is 3. Description adds value by explaining mark_read's effect on subsequent calls, providing example for type filter, and clarifying since accepts ISO timestamps.

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 'Pull fired events from your subscription feed' with verb 'pull' and resource 'subscription feed alerts'. Distinct from sibling tools like list_subscriptions and recent_changes.

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 filtering guidance (type, since), explains mark_read for pagination, and notes polling is safe. Mentions alternative URL for scripts/dashboards, but does not explicitly compare to siblings or state when not to use.

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

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

Adds significant detail beyond readOnlyHint: fans out to three sources (SEC, GDELT→GNews, USPTO), explains fallback logic, rate-limit handling, and return structure (changes[] grouped by source). Annotations already indicate safe read, so the description enriches rather than repeats.

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 (~150 words) yet comprehensive. Front-loaded with query examples, then outlines sources, parameters, and return format. Every sentence adds value; no redundancy.

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

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

With no output schema, description explains return structure (changes[], total_changes, citation URIs). Covers error behavior (GDELT→GNews fallback, USPTO soft-fail) and provides alternative tool. Completeness is high for a complex multi-source 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%, but description adds practical usage: explains `since` accepts ISO or relative shorthand with examples, recommends '30d', clarifies `value` accepts ticker or CIK, and restricts `type` to 'company'. Goes well beyond the schema.

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

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

The description clearly states the tool retrieves recent changes for a company, with examples of queries like "What's new with X" and "latest on Y." It distinguishes from sibling entity_profile by contrasting dynamic change feed vs static profile.

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

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

Explicitly tells when to use (asking about recent changes, news) and when not to (use entity_profile for static profile). Includes fallback behavior and window recommendations, e.g., 'Use "30d" or "1m" for typical monitoring.'

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

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

Annotations indicate idempotentHint=true and destructiveHint=false. The description adds context about key-value pair scoping by identifier, persistence for authenticated users, and 24-hour retention for anonymous sessions, which goes beyond what annotations provide.

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

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

The description is a concise paragraph of three sentences, front-loaded with the core purpose. It includes examples and maintains clarity without unnecessary detail.

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 tool with full schema coverage, the description covers purpose, usage, behavioral details (scoping, retention), and pairing with sibling tools. It is complete for an agent to understand usage.

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

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

Schema coverage is 100% with clear parameter descriptions. The description does not add extra meaning beyond the schema, but the schema itself is sufficient. Baseline 3 is appropriate.

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

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

The description clearly states the verb 'Save' and the resource 'data the agent will need to reuse later'. It distinguishes itself from siblings by mentioning paired operations 'recall' and 'forget'.

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

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

The description explicitly indicates when to use: 'when you discover something worth carrying forward' with concrete examples (resolved ticker, target address, user preference, research subject). It mentions pairing with recall and forget, but does not explicitly state when not to use.

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

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

Annotations already signal read-only/idempotent behavior, and the description adds rich behavioral context beyond that: cascading internal lookups, graceful degradation of LEI/FIGI enrichment, ambiguous-name behavior returning figi_candidates, explicit unresolved identifier reporting, and source-labeling of every identifier. No contradiction with annotations exists.

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

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

The description is long, but the tool is genuinely complex and nearly every clause earns its place with caveats, examples, and behavioral notes. It is front-loaded with the general purpose and usage directive. The heavy use of nested parentheticals makes it slightly harder to scan, so it is not a perfect 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?

For a tool with no output schema, the description thoroughly covers what is returned (CIK, ticker, LEI, FIGI, RxCUI, brand/ingredient, ownership links), when nothing is asserted (figi_candidates), how unresolved identifiers are represented, and how degraded enrichment behaves. An agent has enough context to call this correctly and interpret results.

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

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

Although schema coverage is 100%, the description adds substantial meaning beyond the schema: it explains how company values map to ticker/CIK/name/ISIN, gives drug examples, and provides the critical instruction to pass only the entity name, not the full noun phrase, with the reason why. This materially improves correct invocation.

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

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

The description names a specific verb ('resolve') and resource ('user-spoken NAME to canonical/official identifiers') and states the tool's distinctive role: converting names to the identifiers other tools require. It clearly separates this from sibling tools with phrases like 'Use FIRST whenever you have a name but need an ID' and detailed type/variant examples.

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 an explicit trigger condition — 'Use FIRST whenever you have a name but need an ID' — and illustrates the lifecycle with many example phrasings. It does not explicitly name alternative sibling tools and say when NOT to use this one, so it falls just short of the strict 5-level standard.

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 that it probes each entity with 'ai_visibility_check' and returns a ranked list. It does not add contradictory behavioral info. With annotations covering safety, the description provides useful context about internal behavior.

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

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

The description is two sentences long, front-loads the purpose, then provides a use case example, and finally describes the output. Every sentence adds value with no redundancy or fluff.

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

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

Given the tool has no output schema, the description adequately describes the return format: 'ranked list with score, confidence, signal density per entity'. It also notes that 'models' can be omitted. The description is complete enough for the agent to understand what the tool does and what it returns.

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

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

Schema coverage is 100% (all parameters described). The description adds value by explaining that the first entity in the array is treated as the 'subject' for narrative and the rest as competitors, which is not in the schema. This extra context helps the agent understand the intended ordering.

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, using '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' (generic) by specifying the exact comparison mechanism and use case.

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

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

The description explicitly states the tool is useful for competitive AI-marketing audits and gives an example question ('does Claude know about us as well as our competitors?'). It implies the tool should be used when side-by-side comparison is needed. However, it does not explicitly state when not to use it or mention alternatives.

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

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

Annotations already indicate read-only, idempotent, non-destructive. Description adds behavioral details: fans out across two services, partial failure handling, bundlephobia timing (5-30s), sources_failed field, and returned fields. 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?

Single paragraph with front-loaded purpose. Every sentence adds value, though a slightly more structured format (e.g., lists) could improve readability. Minimal waste.

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

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

No output schema, so description fully explains return fields (summary block with specific fields, per-advisory detail, links, alternative versions). Covers edge cases (partial failures, timeout). Complete for a complex tool.

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

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

Schema description coverage is 100% (both parameters have descriptions). Description adds context about scoped packages and default version, but does not significantly enhance understanding beyond schema. Baseline 3 is appropriate.

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

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

Description clearly states the composite check for npm packages, specifying verb 'scan', resource 'dependency', and outputs (license, advisories, size). Distinguishes from sibling tools by mentioning NPM ecosystem and referencing deps.dev/bundlephobia, which no other sibling does.

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

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

Explicitly states when to use: 'when an agent asks "is X safe / popular / small" or "what does adding lodash cost me"'. Also mentions NPM-only in v1 and directs other ecosystems to a different tool, providing clear alternatives.

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

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

Annotations already declare readOnlyHint, idempotentHint, etc. Description adds numerous behavioral details: character offsets, similarity scores, BGE-base-en embeddings, cosine, 500-char overlapping windows, 200K char cap with truncation flag. No contradiction.

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

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

Concise: 4 sentences, front-loaded with action, efficient use of examples and technical details. No wasted words.

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

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

Given 3 parameters, no output schema, rich annotations, and moderate tool complexity, the description covers behavior, constraints, usage context, and pairing with sibling. Fully 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 covers 100% of parameters. Description adds meaningful context: 'max ~200K chars' for text, '1-20, default 5' for limit, and natural-language query examples. Adds value beyond schema.

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

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

Description clearly states the verb 'semantic search' and resource 'a fetched record' with concrete examples (SEC 10-K, article). It distinguishes from siblings by mentioning pairing with ask_pipeworx_grounded and emphasizing contextual-saving value.

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

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

Explicitly says when to use: 'when the record is too big to cram into the prompt'. No explicit 'when not to use' but the context is clear. Pairs with sibling tool for grounding.

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

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

Adds significant behavioral details beyond annotations: account requirements, type-specific parameters, delivery channel constraints (e.g., SMS cap, webhook HMAC signing), and secret handling. Annotations already provide non-readonly, idempotent, non-destructive hints which are consistent.

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

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

Well-structured and front-loaded with main purpose, then organized by type and delivery channel. Every sentence adds necessary detail without being verbose. Approximately 200 words covering all essential aspects.

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?

Very comprehensive: covers all types, delivery channels, account requirements, and returns the subscription id. However, does not clarify idempotency behavior (though hinted by annotations). Minor gap given 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?

Adds rich meaning beyond the 100% schema coverage: explains each type's purpose with examples (e.g., sec_8k with items codes), delivery options with constraints, and type-specific params. Schema alone would be insufficient for correct usage.

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

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

Clearly states 'Create a proactive monitoring subscription', which is a specific verb and resource. Distinguishes from sibling tools like list_subscriptions, unsubscribe, recent_alerts.

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

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

Explains when to use (to create a subscription) and prerequisites (Pipeworx OAuth account). Implicitly distinguishes from siblings, but does not explicitly mention when not to use or name 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 context about returning live tool catalog mappings and the behavior difference with/without topic. No contradictions, but the simple nature of the tool means limited extra disclosure needed.

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

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

The description is a single paragraph that front-loads example user questions and provides essential behavior details. Every sentence serves a purpose, though it could be slightly shortened without losing 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?

No output schema exists, but the description adequately explains the return format: category-bucketed example questions with tool and argument shape. It also mentions the live catalog of thousands of tools, giving agents sufficient context to use the tool confidently.

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

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

Schema coverage is 100% (all parameters described). The description adds value by listing example topic values ('finance', 'pharma', etc.) and explaining the behavior change when topic is omitted vs provided, going beyond the schema definition.

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

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

The description clearly states the tool returns category-bucketed example questions with exact tool mappings, and positions it as the onboarding entry point. The title 'What Can I Ask Pipeworx?' directly conveys its purpose, distinguishing it from siblings like ask_pipeworx or entity_profile.

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

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

Explicitly says 'Use this FIRST when you do not yet know what Pipeworx can do' and describes two usage modes: no arguments for full spread or topic parameter to focus. It also mentions meta-tools like ask_pipeworx as alternatives for further interaction.

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

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

Discloses ownership enforcement, row deactivation vs deletion, and idempotency beyond annotations. No contradiction with annotations (all hint values are consistent).

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 main action, no wasted words. Efficient and informative.

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

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

Given tool simplicity (1 param, no output schema), description covers purpose, ownership, side effects, and idempotency 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 describes 'id' as uuid from subscribe. Description adds minimal value, but schema coverage is 100%, so baseline 3 applies.

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

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

The description clearly states 'Cancel a subscription by id' with specific verb and resource. It distinguishes from siblings like 'subscribe' and 'list_subscriptions' by mentioning ownership enforcement and deactivation behavior.

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, guiding when to use (own subscriptions) and side effect of keeping historical events. Could mention alternatives but context is clear.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds substantial behavioral context beyond this: the return format (verdict types), the two-path routing logic, the meaning and importance of could_not_verify and unsupported, and the replacement of 4–6 sequential calls. 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?

Although the description is lengthy, every sentence provides necessary information: usage context, example phrasings, path details, return values, and critical caller warnings. It is well-organized, front-loaded with the core purpose, and free of redundant 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?

The tool has moderate-to-high complexity: two processing paths, multiple verdict values, and error semantics. Since no output schema is provided, the description correctly explains the return verdicts, the grounded/structured value with citation, and distinguishes could_not_verify from unsupported. This is complete for the tool's complexity.

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

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

Schema coverage is 100%, so the schema already documents both parameters well. The description adds extra value by explaining tolerance_pct's role ('Overrides the tolerance implied by the claim wording') and giving usage guidance (e.g., 'set 1–2 for hallucination detection'). This goes beyond the schema's basic definitions.

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

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

The description clearly states the tool's function: 'natural-language claim verification against authoritative sources.' It uses a specific verb (validate/verify) and resource (claims), and distinguishes itself from siblings by focusing on fact-checking with verdicts rather than general search or research.

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

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

The description provides clear context: 'Use whenever the agent needs to check whether something a user said is factually correct.' It also explains the two sub-pathways (SEC EDGAR for company financial claims vs. grounded pipeline for others). However, it does not explicitly name alternative tools or state when NOT to use this tool, so it falls short of a 5.

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