Health & medicines

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

Annotations already declare the safe-read profile (readOnlyHint, idempotentHint, non-destructive, openWorld), so the bar is lower. The description still adds real context beyond structured fields: it states the cost model ('free within the daily allowance, then $0.003 USDC per call via x402') and that results include matching trial sites, which is uncommon and agent-relevant.

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 tight sentences with the purpose front-loaded and the pricing clause placed second. Nothing is redundant, though the x402 payment detail is somewhat tangential to selection and could be trimmed.

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

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

With an output schema present, return values need not be described, and annotations carry the safety profile. The description covers purpose, scope, and cost, leaving only minor gaps such as how 'near a place' is bounded (radius/proximity) and pagination behavior, both of which are partly covered by the page_token parameter.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters (limit, location, condition, page_token). The description only echoes 'a condition in a city, region or country' matching the location/condition params and adds no syntax, format, or range detail, so baseline 3 is appropriate.

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

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

The description names a specific resource and scope: 'Studies recruiting (or about to) for a condition in a city, region or country, with the matching trial sites.' The 'recruiting' status filter plus 'near a place' implicitly separates it from clinical-trials__search/stats/study, but it never names an alternative explicitly, so differentiation is inferred rather than stated.

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?

Usage is only implied by the resource framing (recruiting trials near a place). There is no explicit when-to-use/when-not, no prerequisites, and no routing to clinical-trials__search for non-recruiting lookups, so an agent must infer the boundary from the tool name.

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/non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context by disclosing the cost model: free within the daily allowance, then $0.003 USDC per call via x402. That payment/rate-limit detail is real value beyond structured fields, though no pagination behavior is described.

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 compact sentences, front-loaded with the searchable axes and ending with the cost note. Both sentences earn their place; minor redundancy in re-listing status/phase filters that also appear in the schema.

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?

An output schema exists, so return values and next_page_token needn't be explained. For a zero-required-parameter search tool with 100% schema coverage, the description covers inputs and cost adequately; only pagination semantics and sibling routing could add more.

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

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

Schema description coverage is 100%, so every parameter is already documented in the schema. The description restates the filter categories at a high level (condition, intervention, location, sponsor, status, phase) without adding syntax, format, or default guidance beyond what the schema provides. Baseline 3 is correct when 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?

States a specific verb (find) and resource (studies) plus the full set of search axes: condition, intervention, location, sponsor, free text, with optional status/phase filters. This scope distinguishes it from siblings like clinical-trials__recruiting or clinical-trials__study, though it never names those alternatives explicitly.

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 enumerates what can be searched and what can be filtered, which implies when the tool applies, but offers no explicit when-to-use versus clinical-trials__recruiting or stats, and no exclusion conditions. Usage is inferred rather than directed.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely useful non-structured context: the pricing model ('a few free samples a day, then $0.003 USDC per call via x402'), which an agent cannot infer from the schema or annotations.

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

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

Two sentences, front-loaded with the core purpose and followed by the cost note. No filler; each sentence carries distinct 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?

An output schema exists, so return values needn't be explained. Purpose, status breakdown, and pricing are all covered; only the when-to-use routing against sibling tools is missing.

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

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

Schema description coverage is 100% for the single 'condition' parameter, so the schema already documents it fully. The description adds no syntax or format detail for the condition input, so the baseline of 3 applies.

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

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

The description names a specific resource (registered studies for a condition) and the exact output dimension (counts broken down by recruiting/active/completed/terminated/withdrawn). This clearly differentiates it from siblings like recruiting or search, though it doesn't name those siblings directly.

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?

There is no explicit guidance on when to use this tool versus clinical-trials__recruiting, clinical-trials__search, or clinical-trials__study. The aggregate-count use case is implied by 'how many', but no conditions or exclusions are stated.

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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context the annotations lack: the pricing/rate model (free within a daily allowance, then $0.002 USDC per call via x402). It does not say what happens on an invalid or unknown NCT number, which is the main remaining gap.

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

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

One dense, front-loaded sentence: scope first ('One study'), then payload fields, then the commercial/pricing clause. No wasted sentences, though the long comma-separated field list is slightly list-like and the pricing tail is appended somewhat abruptly.

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 simple (one required ID parameter) and an output schema exists, so return values need not be explained — yet most of the description's word budget goes to enumerating returned fields, which the output schema already carries. For a complete picture an agent would still want to know error behavior for invalid/withdrawn NCT IDs and confirmation that the call is a single-record lookup; the pricing disclosure is the main compensating value.

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

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

