Look up drug names, RxCUIs, ingredients and interactions in RxNorm.
Glama couldn't complete the latest health check. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 13 tools
Tools mostly target distinct actions on a concept (properties, related, ndcs, history) or distinct search modes. Minor overlap exists between find_rxcui_by_name, get_drugs, approximate_match and spelling_suggestions, and between get_concept_properties and get_property, but descriptions make the boundaries reasonably clear.
All tools use the rxnorm_ prefix with snake_case verb_noun naming, which is highly predictable. The single deviation is find_rxcui_by_name using 'find' while the rest use 'get', a minor inconsistency.
13 tools is well within the sweet spot and each corresponds to a distinct RxNav/RxClass endpoint. No obvious redundancy or filler tools.
Strong coverage of the RxNorm lifecycle: name lookup, related concepts, drug classes, properties, NDCs, history, spelling, and metadata. A reverse NDC-to-RxCUI lookup and cross-vocabulary mapping are missing but most workflows are covered.
Find RxNorm concept IDs (RxCUIs) matching a drug name string. RxNav REST: GET /rxcui.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Drug name to look up, e.g. 'cymbalta'. | |
| allsrc | No | 0 = Active concepts only (default), 1 = all sources. | |
| search | No | 0 exact (default), 1 normalized, 2 exact-or-normalized, 9 approximate. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes this is a safe read, so the bar is lower. The description adds only the underlying REST route (GET /rxcui), which is traceability rather than behavior; it says nothing about result cardinality, ambiguity handling, or how multiple matches are ordered.
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, zero padding, with the core purpose front-loaded before the API reference. Nothing needs to 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?
For a single-lookup tool with full schema coverage and a readOnlyHint, the definition covers what an agent needs to call it. No output schema exists, so return format need not be explained, though a note on how ambiguous name matches are returned would have completed 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 enums for 'allsrc' and 'search' are fully documented in the schema, including defaults. The description adds no additional parameter meaning, 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?
States a specific verb and resource ('Find RxNorm concept IDs (RxCUIs) matching a drug name string'), so the agent knows exactly what it returns. It does not, however, distinguish itself from the sibling rxnorm_get_approximate_match, which overlaps on the name-lookup use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this versus alternatives such as rxnorm_get_approximate_match or rxnorm_get_spelling_suggestions, nor on when the exact/normalized/approximate modes should be selected. Usage must be inferred 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.
Fuzzy match a term against RxNorm names — tolerant of abbreviations, misspellings, and extra words. RxNav REST: GET /approximateTerm.
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | Search term, e.g. 'zocor 10 mg'. | |
| option | No | 0 = current concepts (default), 1 = include obsolete. | |
| maxEntries | No | Max candidates to return. Default 20. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is clear. The description adds useful behavioral context by specifying the fuzzy-tolerance behavior and the underlying RxNav endpoint, though it does not describe return structure, ranking, or error 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 compact sentences front-load the core matching behavior and then provide the REST endpoint. 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?
The tool is simple, all three parameters are documented in the schema, and annotations cover read-only safety. The description is nearly complete for invocation, though it could say more about what candidates or identifiers are returned since no output schema exists.
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 explains term, option, and maxEntries, including an example and enum meanings. The description adds no further parameter semantics beyond what the schema provides.
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 operation ('Fuzzy match') and resource ('RxNorm names'), and clarifies the matching tolerance for abbreviations, misspellings, and extra words. It distinguishes itself implicitly from exact-name lookup siblings, but does not explicitly name an alternative tool.
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 fuzzy-matching scope implies when this tool is appropriate, especially versus exact name lookup, but there is no explicit guidance on when to prefer it over siblings like rxnorm_find_rxcui_by_name or rxnorm_get_spelling_suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the drugs belonging to a drug class (RxClass API). RxNav REST: GET /rxclass/classMembers.
| Name | Required | Description | Default |
|---|---|---|---|
| rela | No | Relationship filter, e.g. 'may_treat' (source-dependent). | |
| ttys | No | Space-separated term types to include, e.g. 'IN MIN'. | |
| trans | No | 0 = direct members (default), 1 = include transitive. | |
| classId | Yes | Class id, e.g. 'N02BE' (ATC) or a MED-RT class id. | |
| relaSource | Yes | Class source, e.g. 'ATC', 'MEDRT', 'VA', 'DAILYMED'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safe-read profile is covered. The description adds the underlying REST endpoint (GET /rxclass/classMembers) but nothing behavioral — no pagination, response shape, transitive-vs-direct behavior, or source-specific caveats beyond what the schema's 'trans' and 'rela' descriptions already say.
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 second sentence naming the RxClass API and REST endpoint earns marginal value for developers but is essentially reference trivia for an agent, keeping it just short of a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only 5-parameter lookup with fully documented schema and readOnlyHint, the safety and input side is covered. But with no output schema, the description does not indicate what members look like (concepts, RxCUIs, names) nor how to obtain a classId, leaving modest gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all five parameters (rela, ttys, trans, classId, relaSource) are already documented with examples and enum meaning. The description adds nothing over the schema, 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?
States a specific verb+resource: retrieving the drugs that belong to a given drug class, and grounds it in the RxClass API. This distinguishes it from siblings like rxnorm_get_drug_classes (list classes) and rxnorm_get_drugs (look up drugs by name), though it never names those siblings 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?
There is no when-to-use guidance, no mention of the prerequisite of obtaining a classId first, and no routing to alternatives. The only hint is the required classId parameter in the schema, which the description does not build on.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the RxNorm properties (name, synonym, tty, language, suppress, umlscui) of a concept. RxNav REST: GET /rxcui/{rxcui}/properties.
| Name | Required | Description | Default |
|---|---|---|---|
| rxcui | Yes | RxNorm concept id (RxCUI), e.g. '617314'. |
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 description's job is lighter. It adds that the underlying call is a REST GET and lists the six fields returned, which is useful since no output schema exists, but it says nothing about error behavior for invalid RxCUIs or whether results can be empty.
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, then the endpoint mapping. Every clause carries information, though the raw REST path is arguably redundant for an MCP caller.
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 annotations covering safety and no output schema, the enumerated return fields are the key missing piece and they are present. What is absent is disambiguation from the similarly named sibling, which is the main completeness 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% and the single rxcui parameter is fully documented in the schema, so baseline 3 applies. The description only echoes the parameter implicitly via the URL template and adds no format or validity constraints beyond the schema's example.
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 (RxNorm properties of a concept) and enumerates the returned fields (name, synonym, tty, language, suppress, umlscui). It does not, however, distinguish itself from the near-identically named sibling rxnorm_get_property, leaving an 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?
There is no when-to-use guidance, no prerequisite (e.g. you must already hold an RxCUI), and no mention of when to prefer this over rxnorm_get_property or rxnorm_get_all_related. Usage must be inferred 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.
Get the drug classes that contain a drug, by drug name (RxClass API). RxNav REST: GET /rxclass/class/byDrugName.
| Name | Required | Description | Default |
|---|---|---|---|
| relas | No | Space-separated relationships, e.g. 'may_treat has_ingredient'. | |
| drugName | Yes | Drug name, e.g. 'metformin'. | |
| relaSource | No | Class source, e.g. 'MEDRT', 'ATC', 'VA', 'DAILYMED'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already establishes a safe read, and the description confirms it is a name-based lookup via the RxClass endpoint, adding modest context. It says nothing about rate limits, result shape, or whether relas/relaSource change the output set, which is where real behavioral value would lie.
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 core action, followed by the API provenance in a compact second sentence. The 'RxClass API' plus 'GET /rxclass/class/byDrugName' partly restate the same fact, a minor 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?
For a simple read-only lookup with a fully documented schema and readOnlyHint, the essential call information is present. However, nothing explains how relas/relaSource filter the returned class set or what the result resembles, leaving a moderate gap for an agent selecting among the many rxnorm 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 coverage is 100%, so drugName, relas, and relaSource are already documented in the schema, including examples. The description adds no syntax or default behaviour beyond repeating that lookup is by drug name, 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 and resource: get the drug classes that contain a drug, with the lookup key (drug name) and the backing API (RxClass). It is clearly distinguishable from general concept lookups, but it does not explicitly differentiate from the inverse sibling rxnorm_get_class_members (get members of a class), which is the likeliest confusion.
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 of when to pick this over rxnorm_get_class_members (the inverse direction) or rxnorm_get_all_related, and no prerequisites or exclusions. Usage is only implied by the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search drug products (all term types) matching a name, grouped by concept type. RxNav REST: GET /drugs.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Drug name to search, e.g. 'prednisone'. | |
| expand | No | Optional expansion, e.g. 'psn' to include prescribable names. |
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 description's extra value is the note that results are grouped by concept type and span all term types. It says nothing about result volume, pagination, or the shape of failure (e.g., no match), which limits its added context.
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 behavior front-loaded and no padding; the trailing endpoint reference is minor filler but doesn't dilute the payload.
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, fully documented read tool with no output schema, the description supplies the essential scope (all term types, grouped by concept type). Only pagination/result-size behavior is left unstated, which is a small 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 both 'name' and 'expand' are already documented with examples ('prednisone', 'psn'). The description adds nothing to parameter meaning, 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 (search) and resource (drug products, all term types) and notes the grouping by concept type. It implicitly distinguishes itself from the sibling rxnorm_find_rxcui_by_name (broad term-type search vs. single RxCUI resolution), though no sibling is 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?
The description says what it searches but gives no when-to-use guidance, no exclusions, and never routes the agent to alternatives such as rxnorm_find_rxcui_by_name or rxnorm_get_approximate_match, despite those being close neighbors.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the status, history and attributes of a concept (active, remapped, quantified, etc). RxNav REST: GET /rxcui/{rxcui}/historystatus.
| Name | Required | Description | Default |
|---|---|---|---|
| rxcui | Yes | RxNorm concept id (RxCUI). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes this is a safe, non-mutating read, so the description isn't carrying the safety burden. It adds value by naming the REST route (GET /rxcui/{rxcui}/historystatus) and enumerating possible status outcomes (active, remapped, quantified), which hints at result semantics, but says nothing about auth requirements, rate limits, or empty/unknown-concept 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 tight sentences with the capability stated first and the REST endpoint second; no filler. The URL line is mild redundancy but useful for matching documentation, so it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only lookup with no output schema, the description is largely sufficient: it names the resource and previews possible status values. It stops short of describing what the response contains or how to interpret remapped/quantified outcomes, which an agent would need for full confidence.
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 rxcui parameter is fully documented in the schema ('RxNorm concept id (RxCUI)'). The description merely embeds the same id in the URL template and adds no format, resolution, or lookup guidance, 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?
The description pairs a specific verb ('Get') with a concrete resource ('status, history and attributes of a concept') and gives example values (active, remapped, quantified), so the agent understands the payload. It's distinguishable from siblings like rxnorm_get_concept_properties, though it never explicitly contrasts itself with them or with rxnorm_get_all_related.
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: nothing says when an agent should call history_status versus concept_properties or related_by_type. The description only states what the endpoint returns, leaving the selection decision entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the NDCs (National Drug Codes) associated with a concept. RxNav REST: GET /rxcui/{rxcui}/ndcs.
| Name | Required | Description | Default |
|---|---|---|---|
| rxcui | Yes | RxNorm concept id (RxCUI). |
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 annotation carries the safety profile. The description adds only the underlying REST route (GET /rxcui/{rxcui}/ndcs), and says nothing about rate limits, whether historical/obsolete NDCs are included, or what the response contains. Little 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 REST endpoint mapping is secondary but plausibly useful for an agent correlating with RxNav docs; there is no padding 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 one-parameter read tool with annotations and no output schema, the definition is minimally sufficient, but it omits the return shape (e.g., NDC status, 9/10-digit codes) and any note about historical versus current NDCs, which an agent selecting this tool would benefit from knowing.
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 (rxcui) documented at 100% schema coverage, so the schema already carries its meaning. The description adds no format, sourcing, or validity guidance 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 ('Get the NDCs associated with a concept') and names the exact resource type (NDCs), which distinguishes it from siblings like rxnorm_get_drug_classes or rxnorm_get_related_by_type. It does not explicitly contrast with siblings, but the resource specificity makes the distinction 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?
There is no when-to-use guidance, no prerequisites (e.g., you must already have an RxCUI), and no mention of alternatives such as finding a concept first via rxnorm_find_rxcui_by_name. The agent is left to infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a named property (category, name, value) of a concept, e.g. ATC code or a synonym. RxNav REST: GET /rxcui/{rxcui}/property.
| Name | Required | Description | Default |
|---|---|---|---|
| rxcui | Yes | RxNorm concept id (RxCUI). | |
| propName | Yes | Property name, e.g. 'ATC' or 'RxNorm Synonym'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already establishes this is a safe read, so the description's remaining burden is low. It adds that this maps to RxNav GET /rxcui/{rxcui}/property and hints at the returned shape (category, name, value), but says nothing about behavior for unknown property names or 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 short sentences, front-loaded with the operation and its examples, then the underlying REST route. Nothing is wasted, though the endpoint reference is marginally useful only to a caller that cares about the wire mapping.
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 partly compensates by naming the returned tuple (category, name, value). But it omits the key disambiguation against the near-identically named plural sibling, leaving an agent to guess which of the two to call.
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 are already documented in the schema, including the 'ATC' / 'RxNorm Synonym' examples. The description restates those same examples (ATC code, synonym) without adding new semantics such as accepted property-name vocabulary or case sensitivity.
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 a named property of a concept) and gives concrete examples (ATC code, synonym), so the operation is unambiguous. However, it does not distinguish itself from the sibling rxnorm_get_concept_properties (plural), which by name sounds like the same capability.
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 use this tool versus rxnorm_get_concept_properties, rxnorm_get_all_related, or other sibling lookups. The RxNav endpoint reference implies a single-property retrieval, but the description never tells the agent when a single-property fetch is preferred over the bulk properties call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get spelling suggestions for a possibly-misspelled drug name. RxNav REST: GET /spellingsuggestions.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Drug name (possibly misspelled), e.g. 'ibuprofin'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already tells the agent this is a safe read with no side effects, so the bar is lower. The description adds the underlying RxNav endpoint, but says nothing about the shape of the result (a list of strings? scored candidates?) or any empty-result behavior. Minor added value over 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 short sentences, purpose front-loaded, zero padding. The endpoint sentence is marginally useful documentation but borders on filler for an agent that only needs the intent.
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 this is nearly sufficient, but with no output schema the description should say what comes back (e.g. a ranked list of candidate drug names) so the agent knows how to consume it. That omission and the lack of sibling routing keep it at minimum-viable.
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 there is only one parameter, whose schema description already supplies the meaning and an example ('ibuprofin'). The description adds no format constraints or terminology beyond what the schema states, 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?
States a specific verb+resource: 'Get spelling suggestions for a possibly-misspelled drug name.' An agent understands the operation immediately. However, it does not differentiate itself from the closely related sibling rxnorm_get_approximate_match, which sounds like it addresses a similar fuzzy-matching need.
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 routing among alternatives. With siblings like rxnorm_get_approximate_match and rxnorm_find_rxcui_by_name nearby, the agent is left to infer which to pick, which is exactly the ambiguity the description should resolve.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all RxNorm term types (metadata), e.g. SCD, SBD, IN, BN. RxNav REST: GET /termtypes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 that the result is RxNorm term-type metadata and cites the backing REST endpoint, which is useful provenance. No pagination, caching or rate-limit behavior is described, and nothing contradicts the annotation.
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 resource and followed by concrete examples and the endpoint. Nothing is 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?
The tool is trivial (no params, no output schema) and the description tells the agent everything needed to invoke it. Adding a note on what the return shape looks like would close the last gap, but it is not a blocker.
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?
Zero parameters means there is nothing to document, so the baseline is 4. The schema being empty and fully covered leaves no semantic gap.
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 all RxNorm term types') and distinguishes itself from siblings by describing a metadata lookup rather than a concept/RxCUI query. The examples (SCD, SBD, IN, BN) and endpoint mapping remove any ambiguity.
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 'metadata' and the example term types, so an agent can infer this is a reference/lookup call rather than a search, but there is no explicit when-to-use or when-not-to-use guidance and no mention of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
rxnorm_find_rxcui_by_namerxnorm_get_all_relatedrxnorm_get_approximate_matchrxnorm_get_class_membersrxnorm_get_concept_propertiesrxnorm_get_drug_classesrxnorm_get_drugsrxnorm_get_history_statusrxnorm_get_ndcsrxnorm_get_propertyrxnorm_get_related_by_typerxnorm_get_spelling_suggestionsrxnorm_get_term_typesDrug-drug interaction checker for clinical LLMs using RxNorm and DailyMed.
RxNorm MCP — wraps the NLM RxNav REST API (free, no auth)
Link compounds to protein targets, rank bioactivity, and look up drug mechanisms and indications.
Add one secure layer between your agents and this server.