DailyMed MCP by usefulapi

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

Annotations only declare readOnlyHint=true. The description adds genuinely useful behavioral context beyond that: the response is 'raw XML text' with 'no JSON form,' which materially affects how an agent must handle the output. It also names the underlying endpoint (GET /spls/{setid}.xml).

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

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

Front-loaded with the action and resource, then content, then the critical XML-only caveat, then the workflow hint. Dense but well-organized. The 'DailyMed v2: GET /spls/{setid}.xml' trailer is arguably redundant given the endpoint context but is not wasteful.

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

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

No output schema exists, so the description carries the burden of explaining the return value, which it does fully (raw HL7 v3 SPL XML text, no JSON). Combined with the prerequisite (find setid via search first) and safety annotation, an agent has everything needed to call and interpret this tool correctly.

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

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

Schema description coverage is 100%, so the setid parameter's meaning and format are already fully documented in the schema. The description reinforces that the setid comes from dailymed_search_labels but adds no syntax or format detail beyond the schema's pattern and description. 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?

States a specific verb (Fetch) and resource (complete Structured Product Label / full FDA-approved labeling), and enumerates the content sections returned. This clearly differentiates it from siblings like dailymed_label_history, dailymed_label_media, and dailymed_label_packaging, which return narrower slices of a label.

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 the prerequisite workflow: 'Use dailymed_search_labels first to find the setid.' This gives clear context for obtaining the required ID. However, it does not explicitly contrast when to choose this full-label tool versus the narrower label_* siblings, leaving that inference to the 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?

readOnlyHint=true already establishes the safety profile, and the description confirms it is a pure listing operation returning spl_version + published_date pairs. It does not mention pagination behavior or ordering, but with annotations covering safety and the schema covering paging, a 3 is appropriate.

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 the returned shape and the resource, the second adds the use case and the underlying API endpoint. 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?

No output schema exists, so the description usefully names the return fields (spl_version, published_date), and paging is fully covered by the schema. Only minor gaps remain (ordering, whether all versions are guaranteed).

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% (setid UUID pattern, page, pagesize with defaults/max all documented), so the baseline is 3. The description re-states that setid is a label SETID but adds no syntax or paging guidance 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?

States a specific verb and resource ('List every published version (spl_version + published_date) of a label for a SETID'), names the exact fields returned, and is clearly distinct from sibling dailymed_get_label (single current label) and dailymed_search_labels (search). An agent can tell what this returns without opening the schema.

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

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

'useful to see how a drug's labeling has changed over time' gives a clear situational trigger for when to reach for history rather than the current label. No explicit exclusions or named alternatives, but the context is unambiguous.

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?

readOnlyHint=true already tells the agent this is a safe read. The description adds useful scope beyond the annotation: it returns only the current version's media and exposes mime_type and URL. It says nothing about pagination behavior, but the schema covers page/pagesize, so a 3 is appropriate.

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?

A single tight sentence with the action front-loaded, followed by the endpoint reference. Every clause earns its place and nothing is padded.

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

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

With no output schema, the description partially compensates by naming the returned fields (mime_type, URL). Pagination is left to the schema. Complete enough for a simple read-only list tool, though return shape detail is thin.

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 setid, page, and pagesize are already fully documented in the schema. The description reinforces that setid (a UUID) drives the lookup but adds no format or default details beyond what the schema provides. Baseline 3 for full 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?

States a specific verb (List) and resource (media assets / product-packaging images) and pins the scope to a label's current version for a SETID, which separates it from dailymed_label_history (past versions) and dailymed_label_packaging. It does not explicitly name a sibling, so it falls just short of the top mark.

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 or when-not-to-use guidance and no named alternative. The phrase 'for a label's current version' faintly implies a prerequisite SETID from a label lookup, but the agent must infer that on its own.

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?

readOnlyHint=true already tells the agent this is a safe read, so the safety profile is covered. The description adds useful scoping context ("current version" rather than historical versions) and the underlying endpoint. It says nothing about pagination behavior or result volume, which matters since the tool is page/pagesize driven.

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?

A single tight sentence with the resource and its scope front-loaded, followed by an endpoint reference. No filler, though the trailing "DailyMed v2: GET /spls/{setid}/ndcs" is redundant with the schema's parameter naming and earns less than the first clause.

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 three-parameter, paginated read tool with full schema coverage and annotations, the essentials are present. The gaps are the absence of pagination guidance and any differentiation from dailymed_list_ndcs, which an agent choosing among eleven siblings would benefit from.

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 page, pagesize, and setid are all documented in the schema itself with defaults, ranges, and the UUID pattern. The description only names SETID and adds no format or pagination nuance beyond the schema, so the 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?