Schema description coverage is 100%, so the sole parameter nct_id is documented structurally, and the schema's own text ('NCT number') is thin enough that the description's mention of the NCT number is not redundant filler. Still, the description adds no format detail (e.g., 'NCT' + 8 digits) or validation behavior, 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 opens with 'One study' and enumerates exactly what the record contains (title, status, phase, conditions, interventions, sponsor, enrolment, dates, eligibility, outcomes, countries, results-posted flag), which distinguishes it from sibling list/search tools like clinical-trials__search and clinical-trials__recruiting. The retrieval verb ('fetch'/'return') is left implicit, but the resource and scope are unambiguous.

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

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

Usage is only implied: 'One study ... NCT number' suggests lookup-by-identifier rather than browsing, which routes an agent away from search/recruiting. However, no explicit when-to-use statement, no named alternative, and no guidance on prerequisites (e.g., needing a valid NCT ID or what to do if unknown) are given.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive, openWorld). The description adds genuinely new behavioral context: the cost model (free within the daily allowance, then $0.001 USDC per call via x402), which is decision-relevant for an agent and absent from structured fields. It doesn't describe pagination or error behavior, but the added cost disclosure 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?

Two sentences, front-loaded with returned fields before the pricing note. No filler. The content sentence is a dense list, but every element earns its place.

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

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

With an output schema present, return values need not be explained, and annotations carry the safety profile. The description covers scope, returned fields, and pricing, leaving little an agent needs missing, though explicit sibling routing would complete it.

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

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

Schema description coverage is 100% and the single 'code' parameter is already documented with concrete examples (RVV, G82052). The description only reinforces the 'one ODS code' scope without adding format or syntax beyond the schema, 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 gives a specific verb-less but concrete resource enumeration: name, status, address, phone/website, roles and relationships for one ODS code. An agent understands this is a single-entity lookup keyed by ODS code, distinct from the search sibling. It doesn't explicitly name which sibling to use instead, so it lands at 4 rather than 5.

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

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

The phrase 'for one ODS code' implies this is the single-entity retrieval path versus nhs-organisations__search, but there is no explicit when-to-use/when-not guidance or named alternative. Usage is inferable but never stated.

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

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

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: the enumeration is complete ('Every ODS role code') and there is a cost model (free within the daily allowance, then $0.0005 USDC per call via x402), which is material for an agent deciding whether to invoke.

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 tight sentences: the first front-loads what the tool returns, the second front-loads the cost condition. Every clause earns its place with no filler.

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

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

With an output schema present, return values need not be explained, and with zero parameters there is no schema gap to fill. Annotations cover safety, and the description covers scope and pricing; only minor omissions (e.g. whether the code list is versioned or how often it changes) keep it from a 5.

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

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

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. The reference to aliases that 'search accepts' adds a small amount of interpretive value about how the returned data is consumed, but no parameter semantics exist to document.

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

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

States a specific resource ('Every ODS role code with its name') and the added value (friendly aliases accepted by search), so an agent knows this is a static reference/enumeration lookup rather than a filtered query. It does not explicitly name sibling tools like nhs-organisations__search to differentiate, keeping it short of a 5.

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?

Usage is only implied: the mention of 'the friendly aliases search accepts' hints this is the companion lookup for resolving role codes before calling search, but there is no explicit when-to-use or when-not-to-use statement and no named alternative. Pricing terms are given, but that is not 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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: a free daily allowance followed by a $0.001 USDC x402 charge per call, which is a real cost/threshold constraint an agent should know before invoking.

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 tightly packed sentences with zero filler: capability and role list first, cost model second. Every clause carries 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 5 optional parameters, a 100% description coverage and an output schema handling return values, the description covers what an agent needs. It omits one thing worth stating — whether a call with no filters is valid or one filter is required — but that is a minor gap.

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

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

Schema description coverage is 100%, so every parameter (name, role, limit, status, postcode) is already documented in the schema, including defaults and the role enumeration. The description largely restates that vocabulary rather than adding format or matching semantics, so the 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?

States a specific verb ('Find') and resource ('NHS organisations') and enumerates the searchable dimensions (name, postcode/district, role) plus the full set of role types. An agent can distinguish it from sibling nhs-organisations__organisation (single-record lookup) and nhs-organisations__roles from the description alone.

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?

