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?

Beyond the annotations (readOnly, openWorld, idempotent), the description discloses critical behavioral details: it routes to 5,529 tools across 1,455 sources, fills arguments, returns stable pipeworx:// citation URIs, and works on every tier with one fast call. It also subtly discloses a limitation by recommending the 'grounded' variant for hallucination-resistant answers with verbatim evidence, which is valuable transparency about the trade-off.

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

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

The description is long but front-loaded with the most important guidance ('PREFER OVER WEB SEARCH'). Most sentences earn their place, though a few phrases are redundant (e.g., 'START HERE for most questions' and 'this is the default entry point' restate similar ideas). The structured flow from use cases to examples to escalation paths is effective.

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

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

Given that there is no output schema, the description still tells the agent what to expect ('structured answer with stable pipeworx:// citation URIs'). It also positions the tool among 42 siblings, clarifying when to use this default instead of ask_pipeworx_grounded, deep_research, or news-focused tools. This is complete for an entry-point tool.

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

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

The input schema already covers 100% of the parameters with aliases and examples, so the baseline is 3. The description adds value by providing additional real-world examples ('current US unemployment rate', 'Apple's latest 10-K', 'adverse events for ozempic') that illustrate the semantic range of the question parameter beyond what the schema's examples show.

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

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

The description opens with a clear directive ('PREFER OVER WEB SEARCH') and specifies the tool's function: 'Routes the question to the right one of 5,529 tools... and returns the structured answer.' It names concrete domains (SEC filings, FDA drug data, FRED/BLS, etc.) and distinguishes itself from siblings like ask_pipeworx_grounded and deep_research, so the purpose is 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 explicitly states when to use this tool ('Use whenever the user asks...'), when to prefer it over web search, and when to step up to alternatives ('Step up only when needed: for a hallucination-resistant single answer... use ask_pipeworx_grounded; for a broad/multi-part question... use deep_research'). This is a textbook example of providing usage context and 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?

Beyond annotations (read-only, idempotent), the description discloses crucial behavioral traits: candidate routing improvements may be enabled live, currently no candidate is active so it matches ask_pipeworx exactly, and it is a full working router. This experimental context is valuable for an agent deciding whether to invoke it.

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 moderately long but every sentence adds distinct information: beta status, identical behavior, experimental candidate status, usage instructions, and the working-router nature. It is well-structured and front-loaded with the core purpose.

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

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

The tool is fully contextualized: its relationship to ask_pipeworx, its current state, and its response shape are all mentioned. Since it references the same response shape as ask_pipeworx, the lack of an output schema is sufficiently compensated.

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 six parameters are aliases for 'question' and are described clearly in the input schema. The description adds no parameter-specific semantics beyond noting that arguments are identical to ask_pipeworx, so the baseline score of 3 applies.

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

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

The description clearly identifies ask_pipeworx_beta as a beta version of ask_pipeworx, a universal router with the same 5,529 tools, arguments, and response shape. This distinguishes it from its sibling ask_pipeworx and other tools by emphasizing its experimental role.

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

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

It explicitly states when to use this tool: 'Use it exactly like ask_pipeworx when you want the newest routing.' It also implies the alternative (ask_pipeworx for stable routing) and notes that results are compared against the stable router for merging decisions.

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 annotations already indicating a safe read-only operation, the description adds crucial behavioral detail: exact return shape, refusal reasons, the extra LLM call cost, and the promise to not invent facts. 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?

Dense but well-organized: purpose, mechanism, use cases, exceptions, and tradeoff all in one paragraph. Every sentence contributes meaningful information; no redundancy or 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?

Even without an output schema, the description fully specifies the return contract on both success and refusal paths. It explains routing, evidence extraction, cost, and intended contexts, making the tool 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 covers 100% of parameters, with all six parameters clearly documenting aliases for a single natural-language question. The description adds no additional parameter meaning, which is acceptable given thorough schema coverage.

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

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

Describes a specific, distinctive behavior: hallucination-resistant, evidence-grounding answer extraction. Clearly differentiates from ask_pipeworx by emphasizing extraction limited to tool result and explicit refusal 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 when to use (answers quoted, cited, or acted upon; high-stakes factual reads) and when not to (casual lookups, where ask_pipeworx is preferred). Names the alternative tool and even notes the cost tradeoff.

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?

The description adds significant context beyond the readOnlyHint: it warns that dates may be estimated or revised and are planning signals, not guaranteed readouts or regulatory events. This sets expectations about data reliability and interpretation, which is valuable.

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

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

The description is two sentences, front-loaded with the main action and followed by a crucial caveat about data reliability. It is concise, structured, and contains no redundant 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 8 parameters and no output schema, the description covers the input concept and data semantics well but lacks details on output format, pagination, or sorting. For a list-returning tool, this is a moderate gap but not severely incomplete.

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 only 38%, so the description carries partial responsibility. It clarifies the meaning of 'dates' (primary-completion vs study-completion) and the window concept, aiding understanding of event_type and date parameters. However, it does not explain parameters like phase, status, sponsor, or limit.

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: finding trials with sponsor-entered primary-completion or study-completion dates in a specified window. It uses a specific verb ('Find') and resource ('trials'), and distinguishes from sibling tools by focusing on registry date windows.

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

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

The description implies use for date-window queries and clarifies the meaning of registry dates, but it does not explicitly state when to use this tool over alternatives like ct_search or ct_recent_updates. No exclusions or alternative recommendations are 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?

Annotations already declare the tool read-only and idempotent. The description adds valuable context about flag semantics—they are 'mechanical review hints—not predictions of recruitment success, trial failure, or data timing'—which helps the agent avoid misinterpreting outputs. No contradiction with annotations.

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

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

The description is two concise sentences, front-loaded with the primary action and followed by a critical caveat. Both sentences add value, with no wasted words.

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

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

The description covers the tool's purpose and flag interpretation, but with no output schema, it does not describe the return format or content. Parameter semantics are also incomplete, leaving some gaps for an agent to invoke the tool correctly. The read-only nature and example mitigate the gaps somewhat.

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 0%, and the description does not explain the four parameters (limit, phase, query, sponsor). While it mentions criteria like registry status and site counts, these are not linked to the actual input parameters. The example provides minimal context but no formal parameter meaning.

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

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

The description clearly states the tool's function with a specific verb ('Route') and resource ('active trials for enrollment follow-up'), listing concrete criteria used (registry status, enrollment type, dates, last update, site counts). This effectively distinguishes it from related sibling tools like ct_search or 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?

The description implies a use case for enrollment follow-up but does not explicitly state when to use this tool over alternatives or provide exclusion criteria. The additional note about flags is interpretive guidance rather than usage direction.

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 readOnlyHint=true, and the description adds that it returns NCT IDs, titles, status, enrollment, sponsor info. Also discloses that conversational framing is stripped and the actual query term is echoed back, which is behavior not captured in 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 one paragraph, front-loaded with the main action. It includes examples and guidance, but could be slightly more structured for readability.

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

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

Given 5 parameters, 1 required, and presence of output schema, the description covers what the tool does, what it returns, how to use it effectively, and contrasts with a sibling. It is fully adequate for an AI agent.

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

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

Input schema covers all parameters (100% coverage). The description adds meaning beyond schema by advising on optimal parameter usage (prefer topic alone, put status/phase in respective fields) and explaining the 'query_used' echo behavior.

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

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

The description clearly states it searches ClinicalTrials.gov for clinical trials, with specific use cases (by keyword, condition, drug/therapy, status, phase). It distinguishes itself from sibling tool 'ct_get_study' by noting that the sibling is for full design/results.

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

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

Explicitly states when to use it: 'for clinical trials for <disease/drug>', or to locate a specific study. Also provides exclusion: 'use ct_get_study for its full design/results'.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the baseline is lower. The description adds meaningful behavioral context by specifying the types of activities tracked (newly registered, first-posted results, updates) and clarifying that registry activity may not be a corporate disclosure. This helps set expectations about data interpretation beyond the annotations.

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

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

The description is exactly two sentences, front-loaded with the action and resource. It is concise, with no redundant phrasing or filler. Every sentence earns its place, making it easy for an agent to parse quickly.

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 5 parameters and no output schema, the description is somewhat minimal. It does not mention the return format, pagination via limit, or how to handle the sponsor field (e.g., exact name matching). The caveat about corporate disclosure is useful, but for a tool with multiple parameters and no output schema, more detail would be needed for full completeness.

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

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

With 0% schema description coverage, the description must compensate. It mentions 'newly registered studies, first-posted results, or study updates' which maps to the date_type enum (first_posted, results_posted, last_update), and 'verifiable date window' maps to since/until. However, it does not explain the sponsor parameter or limit, nor does it clarify how to specify the date window (e.g., required since). The description provides partial parameter semantics but not complete coverage.

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

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

The description uses the specific verb 'Track' and clearly identifies the resource: a sponsor's newly registered studies, first-posted results, or study updates within a verifiable date window. This distinguishes it from sibling tools like ct_sponsor_pipeline or ct_sponsor_trials by focusing on date-bounded activity events. The caveat about registry activity not being a corporate disclosure adds important context without obscuring the core 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?

The description implies usage for monitoring sponsor activity in a specific date range, but it does not explicitly state when to use this tool over alternatives or provide exclusions. The caveat 'Registry activity is not necessarily a corporate disclosure or material event' offers a subtle hint about appropriateness, but no direct comparison to siblings like ct_recent_updates or ct_sponsor_trials is given. This is minimal guidance.

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

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

The description adds meaningful behavioral context beyond the annotations: it discloses that the output is based on a bounded relevance-ranked sample (not full enumeration) while still reporting the full matching count. It also includes an important caveat that registration does not imply asset ownership or commercial value, which helps with result interpretation.

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

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

Two sentences, front-loaded with the primary function and a crucial caveat. Every word earns its place; no fluff or redundancy.

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

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

With no output schema and no parameter descriptions, the description plus annotations give a solid picture: read-only, sampled, full count, and interpretation warning. However, the agent may still be unsure about input value formats or the exact output structure, and sample_size semantics are a bit vague.

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 0%, so the description must compensate. It mentions phase, status, condition, and intervention as grouping dimensions, but condition and intervention are not in the schema, and it does not explicitly clarify how sample_size controls the bounded sample or that sponsor is required. It provides some meaning but leaves ambiguity.

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 'Summarize' and clearly identifies the target resource (sponsor's ClinicalTrials.gov portfolio) with explicit grouping dimensions (phase, status, condition, intervention). This distinguishes it from sibling tools like ct_sponsor_trials, which would likely list individual trials rather than aggregate 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?

The description implies the tool is used for portfolio-level summaries but does not explicitly state when to use it over alternatives like ct_sponsor_activity or ct_sponsor_trials, nor does it mention exclusions. The caveat about registration is about interpretation, not tool selection guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds that it returns specific fields (status, phase, conditions), which provides useful context 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 two sentences, front-loaded with the main action and a quick summary of return fields. No wasted words.

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

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

Given the tool has an output schema and 100% parameter coverage, the description is adequately complete. It could mention pagination or default limit, but the schema provides that detail, so it's acceptable.

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

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

Schema coverage is 100% with descriptions for all parameters. The description only mentions sponsor implicitly and does not add new semantic information beyond the schema. Baseline score 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 'List' and resource 'trials by sponsor or organization name', clearly stating what the tool does. It also mentions return fields (status, phase, conditions), which helps distinguish it from siblings like ct_search or ct_count_by_condition.

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

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

The description implies usage when needing trials by sponsor, but does not explicitly contrast with sibling tools or state when not to use it. No exclusion criteria or alternative recommendations are 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 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?

Beyond the annotations (readOnlyHint, idempotentHint, etc.), the description discloses account requirements, paid tier for 'thorough', expected latency, and the full findings packet structure including gaps[], contradictions[], hop fields, citation_uri semantics, and semantic excerpting of large records. It also states that it never invents answers, adding trust-relevant behavioral detail.

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

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

Although the description is long, every sentence earns its place: it covers account prerequisites, purpose, mechanism, use cases, alternatives, depth behaviors, citation reliability, excerpting, and expected latency—all without redundancy. The information is dense and well-organized in a single cohesive block, making it highly efficient for its scope.

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 thoroughly explains the return packet (evidence, confidence, source, timestamp, citations) and edge cases (gaps[], contradictions[], citation_uri resolution). It also covers prerequisites (account/paid plan), performance expectations, and how the tool handles large records, making it complete for a tool of this complexity.

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

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

The input schema already provides detailed descriptions for both parameters (question required, depth enum with per-level facet counts and behavior), so the baseline is 3. The description adds extra context on depth-specific behavior (gap recovery, contradictions, paid plan), timing (15-90s), and the natural-language nature of the question, which is valuable but not essential 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 performs grounded multi-source research across 1455 structured data sources in one call, explicitly distinguishing itself from open-web search and from sibling tools like ask_pipeworx. It specifies the verb 'research' and the resource 'Pipeworx's 1455 STRUCTURED data sources', making its function unmistakable and differentiated.

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

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

The description provides explicit when-to-use guidance: best for broad/multi-part structured-data questions, and specifically names alternatives for single lookups ('For a single lookup use ask_pipeworx'), breaking/current-news topics ('prefer ask_pipeworx'), and signed-out users ('use ask_pipeworx instead'). It also notes that deep_research returns empty gaps for topics not in the structured catalog, giving clear exclusion criteria.

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

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

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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds substantial behavioral context: compatibility_warning conditions, temporal alignment, skipped_cross_type/subtype, and when spreads are meaningless. 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 structured with sections (TWO MODES, RESPONSE, SAFETY FIELDS). It uses emphasis effectively. While long, each sentence adds value given the tool's complexity. Could be slightly trimmed but overall concise for the information conveyed.

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

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

Despite no output schema, the description covers return structure (leg-by-leg prices, top_spreads_pp), safety fields, compatibility conditions, and temporal alignment. It fully explains when spreads are valid and what to expect, making it 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%, and the description adds meaning: it explains the shortcut list for 'topic' and the override behavior of explicit parameters. It also clarifies how parameters interact and what values are expected, adding 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?

The description clearly states it computes cross-venue spread between Kalshi and Polymarket for the same resolving question. It distinguishes two modes (topic shortcuts and explicit tickers) and explains when spreads are meaningful, differentiating it from siblings like polymarket_arbitrage.

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

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

The description explicitly outlines two modes and when to use each, and warns that pre-mapped topics often return compatibility warnings. However, it does not explicitly contrast with sibling tools, though the context is clear.

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

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

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

Beyond annotations (readOnly, idempotent, openWorld, non-destructive), the description discloses rich behavioral traits: labels every identifier with its source, explicitly states unresolved identifiers under `unresolved` instead of omitting them, and 'degrades gracefully' if GLEIF/OpenFIGI are unavailable. It also reveals internal cascading of lookups, adding transparency about how results are produced.

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

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

The description is front-loaded with example queries and a clear directive. It is structured with 'SUPPORTED TYPES' sections, making it easy to scan. Every sentence adds unique value—source labeling, degradation behavior, replacement of manual lookups—so no part is wasted. Length is justified by the tool's 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?

For a complex tool with two params and no output schema, the description covers everything an agent needs: what types are supported, what each type returns, input formats, behavior on unresolved identifiers, and graceful degradation. It preemptively answers likely questions (e.g., what happens when a source is down) and clearly explains outputs even without a formal 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?

Although the schema already provides basic descriptions for `type` and `value`, the description adds substantial meaning: for 'company' it explains the 'cross-source identity spine' (CIK, ticker, LEI, FIGI) and accepted input forms (ticker, CIK, name); for 'drug' it clarifies RxCUI, ingredient, brand, and citation. Examples like 'AAPL' and 'ozempic' further clarify 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 states the specific purpose: 'resolve a user-spoken NAME to the canonical/official identifiers other tools require as input.' It provides concrete example queries ('What's the ticker for…', 'find the CIK for…') and distinguishes itself from siblings by declaring 'Use FIRST whenever you have a name but need an ID.' This clearly separates it from tools like entity_profile or compare_entities.

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

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

Explicit usage guidance is given: 'Use FIRST whenever you have a name but need an ID.' It also clarifies that the tool replaces 2-3 manual lookups, indicating when to use it. The description details the supported entity types (company, drug) and input formats, giving practical 'when to use' context without confusion with 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=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.