RxNorm MCP by usefulapi

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 bar is lower. The description adds only the underlying REST endpoint (GET /rxcui), which reinforces read-only but reveals nothing about result ambiguity, multiple matches, or error behavior on unknown names.

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 the core purpose front-loaded and no padding. The REST endpoint clause is arguably implementation detail rather than agent-facing value, but it costs only a few 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?

With no output schema, the description carries the burden of describing what comes back, and it does not — it never says whether a result is a single RxCUI, a ranked list, or empty when no match is found. Functional but with a clear gap for a lookup tool whose results are often ambiguous.

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 enums (allsrc, search) are fully documented in the schema, so the description need not repeat them. It adds no parameter meaning beyond the schema, which is the expected 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 and resource ('Find RxNorm concept IDs (RxCUIs)') scoped to a drug name string, which is more precise than the bare title. It does not explicitly distinguish itself from siblings like rxnorm_get_approximate_match or rxnorm_get_spelling_suggestions, so it lands just 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?

No when-to-use guidance, no exclusions, and no routing to alternatives. Given that approximate matching and spelling suggestion siblings exist, an agent gets no signal about when a plain name lookup is the right choice versus those 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?

readOnlyHint=true already establishes this is a safe read. The description adds useful scope context (transitive relations, all term types) and the underlying RxNav endpoint, but says nothing about result size, pagination, or response ordering despite a transitive 'allrelated' query potentially returning a large set.

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, scope stated first, endpoint reference second. No filler or restated title.

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 no output schema, the description covers purpose, scope, and the backing API. It would be fully complete with a note on the potential breadth of results, but nothing essential is missing.

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

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

One parameter with 100% schema description coverage, so the schema already documents rxcui as the RxNorm concept id. The description adds no syntax, format, or constraint detail beyond the schema, 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 ('get') and resource ('every concept ... related to a concept') with the scope qualifier 'directly or indirectly' and 'all term types'. That qualifier implicitly distinguishes it from the sibling rxnorm_get_related_by_type, though the sibling is not named 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?

Usage is only inferable: 'all term types' and 'directly or indirectly' suggest this is the unfiltered variant, versus rxnorm_get_related_by_type for narrower queries. There is no explicit when-to-use, when-not-to-use, or naming of the alternative.

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

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

Annotations only cover readOnlyHint=true. The description adds real behavioral context beyond that: the matching is fuzzy and tolerant of abbreviations, misspellings, and extra words, which tells the agent what input quality it can absorb. It still says nothing about the returned candidate list, scoring, or rate limits.

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 matching semantics come first and the upstream REST endpoint is a compact trailing note. Every clause earns its place and nothing is front-loaded incorrectly.

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-purpose lookup with a fully documented schema and a safe-read annotation, the description covers what and how well it matches. With no output schema, a brief note on the shape of the result (e.g., candidate list) would have closed the only real 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 term, option (enum for obsolete concepts), and maxEntries are already documented in the schema. The description adds no parameter-level information beyond that, which is the correct baseline 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 and resource — 'fuzzy match a term against RxNorm names' — and the phrase 'fuzzy' immediately distinguishes it from exact-match siblings like rxnorm_find_rxcui_by_name and rxnorm_get_spelling_suggestions. It does not name those siblings explicitly, 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 'tolerant of abbreviations, misspellings, and extra words' phrasing implies when this tool is appropriate (imprecise or incomplete input), but it never states when to prefer it over rxnorm_find_rxcui_by_name or rxnorm_get_spelling_suggestions. Usage is inferable rather than 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?

readOnlyHint=true already declares the safety profile, and the description matches it by naming the GET /rxclass/classMembers endpoint. It adds provenance about the data source but says nothing about result size, transitive expansion effects, or rate limiting, which would have been the genuinely useful additions.

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 the primary purpose front-loaded. The endpoint reference in sentence two is mildly redundant with the title but still concise and non-padding.

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 arguably should describe the shape of returned members or how relaSource constrains results. Combined with five parameters and no usage guidance, the definition is minimally adequate rather than 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 all five parameters (classId, relaSource, rela, ttys, trans) are already documented with examples and defaults. The description adds no parameter meaning beyond that, which meets the baseline of 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 and resource: fetching drugs that belong to a drug class, plus the underlying RxNav endpoint. The inverse relationship to a sibling like rxnorm_get_drug_classes (classes for a drug) is inferable but never explicitly contrasted.

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 rxnorm_get_drug_classes, rxnorm_get_drugs, or rxnorm_get_related_by_type. Usage is only implied by the description of what it returns.

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 as a safe read, so the bar is lower. The description adds the underlying REST endpoint (GET /rxcui/{rxcui}/properties) which is mildly useful context, but says nothing about error handling for invalid RxCUI or missing concepts.

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, both front-loaded with the essential information: what is returned first, then the 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?