Usage is implied by the enumerated search keys, but there is no explicit when-to-use statement and no routing to the sibling tools (organisation for detail lookup, roles for role listings). The only non-purpose sentence is about pricing, not 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful pricing/payment context ('free daily allowance' and '$0.003 USDC per call via x402'), but does not describe search behavior, pagination, or authentication requirements.

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 short sentences with no filler, front-loading the data domain and following with cost information. Every sentence earns its place.

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

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

The output schema and high schema coverage reduce the burden on the description, and the resource and pricing are conveyed. However, the lack of verb clarity and usage guidance leaves the definition at minimum viability for an agent selecting among many openFDA and external siblings.

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 both parameters are documented in the input schema. The description adds no further meaning about the required 'search' expression or the 'limit' semantics, so the baseline of 3 is appropriate.

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

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

The description names the resource ('Premarket 510(k) clearances') but omits a specific verb such as search or retrieve. It distinguishes the subject from siblings like device-events and device-recalls, but leaves the action implicit.

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?

There is no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. The only added context is pricing, which does not help the agent choose between sibling openFDA 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 cover the safety profile (readOnly, openWorld, idempotent, non-destructive), so the description's contribution is the cost model: free within the daily allowance, then $0.003 USDC per call via x402. That is genuinely useful behavioral context an agent needs for cost-aware routing, though auth/quota specifics remain unstated.

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 short, front-loaded sentences with zero waste: the resource identity comes first and the pricing caveat second. Every sentence carries distinct 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, return values need no description, and the two params are fully covered by the schema. The description adds the source database and cost model, but omits how to construct a valid openFDA search expression, which would help an agent avoid failed calls.

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

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

Schema description coverage is 100%, so the schema already documents both parameters (search expression, limit default/max). The description adds no syntax or format detail for the search expression, so the 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 identifies the specific resource: MAUDE medical device adverse event reports, which is distinctive enough to distinguish it from openfda__device-recalls and openfda__drug-adverse-events. However, it is a noun phrase with no explicit verb (search/query/fetch), leaving the action to be inferred from the schema.

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

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

There is no guidance on when to use this tool versus its many siblings (device-510k, device-recalls, drug-adverse-events), nor any prerequisites or context. Usage must be inferred entirely from the resource name.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds genuinely useful behavioral context the annotations do not: cost model (free within daily allowance, then $0.003 USDC per call via x402). It says nothing about result volume, pagination, or rate limits beyond the allowance.

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 short sentences, resource identified first, pricing second; every word carries information and nothing is padded. It is arguably under-specified rather than over-long, but for the conciseness dimension itself the structure is tight.

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?

An output schema exists, so return values need not be explained, and the schema covers both parameters. However, for a search-driven endpoint the description omits how to actually query it and any distinction from sibling endpoints, leaving the agent to infer usage entirely from the 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 description coverage is 100%, so both parameters (search, limit) are already documented in the schema, establishing the baseline of 3. The description adds no syntax or format guidance for the openFDA search expression, so it does not exceed 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 names the specific resource (medical device recalls), which cleanly separates it from siblings like openfda__device-events, openfda__device-510k, and openfda__drug-recalls. It lacks an explicit verb (search/list/retrieve), but the noun phrase plus the sibling set makes the purpose unambiguous.

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

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

There is no when-to-use guidance, no mention that a search expression is required, and no routing advice versus the other openFDA endpoints. The only conditional text concerns billing, not invocation context.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context — a cost model (free within the daily allowance, then $0.003 USDC per call via x402), which matters for an agent deciding whether to call. It omits what the allowance actually is, auth requirements for x402, and result-set size behavior.

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

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

Two sentences, purpose front-loaded, no filler. The pricing sentence earns its place by conveying a decision-relevant cost signal rather than restating metadata.

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?

An output schema exists so return values need no explanation, but the description leaves the openFDA query-expression convention entirely to the bare schema label, and gives no sibling routing. Adequate but with a clear gap where invocation correctness is concerned.

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 only two parameters, so the baseline is 3. The description adds nothing about the openFDA search expression syntax, which is the one parameter most likely to be invoked incorrectly, and no guidance on the limit/pagination tradeoff.

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

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