States a specific verb (List) and resource (package-level NDCs associated with a label's current version), so the agent knows exactly what comes back. It does not differentiate itself from the sibling dailymed_list_ndcs, which presumably lists NDCs more broadly, so the boundary between the two is left to 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?

The phrase "associated with a label's current version, for a SETID" implies the usage context (you have a SETID and want its NDCs), which is a reasonable implied trigger. However, there is no explicit statement of when to prefer this over dailymed_list_ndcs or the other label-* siblings, and no prerequisites or exclusions 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?

With readOnlyHint already declaring the safety profile, the description adds genuine value by spelling out the return payload (packaging descriptions, product names, active ingredient name + strength) and mapping to the concrete DailyMed v2 endpoint GET /spls/{setid}/packaging. It stops short of noting auth needs, rate limits, or pagination behavior beyond what the schema already carries.

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?

A single tight sentence followed by the endpoint reference; the key scoping phrase 'by SETID' is placed near the end but the payload description is front-loaded. No wasted prose.

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 usefully enumerates what is returned, and the input parameters are fully covered by the schema. The main gap is guidance on choosing this tool over dailymed_get_label for label-level data.

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 all three parameters (setid, page, pagesize) are documented in the schema itself. The description only reinforces that setid is the lookup key, adding no format or semantics beyond the schema's UUID pattern note.

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 ('Get packaging descriptions plus product names and active ingredients') and scopes it to 'each product in a label, by SETID', which is more precise than a generic label fetch. It does not explicitly differentiate itself from siblings like dailymed_get_label or dailymed_label_ndcs, so it falls 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?

The phrasing implies the use case (retrieve packaging/ingredient data for a known label), but there is no explicit when-to-use guidance and no named alternative for the full-label or NDC use cases handled by siblings. Usage is inferable but not 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=true, so the safety profile is covered. The description adds that results span all labels and are paginated, plus the underlying v2 endpoint, but adds nothing about result volume, ordering, or rate limits beyond what the schema's page/pagesize hints imply.

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 front-loaded sentence carries the payload, with the DailyMed v2 endpoint appended as a compact cross-reference. Slightly redundant given pagination is already in the schema, but nothing is bloated.

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 two-parameter read-only list endpoint with no output schema, the description names the returned entities and one returned field, which is enough for an agent to call it correctly. It stops short of enumerating the full return shape or ordering.

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 (page, pagesize) are fully documented in the schema, so the baseline is 3. The word 'paginated' restates the schema rather than adding syntax or constraint detail beyond 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?

States a specific verb (List) and resource (FDA application numbers, qualified as NDA/ANDA/BLA) plus the fields returned (marketing category code). The resource is naturally distinct from siblings like dailymed_list_ndcs or dailymed_list_drug_classes, but the description never explicitly contrasts itself with those list endpoints.

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, when-not-to-use, or alternative selection guidance is provided. The only implicit cue is the resource name itself; nothing tells an agent whether to prefer this over dailymed_search_labels or the other list_* 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?

readOnlyHint=true already establishes this is a safe read, so the bar is lower. The description adds the underlying endpoint (GET /drugclasses) and the shape of returned records, but says nothing about response volume, ordering, or whether the list is exhaustive — useful context beyond annotations is thin.

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?

A single compact sentence with the field enumeration up front, followed by the endpoint reference. Nothing is wasted, though the endpoint string is marginally redundant for an agent that never sees the HTTP layer.

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 compensates by naming the returned fields, and pagination is fully covered by the schema. For a simple read-only listing tool with annotations covering safety, this is close to complete; only usage routing is missing.

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

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

Schema coverage is 100%, so page and pagesize are already fully documented in the schema with defaults and bounds. The description adds no parameter detail at all, which is the correct baseline when the schema does the work.

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 ('List pharmacologic drug classes linked to labels') and enumerates the returned fields (code, coding system, type, name), so the agent knows exactly what it gets back. It does not distinguish itself from siblings like list_drug_names or list_rxcuis, but the resource is distinct enough that confusion is unlikely.

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 prerequisites, and no routing to alternatives. The phrase 'linked to labels' hints at context but never states when an agent should call this instead of search_labels or list_drug_names.

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, so the safety profile is covered. The description usefully adds the returned field set and the underlying v2 endpoint, but says nothing about pagination, ordering, or result-size behavior beyond what the schema already states.

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 that front-load the core action and the primary filtering use case. The trailing endpoint string (GET /drugnames) is mildly redundant for an agent that cannot call raw HTTP, but it costs little.

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 compensates by naming the returned fields (name, name_type). Combined with schema-documented paging parameters, an agent has enough to call it correctly; only ordering and result-size guidance are absent.

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 all four parameters are already documented in the schema, including the name_type enum. The description restates the name_type letters and explains the intent of drug_name as a discovery filter, which is only marginal added value over structured fields — baseline 3.

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

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

States a specific verb+resource (list drug names in DailyMed) and discloses the return shape (name + name_type, B=brand/G=generic). The mention of discovering exact spellings before searching labels contrasts it functionally with dailymed_search_labels without opening either 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?

Gives a clear use case — pass drug_name as a substring to discover exact spellings before searching labels — which implicitly routes the agent away from label search. It does not name the alternative tool or state an explicit when-not condition, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds genuinely useful behavioral context beyond that: the result is paginated and the full set is large, which warns the agent to expect paging and heavy result volume. It stops short of return format or rate-limit details.

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

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

Very compact and front-loaded, with the scale caveat placed before the endpoint note. The trailing 'DailyMed v2: GET /ndcs' is endpoint trivia that adds little for an agent, so it is not perfectly waste-free.

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

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

With no output schema, the description carries the burden of describing the return, and it only implies a list of NDC codes without stating element shape or whether label metadata accompanies each code. Pagination behavior is hinted at and parameters are covered, so it is adequate but not 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 description coverage is 100%, so both parameters (page, pagesize) are already fully documented with defaults and maxima. The description's mention of 'paginated' merely echoes the schema rather than adding format or usage nuance, 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+resource ('List National Drug Codes') and adds scope ('across all labels in DailyMed'), which distinguishes it from the per-label sibling dailymed_label_ndcs. An agent can tell what it returns without opening the schema.

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

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

Usage is implied by 'across all labels', suggesting a global enumeration rather than a per-label lookup, but no when-to-use/when-not guidance or explicit alternative (e.g. dailymed_label_ndcs) is named. The agent must infer the distinction from sibling names.

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, so safety is covered. The description adds useful context the annotations don't: it is paginated and backed by the DailyMed v2 GET /rxcuis endpoint. It says nothing about rate limits, auth, ordering, or what an empty page means, so it stays at an adequate 3.

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?

A single front-loaded sentence carrying resource, returned fields, pagination, and endpoint reference with zero 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?

No output schema exists, so the description's enumeration of returned fields (rxcui, rxstring, rxtty) is genuinely load-bearing for this low-complexity list tool. Only the lack of usage routing keeps 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?

Schema description coverage is 100% and both page/pagesize are fully documented in the schema with defaults and max values. The word 'paginated' in the description adds no syntax beyond what the schema already 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 (List) and a precise resource (product-level RxNorm concept identifiers) and spells out the returned fields (rxcui + rxstring + rxtty). This cleanly separates it from siblings that list NDCs, UNIIs, drug names, or application numbers.

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 notes it is paginated but never says when to reach for this tool versus dailymed_list_ndcs, dailymed_list_drug_names, or the search tools. No prerequisites, no exclusions, no alternative routing.

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, so the safety profile is covered. The description adds only a pagination note (already in the schema) and the raw endpoint 'DailyMed v2: GET /uniis'; it discloses nothing about result ordering, total counts, or truncation behavior.

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

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

Three short sentences, zero waste, with the core purpose front-loaded before supporting routing and endpoint detail. Nothing redundant or padded.

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

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

For a simple list tool with no output schema and fully documented params, the description covers what is returned (UNII codes and active-moiety names) and that results page. Only minor gaps remain, such as whether a total count or ordering is provided.

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

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

Schema description coverage is 100%, with page and pagesize documented in the schema itself, so the baseline is 3. The description's '(paginated)' adds no syntax or default detail beyond what the schema already supplies.

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 ('List FDA UNII codes and their active-moiety names') plus the paginated scope. The mention of UNII codes/active moieties clearly separates it from siblings like dailymed_list_drug_names and dailymed_list_rxcuis.

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 tells the agent the downstream use of the output ('Use a unii_code to filter labels in dailymed_search_labels'), which implies when this tool is relevant. However, it never says when to choose this over the other list_* siblings (drug names, RxCUIs, drug classes) or any exclusion.

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?

readOnlyHint=true already establishes the safe-read profile, and the description adds real context beyond that: the cardinality assumption (one label per marketed drug product), the exact returned fields (setid, title, spl_version, published_date) despite no output schema, and the underlying DailyMed v2 GET /spls endpoint. It omits result-count/pagination behavior and any usage limits, keeping it out of the top band.

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 with no filler: what it searches, what can be filtered, what comes back and how to use it. The routing instruction is placed after the return-shape sentence it depends on, so the ordering is logical rather than repetitive.

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 12-parameter, all-optional search with no output schema, the description supplies the missing return-shape and result-chaining information an agent needs to act. Auth requirements, rate limits and how paging interacts with total match counts are left unstated, which is the only 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 is already documented with examples and the two enums are enumerated in the schema. The description's prose list of filters largely restates that information, adding only the NDA/ANDA gloss on application_number. Baseline 3 is appropriate 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 (Search), the exact resource (Structured Product Labels, one per marketed drug product) and the filterable dimensions. An agent can immediately distinguish it from the dailymed_get_label and dailymed_label_* siblings, which operate on a single label once a setid is known.

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 routes the caller onward: results include setid, and the description says to use that setid with dailymed_get_label and the label_* tools, which defines this tool's role as the discovery step. It does not state when to prefer this over browse-style siblings like dailymed_list_drug_names or dailymed_list_ndcs, so it falls short of full when/when-not guidance.

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