For a single-parameter read tool with no output schema, the description usefully enumerates the returned properties, compensating for the absent return-value documentation. It is nearly complete, missing only routing guidance against its look-alike sibling.

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 rxcui parameter is documented with an example in the schema itself. The description adds nothing beyond restating the path parameter, 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 gives a specific verb (Get), resource (RxNorm properties of a concept), and enumerates the returned fields (name, synonym, tty, language, suppress, umlscui). However, it does not differentiate from the near-identical sibling rxnorm_get_property, leaving the agent to guess which to call.

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 prerequisites, and no mention of alternatives. The agent gets no help selecting this over rxnorm_get_property or the related-lookup 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 declares the safe read profile, so the description only needs to add context. It identifies the backing service (RxClass API / RxNav REST endpoint), but says nothing about rate limits, auth needs, or response shape.

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 core verb and resource, with no filler. The endpoint reference is terse and skimmable.

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 should ideally hint at what is returned (class ids, class names, relationship types) and whether results are grouped by relaSource. Full schema coverage and the readOnly annotation cover the invocation basics, but the return side is 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 description coverage is 100%, so drugName, relas, and relaSource are already documented with examples in the schema. The description adds no parameter semantics beyond that, which is the expected 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?

States a specific verb and resource ('Get the drug classes that contain a drug, by drug name'), which is materially different from siblings like get_class_members or get_drugs. It does not explicitly name an alternative sibling, 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 or when-not-to-use guidance and no reference to alternatives such as rxnorm_get_class_members (the inverse direction). The only implicit signal is the tool name and the 'by drug name' qualifier.

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 the underlying RxNav REST call (GET /drugs), which is useful context, but discloses nothing about response shape, paging, or grouping behavior beyond the one-line summary. Adequate but thin for a search endpoint.

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 core purpose and no filler. The endpoint reference is compact and earns its place, though it could be trimmed without loss.

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 needn't detail return values, and it does indicate the result is grouped by concept type. For a simple two-parameter read-only search, this is close to sufficient, with only minor gaps around result scope and paging.

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 both parameters (name, expand) are already documented in the schema, making baseline 3 correct. The description's 'all term types' / 'grouped by concept type' phrasing loosely relates to the expand parameter but adds no concrete syntax or format 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?

Specific verb+resource: 'Search drug products (all term types) matching a name, grouped by concept type.' This is clearer than a bare name restatement and the 'all term types' / 'grouped by concept type' phrasing hints at scope. However, it does not explicitly distinguish itself from the sibling rxnorm_find_rxcui_by_name, which sounds like an overlapping name search.

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

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

Usage is only implied by the name search framing; there is no explicit when-to-use, when-not-to-use, or alternative routing despite a crowded sibling set (find_rxcui_by_name, get_approximate_match, get_spelling_suggestions). An agent must infer that this broad drug-product search is preferred over those siblings in some cases.

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 the useful fact that results include history and status categorization (active, remapped, quantified). It discloses nothing further about return shape, pagination, or error behavior for an unknown RxCUI, and there is no output schema to compensate.

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 underlying endpoint. 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?

For a one-parameter read-only lookup with 100% schema coverage and annotations covering safety, the description supplies enough to call it correctly: what it returns and the categories of status. Only the exact response shape is unspecified, which is minor here.

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

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

Schema description coverage is 100% with a single documented rxcui parameter, so the schema carries the burden. The description only restates the parameter via the REST path /rxcui/{rxcui}/historystatus and adds no format, validity, or sourcing details.

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 (get) and resource (concept status/history/attributes) and enumerates concrete status values (active, remapped, quantified), so the agent knows what it retrieves. It does not, however, differentiate itself from the adjacent sibling rxnorm_get_concept_properties, which also promises 'attributes'.

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 prerequisites, and no named alternative is given. The agent must infer from the name alone whether this or rxnorm_get_concept_properties is the right call for concept attribute lookups.

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, non-mutating read, so the description only needs to add context. It contributes the REST endpoint, but says nothing about behavior when a concept has no NDCs, whether multiple NDCs return as a list, or whether the result is paginated.

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 what is returned; the endpoint line is useful but slightly redundant given the preceding description. 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?

For a simple single-parameter read lookup with readOnlyHint declared and no output schema, the description covers what the tool returns and how it maps to the API. It is nearly complete, though a note on empty results would close the last 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 coverage is 100% with a single required rxcui parameter that is documented in the schema, so baseline 3 applies. The description's endpoint template reinforces that rxcui is the sole input, but adds no format or validity detail 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 (get) and resource (NDCs for a concept), plus the expansion of the acronym and the underlying endpoint. It does not explicitly contrast itself with related siblings such as rxnorm_get_all_related, but the resource is distinctive enough that an agent can pick it out.

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 preconditions (e.g. that a valid RxCUI is needed first, obtainable via rxnorm_find_rxcui_by_name), and no mention of alternatives among the many sibling lookups. The agent must infer usage entirely from the 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?