States a specific resource (FAERS adverse event reports) scoped to a drug, which is enough for an agent to distinguish it from siblings like drug-recalls, drug-labels, and device-events by resource name alone. It stops short of an explicit sibling comparison or an example of what an adverse event report contains.

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 when-to-use guidance, no mention of alternatives (e.g. drug-recalls for recall data, food-adverse-events for food), and no hint that the required 'search' parameter is how you bind the query to a specific drug. The only framing is pricing, which is not usage 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, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds genuinely useful context the annotations do not: a cost model with a free daily allowance and $0.003 USDC per call via x402, which affects invocation volume decisions. It stops short of stating the allowance size or auth/payment mechanics.

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 compact sentences with no filler, and the payload description is front-loaded ahead of the pricing note. Nothing is wasted, though the brevity comes at the cost of onboarding 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?

An output schema exists, so return values need not be explained, and annotations carry the safety profile. However, the description omits any guidance on the required search expression format and on how this endpoint differs from the other openFDA drug tools, leaving meaningful gaps for a query-driven API.

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 only two parameters, so the schema already documents limit and search. The description adds no syntax or format detail for the non-trivial openFDA search expression, 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 names a specific resource (structured prescribing information) and enumerates its content areas (indications, dosage, warnings, interactions), which is enough for an agent to understand what is returned. It lacks an explicit verb and does not distinguish itself from nearby siblings like openfda__drug-adverse-events, openfda__drug-recalls, or openfda__drugs-fda.

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?

There is no guidance on when to use this tool versus the many other openFDA drug endpoints or RxNorm alternatives. The only usage-adjacent information is billing (free within daily allowance, then per-call pricing), which says nothing about selection criteria.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld). The description adds cost/rate-limit context, which is genuinely useful since it is not in the annotations. However, it says nothing about what the search returns, pagination, or what happens when the allowance is exhausted.

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 short sentences with no waste and the pricing constraint front-loaded. Slightly under-specified rather than verbose, but structurally 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?

With annotations carrying the safety profile and an output schema present, return format need not be described. But for an openFDA search tool sharing a namespace with many near-siblings, the description lacks scope/disambiguation and any hint of expected usage, leaving a notable gap.

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 limit and search are documented in the schema, including the default and max for limit. The description adds no parameter-level detail, 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?

States the resource 'National Drug Code directory entries' and implies lookup, but the sentence is a noun phrase without a verb. Siblings like openfda__drugs-fda, openfda__drug-labels and rxnorm__ndc make it hard to tell what distinguishes this NDC directory from the other NDC/drug tools.

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

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

The only guidance is pricing ('free within the daily allowance, then $0.003 USDC per call'). There is no statement of when to use this tool versus openfda__drugs-fda or rxnorm__ndc/ndcs, and no 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful non-schema context — that calls are free within a daily allowance and cost $0.003 USDC per call via x402 — but says nothing about result ordering, pagination, or query behavior.

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

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

Two short sentences with no filler; the resource is front-loaded before the pricing detail. It is efficient, though the second sentence covers cost rather than usage, so brevity comes partly at the expense of 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?

An output schema exists, so return values need not be described. Still, the tool's required parameter is a free-form 'openFDA search expression' with no syntax example or common field references (drug name, classification, report date), which is the main thing an agent needs to invoke it 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%, with both parameters documented (search expression, limit default 10/max 100), so the baseline is 3. The description adds no syntax hints for the openFDA search expression or interaction with limit, so it does not exceed the schema.

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

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

The description states a specific resource (drug recall enforcement reports) and the domain word 'Drug' distinguishes it from the device-recalls and food-recalls siblings. However, it uses no verb and gives no sense of what the tool returns or how results are shaped, so it is clear but not fully differentiated in action terms.

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?

There is no guidance on when to use this tool versus related siblings such as openfda__drug-adverse-events, openfda__drug-labels, or openfda__device-recalls. The only conditional statement is about billing, not about selecting this tool for a task.

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 carry the safety profile (readOnly, idempotent, openWorld, non-destructive), so the description adds value by disclosing the cost model: free within a daily allowance, then $0.003 USDC per call via x402. That is exactly the kind of operational context annotations cannot express. It falls short of a 5 only because it says nothing about pagination behavior or result-volume expectations.

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

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

Two sentences, no filler, and the function ('FDA approval history for an application or brand') is front-loaded ahead of the billing note. Every clause carries information the agent needs.

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

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

An output schema exists, so return values needn't be explained, and annotations cover the safety profile. However, the tool is search-driven and the description gives no orientation on the openFDA search expression syntax or result scoping, and it never routes the agent away from the many adjacent openFDA drug endpoints — a meaningful gap for a 2-param query 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% for both parameters (limit and search), so the schema already does the heavy lifting — baseline 3. The description's mention of 'an application or brand' hints at what the search expression should target but adds no actual syntax or format guidance beyond the schema's 'openFDA search expression'.

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

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

States a specific verb+resource: 'FDA approval history (Drugs@FDA) for an application or brand.' An agent can tell this is approval/regulatory-history data rather than labels, NDC codes, recalls, or adverse events. It does not, however, explicitly name or contrast with the nearest siblings (drug-labels, drug-ndc), so it stops short of a 5.

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?

There is no when-to-use guidance, no when-not-to-use, and no reference to any alternative tool. The agent must infer from the phrase 'approval history' that this is the right endpoint versus openfda__drug-labels or openfda__drug-ndc. No prerequisites or eligibility conditions are stated.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world behavior, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: the pricing model (free within a daily allowance, then $0.003 USDC per call via x402), which materially affects whether an agent should call it repeatedly.

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 tight sentences: the first front-loads what the tool returns, the second the cost model. No filler, and the most important scoping information comes first.

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

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

With an output schema present, return values need not be explained, and annotations cover the safety profile. For a simple two-parameter query tool the description is largely complete, missing only explicit routing guidance among the many sibling openFDA tools.

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

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

Schema description coverage is 100%, so both parameters (limit and search) are already documented in the schema. The description adds no additional meaning about the search expression syntax or limit behavior, so the baseline of 3 applies.

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

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

The description names the specific data source (CAERS reports) and scopes it to foods, supplements and cosmetics, which distinguishes it from openfda__drug-adverse-events and openfda__device-events by domain. It lacks an explicit verb (query/retrieve), so it is clear but not maximally 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?

There is no when-to-use guidance, no statement of when this should be chosen over the sibling adverse-event tools, and no note about prerequisites or the meaning of the required search expression. The domain scope implies usage but nothing is explicit.

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

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

Annotations already cover the safety profile (readOnly, idempotent, open-world, non-destructive), so the bar is lower. The description adds genuinely useful non-schema context: a free daily allowance and $0.003 USDC per call via x402, which directly informs an agent's decision and budget behavior. It still omits pagination/result-size behavior, so not a 5.

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 tight sentences: purpose first, pricing second. Nothing is redundant and the most decision-relevant facts are 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?

An output schema exists, so return values need no explanation, and the cost model is a helpful addition. However, for a search tool the description gives no query-expression guidance or usage context, leaving a gap an agent must fill from the schema alone.

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 'search' and 'limit' are already documented structurally — baseline 3 applies. The description adds no syntax or format detail for the 'openFDA search expression' beyond what the schema states.

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?

Names a specific resource ('Food recall enforcement reports') that cleanly distinguishes it from siblings like drug-recalls, device-recalls, and food-adverse-events. It lacks an explicit verb, but the resource scope is unambiguous enough that an agent knows what it retrieves.

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 when-to-use guidance and no mention of alternatives. It never tells the agent how this differs in practice from openfda__drug-recalls or openfda__food-adverse-events, nor what the required 'search' expression is for.

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 non-destructive behavior, so the safety profile is covered. The description meaningfully adds the cost and rate-limit model ('a few free samples a day, then $0.002 USDC per call via x402'), which an agent needs before invoking a paid endpoint. Return-format disclosure is unnecessary since an output schema exists.

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

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

Two short sentences, zero filler, and the scope statement is front-loaded ahead of the cost note. Every sentence carries distinct 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?

Safety, parameters, and return shape are covered by annotations, the schema, and the output schema respectively. The notable gap is sibling differentiation: with both pubmed__search and clinical-trials__search present, the description should say when this narrow clinical-trial-filtered endpoint is preferred.

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 documents the sole 'term' parameter including the '[pt] filter' hint. The description adds no syntax or semantics beyond the schema, so the baseline of 3 is appropriate.

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

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

The description states a specific resource and a narrowing scope: 'PubMed citations that are clinical trial reports for a query.' This functionally distinguishes it from the broader pubmed__search, though it never names that sibling explicitly. Purpose is clear, but routing between the two pubmed search tools still takes inference.

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?