readOnlyHint=true already declares this as a safe read, so the bar is lower. The description adds the underlying REST call (GET /rxcui/{rxcui}/property) and the returned property shape (category, name, value), which is useful grounding, but says nothing about auth, lookup failures for unknown property names, or rate limits.

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 purpose and examples come first, the REST mapping second. Nothing is wasted, though the endpoint reference is supplementary rather than essential for the main decision.

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

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

With 2 required params fully documented in the schema, no output schema, and no nesting, the description plus schema is nearly sufficient; it even sketches the return shape (category, name, value). The only real gap is sibling disambiguation against rxnorm_get_concept_properties.

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 (rxcui, propName) are already documented in the schema. The description's 'category, name, value' phrasing describes the return shape of a property rather than adding parameter-level detail, so it does not meaningfully exceed the schema 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?

States a specific verb (Get) and resource (a named property of a concept) and gives concrete examples (ATC code, synonym). The phrase 'a named property' implicitly distinguishes it from the sibling rxnorm_get_concept_properties (which returns all), but 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 examples 'ATC code or a synonym' imply when this tool is useful, so usage is inferable. However, there is no explicit when/when-not guidance and no routing to the very close sibling rxnorm_get_concept_properties, which an agent would need to distinguish this from.

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 declares this a safe read, so the bar is lower. The description adds only the underlying RxNav REST endpoint, which is mildly useful orientation but discloses nothing about return shape, relationship semantics, or limits.

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 the core purpose front-loaded; the REST endpoint line is minor filler but not wasteful. Nothing is buried.

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?

Adequate for a two-parameter read tool whose annotations cover safety, but with no output schema the description should say more about what 'related' concepts are returned and in what form. The agent is left to infer the response.

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 (rxcui, tty with its format example 'SCD SBD BPCK') are already documented. The description adds no syntax or meaning beyond the schema, 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?

Clear verb and resource: 'Get concepts related to a concept, restricted to the specified term types.' The 'restricted to term types' phrasing implicitly distinguishes it from the sibling rxnorm_get_all_related, though it never names that alternative 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?

No explicit when-to-use or when-not guidance and no alternatives named. The tty restriction hints at usage but leaves the agent to infer that rxnorm_get_all_related is the unfiltered counterpart.

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

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

The annotation readOnlyHint=true already tells the agent this is a safe, non-mutating lookup. The description adds no further behavioral detail such as result count limits, ranking behavior, or what happens when no suggestions exist, so it contributes only modest value beyond the 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 short sentences, front-loaded with the purpose. The trailing 'RxNav REST: GET /spellingsuggestions' is endpoint trivia that does not help an agent decide or invoke the tool, 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?

For a single-parameter read-only lookup with no output schema, the definition covers what the tool does and what input it expects. Only the differentiation from the approximate-match sibling is missing, which is a modest gap at this complexity level.

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 itself provides both the semantics and a concrete example ('ibuprofin'). The description's restatement of 'possibly-misspelled drug name' adds no syntax or format detail beyond what the schema already gives, 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 a specific verb and resource ('Get spelling suggestions for a possibly-misspelled drug name'), which clearly identifies the operation. It does not, however, distinguish itself from the closely related sibling rxnorm_get_approximate_match, leaving the agent to infer the difference.

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 'possibly-misspelled drug name' implies the input condition under which this tool is appropriate, so usage is hinted at. But there is no explicit when/when-not guidance and no mention of the near-synonym sibling rxnorm_get_approximate_match, which is the main selection ambiguity.

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 by structured data. The description adds modest context beyond that – that the result is metadata rather than patient/concept data and that it maps to GET /termtypes – but says nothing about auth, rate limits, or caching, all of which matter for an external RxNav API call.

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 sentence plus a short provenance clause. The purpose is front-loaded in the first four words and nothing is padded or repeated from the title.

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

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

For a zero-param, read-only reference tool with no output schema, the description is nearly sufficient: the examples convey the shape of the returned term-type codes and the endpoint grounds the source. A brief note on the return structure (e.g. tty/name pairs) would close the small remaining 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?

The tool takes zero parameters, so the baseline of 4 applies. There is nothing for the description to disambiguate, and it correctly avoids inventing any parameter discussion.

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?

Specific verb ('List') plus a precise resource ('RxNorm term types'), with concrete examples (SCD, SBD, IN, BN) and even the backing REST endpoint. This is clearly distinguished from every sibling, which all operate on specific concepts or drugs rather than the static vocabulary.

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 rather than stated: an agent can infer this is a static reference lookup useful for interpreting TTY values returned elsewhere, but the description never says when to call it, when not to, or which sibling it complements. No exclusions or alternatives are given.

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