There is no guidance on when to use this tool versus pubmed__search or pubmed__pmc-search, despite those siblings existing. The only conditional information given is the pricing model, which is not a usage-selection rule. An agent must guess based on the tool name alone.

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, openWorldHint, and destructiveHint=false. The description adds valuable behavioral context beyond annotations: a daily free-sample quota and a per-call cost via x402. It does not detail how payment is authorized or what happens when the free quota is exceeded, but the cost disclosure is meaningful.

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 short sentences, front-loaded with the purpose and followed by the cost model. Every sentence earns its place; there is no filler or repetition.

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 a single required parameter, rich annotations, and an output schema, the description covers what the tool returns (article IDs) and the cost model. It omits usage context relative to sibling tools, but that is the main gap rather than a missing critical detail.

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

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

Schema coverage is 100% for the single 'term' parameter, which is documented as 'Query'. The description does not add any parameter-level semantics, so the baseline of 3 applies when the schema already carries the full burden.

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

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

The description names the resource and scope: 'Free full-text article ids in PubMed Central.' This differentiates it from sibling pubmed__search (general PubMed) and other PubMed tools by focusing on PMC full-text article IDs. The verb 'search' is absent from the description itself, though the tool name and title supply it.

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

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

There is no explicit guidance on when to use this tool versus alternatives such as pubmed__search or pubmed__clinical-trials-search. The pricing model implies a paid search but does not state conditions for choosing this tool over 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?

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds genuinely useful non-schema context: a free-sample quota and a per-call price ($0.002 USDC via x402), which matters for agent call budgeting. It stops short of describing result format or pagination.

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 tight sentences, front-loaded with what is returned before the cost caveat. No filler.

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

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

With an output schema present, the description needn't explain return values, and it covers input syntax and cost. It is adequate for a 1-parameter tool, with only sibling differentiation and result-count/limit behavior left unaddressed.

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

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

Schema coverage is 100% and the single 'term' parameter is described only as 'Query'. The description adds real value by noting support for PubMed query syntax, which tells the agent the accepted input format beyond the schema's minimal label.

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

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

Clearly states it returns PubMed ids matching a query, which is a specific verb+resource+return type. However, it does not differentiate itself from close siblings like pubmed__pmc-search, pubmed__clinical-trials-search, or pubmed__summary, so an agent must infer the distinction from names alone.

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?

There is no guidance on when to use this versus the many sibling search tools (PMC, clinical trials, summary). Usage is only implied by the mention of PubMed query syntax; no prerequisites or exclusions are stated.

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 readOnly, idempotent, openWorld, and non-destructive behavior. The description adds pricing/rate-limit context ('A few free samples a day, then $0.002 USDC per call via x402'), which is genuinely useful behavioral information beyond annotations. However, it doesn't disclose failure modes for invalid IDs or output format details. With annotations handling safety, a 3 is reasonable.

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

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

Two concise sentences front-loading the return fields and input format, then pricing. No wasted words, though the pricing sentence could be seen as slightly tangential to core function.

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, return format details are not needed. The description covers input format, output fields, and pricing. It lacks workflow guidance (e.g., get IDs from search) but is otherwise complete for a simple lookup tool.

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

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

Schema coverage is 100%, and the single parameter is documented as 'PMIDs, comma separated'. The description confirms the comma-separated format, reinforcing the schema. For a single well-documented parameter, this is sufficient. Baseline 4 for 0-1 params with high 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?

States a specific verb+resource: returns article metadata (title, authors, journal, date, DOI) for given PubMed IDs. Distinguishes itself from sibling pubmed__search by being an ID-based lookup rather than a search. It doesn't explicitly name siblings, but the input shape (comma-separated IDs) makes its role clear.

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

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

No guidance on when to use this versus pubmed__search or pubmed__pmc-search. The pricing note implies it's for metadata retrieval, but it doesn't say to call search first to obtain IDs. An agent must infer the workflow.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: a pricing/allowance model (free within the daily allowance, then $0.002 USDC per call via x402), which is not expressible in annotations and matters for agent cost decisions.

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 tight sentences with the core function front-loaded and the pricing caveat second. Every clause earns its place with no filler.

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

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

With an output schema present, return values need not be explained, and annotations plus full schema coverage handle the rest. The description complements this with pricing context; the only real gap is the unresolved overlap with rxnorm__spelling.

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

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

Schema description coverage is 100%, so both 'term' and 'limit' are already documented in the schema. The description adds no syntax, format, or ranking details beyond what the schema provides, making the baseline 3 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?

States a specific verb and resource ('Ranked RxNorm candidates') plus the input condition (misspelled or partial drug name), so the operation is clear. However, it does not differentiate from the close sibling rxnorm__spelling, which by name appears to serve a nearly identical fuzzy-matching 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 phrase 'misspelled or partial drug name' implies when the tool is useful, but there is no explicit when-to-use guidance, no statement of when to prefer exact-match tools (rxnorm__rxcui, rxnorm__drugs), and no mention of the likely overlap with rxnorm__spelling.

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 readOnly, idempotent, openWorld and non-destructive behavior, so the safety profile is free. The description adds genuinely new operational context: a metered pricing model (free within a daily allowance, then $0.002 USDC per call via x402) that an agent cannot learn from structured fields.

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 tightly written sentences, front-loaded with what is returned and how it is grouped, followed by the cost condition. No filler 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 an output schema present, return values need no explanation, and the annotations plus pricing disclosure cover most of what an agent needs for a one-parameter lookup. The only real gap is routing relative to the other rxnorm tools, which is not addressed.

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?

There is a single parameter with 100% schema description coverage ('Drug name (ingredient or brand)'), so the schema does the work. The description's 'for an ingredient or brand name' merely restates it without adding format, casing or normalization guidance.

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

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

States a specific resource and scope: returns clinical drugs, branded drugs and packs for an ingredient or brand name, grouped by RxNorm term type. That is more specific than a bare 'get drugs', but it never distinguishes itself from siblings like rxnorm__approximate, rxnorm__spelling or rxnorm__rxcui, which an agent must choose between for name-based 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 phrase 'for an ingredient or brand name' implies the input context and therefore when the tool applies, but there is no explicit when-to-use or when-not-to-use guidance and no mention of the sibling tools that handle fuzzy spelling, codes or related concepts. Usage is left to inference.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety burden is lifted. The description adds genuinely new operational context: a free daily allowance and $0.001 USDC per call beyond it, which an agent needs for cost-aware invocation.

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 tight sentences with the core mapping front-loaded before the billing caveat. 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?

An output schema exists so return values needn't be explained, and annotations cover safety. The description is nearly complete for a single-parameter lookup, with only when-to-use routing left unaddressed.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds the accepted NDC length (10 or 11 digits) which the schema description does not state. Hyphen tolerance is already in the schema, so this is a modest but real increment.

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

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

States a specific transformation: an NDC (10 or 11 digits) to its RxNorm concept and status. The direction is clear and implicitly distinguishes it from the plural sibling rxnorm__ndcs (the reverse lookup), though it never names that sibling explicitly.

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 says nothing about when to use this tool versus rxnorm__ndcs, rxnorm__rxcui, or rxnorm__approximate. The only added context is billing, not 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, non-destructive, and openWorld, so the safety profile is covered. The description adds genuinely useful non-annotation context—the pricing model (free within the daily allowance, then $0.001 USDC per call via x402) and the 'Active'-only scoping—but does not explain what constitutes an active vs inactive NDC or any rate-limit specifics.

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 short, front-loaded sentences with no filler; the resource is stated first and the pricing caveat second. Efficient and scannable, though nothing is trimmed to the point of losing the pricing 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?

With an output schema present, return values need not be described, and the single parameter is fully documented. What remains missing is the relationship to the near-identical sibling rxnorm__ndc, which matters more than usual given how close the names are.

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

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

Schema coverage is 100% for the single required rxcui parameter, so the baseline is 3. The phrase 'clinical or branded drug' nudges toward accepted RxCUI types, but adds little beyond what the schema description already states.

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

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

The description states a specific resource ('Active National Drug Codes') and the input it operates on ('an RxNorm clinical or branded drug'), so the agent knows what comes back. It does not, however, differentiate itself from the singular sibling rxnorm__ndc, leaving the plural/singular distinction to be inferred.

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?

There is no explicit when-to-use guidance, no mention of alternatives such as rxnorm__ndc or rxnorm__properties, and no preconditions stated. The word 'Active' implies a filtering behavior but the description never says when this tool is the right choice.

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

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

Annotations already declare read-only, idempotent, open-world, non-destructive behavior, so the safety profile is covered. The description adds a genuinely useful trait not present in structured data: the pricing model (free within a daily allowance, then $0.001 USDC per call via x402), which is important for an agent to know before invoking.

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 tight sentences that are front-loaded with the returned fields and follow with the cost model. Nothing is wasted, though it is terse enough to leave usage context unaddressed.

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?

An output schema exists, so return values need not be described, and annotations cover the safety profile. For a single-parameter lookup, the description covers the essential behavior (what is returned plus cost), though the absence of any routing guidance keeps it from being 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?

With a single parameter and 100% schema description coverage, the schema fully documents rxcui, so the baseline is 3. The description does not add any format or syntax detail about the RxCUI beyond what the schema states.

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

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

The description names the specific fields returned (name, synonym, term type, active/obsolete status) and the resource (an RxCUI), which clearly distinguishes it from siblings like rxnorm__related or rxnorm__approximate. It stops short of explicitly naming an alternative, but the scope is unambiguous.

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

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

No when-to-use or when-not-to-use guidance is given. With siblings such as rxnorm__rxcui, rxnorm__related, and rxnorm__drugs available, the description never explains which lookup to pick for which need, leaving the agent to infer from the name alone.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely useful context the annotations lack: the cost model (free within the daily allowance, then $0.002 USDC per call via x402), which informs call budgeting. It does not describe return shape, but an output schema exists to carry that.

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 compact sentences that are front-loaded with the capability before the pricing detail. No filler; the only mild criticism is that the pricing clause competes for attention with the functional statement.

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 single-parameter, read-only lookup with an output schema and rich annotations, the description supplies what the structured fields cannot: the conceptual scope of the results and the cost/quota behavior. What it omits, sibling differentiation, is useful but not essential to invoking it 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?

Only one parameter (rxcui) with 100% schema description coverage, so the schema fully documents the input. The description says 'related to an RxCUI' but adds no syntax, format, or validity detail beyond the schema, making the baseline 3 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?

States a clear resource (related concepts for an RxCUI) and enumerates the returned categories (ingredients, brand names, dose forms, clinical/branded drugs), which is more than a tautology. It does not, however, explicitly distinguish itself from close siblings like rxnorm__drugs or rxnorm__properties, which also surface drug concepts.

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?

There is no guidance on when to choose this tool over rxnorm__drugs, rxnorm__properties, or rxnorm__approximate. The pricing sentence describes cost, not usage conditions, so the agent must infer selection criteria from the name alone.

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 safety profile (readOnly, idempotent, openWorld, non-destructive), so the bar is lower. The description adds genuinely useful non-annotation context: the metered pricing model (free daily allowance, then $0.001 USDC per call via x402) and the plural 'concept id(s)' hinting multiple matches may return.

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 tight sentences with the matching semantics front-loaded and the cost model second. No filler 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?

An output schema exists so return values need not be explained, and the one-parameter surface is simple. The description covers match type, result shape hint, and pricing, though it does not spell out what 'normalised' means in practice (case, punctuation, salt forms).

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

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

Schema coverage is 100% with a single optional-free 'name' parameter already described as 'Drug name (ingredient or brand)'. The description adds no syntax, format, or matching-rule detail beyond what the schema provides, so the 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?

States a specific verb (exact normalised match) and resource (drug name to RxNorm concept id(s)). The word 'Exact' implicitly distinguishes it from rxnorm__approximate and rxnorm__spelling, but no sibling is named outright.

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?

Usage is only implied: 'Exact (normalised) match' signals this is the precise-lookup path, leaving the agent to infer that approximate or spelling variants live in sibling tools. No explicit when-to-use or when-not-to-use statement.

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

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

Annotations already cover the read-only, idempotent, non-destructive, open-world profile, so the bar is lower. The description adds genuinely new behavioral context not present in structured fields: a free daily allowance and a $0.001 USDC per-call charge via x402, which tells the agent there is a cost/quota dimension to invoking 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?

Two short sentences with no filler; the functional statement is front-loaded and the pricing caveat follows. Nothing reads as redundant.

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

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

An output schema exists, so return-format explanation is not required, and the tool is a simple single-input lookup. The description covers purpose and cost, but omits what happens on no-match and how many suggestions are returned, which is a minor gap for the agent.

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

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

With a single parameter and 100% schema description coverage, the schema already documents 'name' as the drug name as typed. The description adds no further semantic detail (e.g. formatting, case sensitivity, multi-word handling), so the 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 first sentence states a specific resource and outcome: correctly spelled RxNorm drug names near the input, which is enough for an agent to know this is a spelling-correction/lookup tool. It does not, however, distinguish itself from the close sibling rxnorm__approximate, which plausibly overlaps in intent.

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?

There is no statement of when to prefer this tool over rxnorm__approximate or other RxNorm siblings, nor any condition for use (e.g. misspelled input). The only contextual note is commercial (pricing), not usage guidance.

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