Pharmacy MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct operation: interaction checks (single/multi/food), drug info retrieval (search, get info, dosage, warnings), dose calculations (weight, BSA, pediatric, infusion, conversion), Taiwan-specific (NHI, TFDA, coverage, price, translation), formulary management (search, item, order validation, submit, stop), and PK simulations (formula catalog, mechanism, simulation). There is no meaningful overlap, and agents can clearly distinguish between them.
Naming Consistency5/5
All tool names use consistent snake_case with a verb_noun pattern (e.g., check_drug_interaction, get_drug_info, calculate_dose_by_weight, list_nhi_coverage_rules). The naming is descriptive and follows a predictable structure across all subdomains, with no mixing of conventions.
Tool Count4/5
33 tools is a high count, but it reflects the server's broad scope covering drug information, interactions, dose calculations, Taiwan NHI features, hospital formulary, and PK simulations. The tools are well-scoped and necessary for the comprehensive purpose, though the number edges above the typical 'well-scoped' range.
Completeness4/5
The tool surface covers core pharmacy operations: drug lookup, interaction checks, dose calculations, Taiwan-specific queries, formulary order management, and PK simulations. Minor gaps exist (e.g., drug-allergy checking, medication reconciliation), but the set is largely complete for its stated purpose in a Taiwan healthcare context.
Average 3.5/5 across 33 of 33 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 28 commits in the last 12 weeks
- Last stable release on May 17, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It mentions an 'Agent contract' that instructs on preserving certain output fields, but does not disclose traits like error behavior, unsupported drug handling, or result nature beyond the core simulation function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise with two sentences plus a contract clause, and the main purpose is front-loaded. However, the contract adds length without aiding core understanding, and the structure is somewhat informal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, PK simulation, output schema exists but not explained), the description is severely incomplete. It lacks guidance on required parameters, unsupported drugs, result interpretation, and does not leverage the presence of an output schema to clarify return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, but the description adds no meaning to the parameters. It mentions 'explicit user-supplied parameters' but does not explain what fm, ki, cl_total, or inhibitor_concentration represent, leaving the agent to infer from parameter names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'Run' and the resource 'PBPK-lite CYP reversible inhibition exposure estimate', and clarifies it uses explicit user-supplied parameters for a supported drug pair. It is clear but does not explicitly differentiate from sibling simulation tools like simulate_concentration_time.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide when to use this tool versus alternatives. It only includes an 'Agent contract' for output handling, which is not about usage context or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry burden. It focuses on output contract (structuredContent) but omits behavioral traits like read-only nature, authentication needs, or side effects. Does not disclose that this is a computation, not a database lookup.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose. The agent contract adds necessary guidance but is concise. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, description lacks detail on input constraints, method selection criteria, and result interpretation. For a tool with 8 parameters and 30+ siblings, more context is needed for correct tool selection and use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only locale and output_format described). Description mentions method options but does not clarify how adult_dose, child_weight_kg, child_age_years, child_bsa relate to methods. Fails to compensate for low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool calculates pediatric dose from adult dose using weight, age, or BSA method. However, it does not explicitly distinguish from sibling tools like calculate_dose_by_weight or calculate_dose_by_bsa, which may cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., calculate_dose_by_weight, calculate_dose_by_bsa). The agent contract only addresses output handling, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It adds a contract about preserving structuredContent fields and never inferring missing clinical facts, which is useful. However, it lacks details on auth requirements, rate limits, or any side effects. The description provides moderate transparency but is not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, consisting of two sentences. The first sentence delivers the core purpose, and the second adds a key behavioral contract. There is no redundancy or fluff. It is front-loaded with the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters and an output schema, the description lacks important context for proper use. It does not explain parameter effects, output format (though schema exists), or how to handle edge cases like missing max_dose. The agent contract helps but does not fill all gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain any parameters. With schema coverage at only 33% (only locale and output_format have descriptions), the description fails to compensate for the missing parameter meanings, especially for critical ones like dose_per_kg, patient_weight_kg, max_dose, and dose_unit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool calculates weight-based dosage in mg/kg. The purpose is specific and distinguishable from sibling tools like calculate_dose_by_bsa (body surface area) and calculate_pediatric_dose (likely age-based). The addition of 'Agent contract' does not detract from clarity, but the purpose alone is strong.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description does not mention prerequisites, contraindications, or when to prefer other dose calculators. The only usage note is about the response handling contract, which is more about output processing than selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description includes an 'agent contract' about output handling but does not disclose whether the tool is read-only, has side effects, or requires authentication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, no fluff. However, the agent contract sentence is somewhat out of place for a tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters and an output schema, the description fails to explain the formula, output structure, or clinical context, making it insufficient for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, and the tool description does not explain the meaning of parameters like dose_unit, volume_ml, total_dose, or duration_hours, leaving critical gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Calculate IV infusion rate,' which is a specific verb+resource pair. It clearly distinguishes from sibling tools like dose calculations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no references to when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions data sources and a contract for handling results, but does not disclose whether the tool is read-only, requires authentication, or has 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core purpose. The agent contract is specific but concise. However, it could be more structured with separate sections for usage and behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, output schema exists), the description provides key information about data sources and result handling constraints. However, it does not mention the output schema or clarify how this search tool relates to more specific siblings for drug details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 50% schema description coverage, the description adds no meaningful parameter details beyond the overall purpose. It does not explain query format, max_results limits, or output_format values, leaving gaps that the schema partially covers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches for drugs by name and returns results from RxNorm and FDA databases, providing a specific verb and resource. However, it does not differentiate from sibling tools like search_tfda_drug or get_drug_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks guidance on when to use this tool versus alternatives. It only describes the action and result handling, with no mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adds some behavioral context by specifying an 'Agent contract' to preserve structured fields and not infer missing clinical facts. However, it does not disclose error handling, validation rules, or the mathematical formula used (e.g., Mosteller).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at three sentences. The first sentence clearly states the purpose. The latter two sentences about the agent contract are somewhat meta but not overly verbose. It could be slightly more structured, but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, 3 required, and an output schema, the description is quite sparse. It does not explain the output structure (though output schema exists), the BSA formula used, or any constraints on input values. More context would be beneficial for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 29% (2 of 7 parameters have descriptions). The tool description does not explain the meanings of parameters like 'dose_per_m2', 'height_cm', 'weight_kg', 'max_dose', or 'dose_unit'. It only restates the concept of BSA-based dosage. This is insufficient to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates BSA-based dosage in mg/m², commonly used in oncology. This is specific and includes the unit and context. However, it does not explicitly differentiate from sibling tools like 'calculate_dose_by_weight' or 'calculate_pediatric_dose', so it's not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an 'Agent contract' about preserving output fields but gives no guidance on when to use this tool vs alternatives like weight-based dosing or other calculation tools. No explicit 'when to use' or 'when not to use' instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It only states 'Submit' which implies mutation, but lacks details on side effects, required preconditions (e.g., validation), idempotency, or error handling. The agent contract addresses response handling but not the tool's own behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences) and avoids redundancy. However, the 'Agent contract' clause may be better placed elsewhere, as it mixes usage instructions with purpose. Still, it achieves conciseness without extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (12 parameters, 8 required, no annotations, low schema coverage), the description is incomplete. It does not explain prerequisites, required parameter formats, or what happens upon successful submission. The presence of an output schema is mentioned only implicitly via 'structuredContent', but the description does not detail the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 17% (2 of 12 parameters have descriptions). The main tool description adds no parameter-specific information beyond what the schema provides, failing to compensate for the low coverage. Important fields like drug_code, dose, frequency lack any semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Submit a medication order to the HIS service', specifying the verb ('submit'), resource ('medication order'), and target system ('HIS service'). This distinguishes it from sibling tools like validate_order, stop_order, or query tools, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like validate_order or other submission-related tools. There is no explicit when-to-use or when-not-to-use information, and no exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The agent contract discloses key behaviors: using structuredContent as source of truth and preserving certain fields. However, without annotations, it fails to mention whether validation is read-only or if any side effects exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two clear sentences, front-loading the core purpose. The agent contract adds useful behavioral context but could be shortened or separated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the output schema existing, the description omits what validation checks are performed, error handling, prerequisites, or the overall workflow context. For an 8-parameter tool, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, and the description adds no meaning for the 6 undocumented parameters (drug_code, dose, dose_unit, route, frequency, patient_crcl). It relies entirely on parameter names, which is insufficient for a 5-required-param tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Validate a medication order before submission' with a specific verb (validate) and resource (medication order). It distinguishes from siblings like submit_order and check_drug_interaction by focusing on pre-submission validation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as check_drug_interaction or submit_order. The agent contract is about response handling, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully convey behavioral traits. It mentions post-processing (preserve fields, don't infer) but omits details on safety (e.g., read-only nature), authentication needs, or performance implications. The agent contract is helpful but insufficient for complete transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two sentences: one for purpose and one for the agent contract. It is front-loaded with the core function and wastes no words, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward list tool with three optional parameters and an output schema, the description covers the purpose and a key behavioral instruction (preserve fields). However, it lacks context on output format variations or when the tool should be preferred over similar list tools like search_formulary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (2 of 3 parameters have descriptions), but the description adds no parameter-specific information. The undocumented 'status' parameter is not explained, and the description does not clarify the meaning or usage of any parameter beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'List trusted PK/DDI formulas available for simulation', which clearly specifies the action (list) and the resource (trusted PK/DDI formulas). This purpose is distinct from sibling tools like check_drug_interaction or search_formulary, making it easy for an agent to understand when to use this tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an 'Agent contract' for handling the output but does not give any guidance on when to use this tool versus alternatives like get_formula_details or simulate_pk_interaction. It lacks explicit context for selection, leaving the agent 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The 'Agent contract' provides some behavioral context (e.g., preserving fields, not inferring facts) beyond what is in the schema or annotations, but it does not disclose common traits like mutation, side effects, or performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief with two sentences, but the second sentence is lengthy and mixes output-handling instructions with the purpose, slightly reducing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks details on parameter units, acceptable ranges, or differentiation from similar tools. Given the presence of an output schema, return values are partially covered, but overall the description is insufficient for an agent to use the tool reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, and the description adds no information about the required parameters (dose, vd, ke, time). The agent must rely solely on parameter names, which may be ambiguous without units or context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Run a one-compartment concentration-time estimate.' This is a specific verb+resource combination that distinguishes it from siblings like simulate_pk_interaction and other dosing calculation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The 'Agent contract' advises on handling output but does not specify use cases or when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The 'agent contract' part adds behavioral instructions about handling the response (use structuredContent, preserve fields), but no annotations are provided. The description does not disclose side effects, error behavior, or whether it is read-only, which is partially expected for a conversion tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences) and front-loads the purpose. The inclusion of the agent contract adds relevant but non-essential information; however, it is still concise without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description covers the basics. However, it lacks mention of error cases (e.g., incompatible units) and does not elaborate on how the conversion is performed, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 40%, with descriptions only for 'locale' and 'output_format'. The description does not explain the key parameters (value, from_unit, to_unit) beyond their names, leaving ambiguity about accepted values and behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Convert between dose units (g, mg, mcg, ng).' It specifies the exact units and differentiates it from sibling tools like dose calculations by focusing solely on unit conversion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Despite a clear purpose, the description does not specify that it is for simple unit conversion only, nor does it mention when not to use it (e.g., for dose calculations).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only covers result handling (structuredContent as source of truth), without disclosing behavioral traits such as side effects, authentication needs, rate limits, or whether the tool is destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, efficient. The agent contract is valuable but slightly verbose, earning a 4 rather than a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description adequately covers purpose and result handling. However, it lacks parameter guidance and usage context, making it minimally viable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no additional meaning beyond the input schema; the required drug_name parameter lacks a schema description and the description does not explain how to specify it, leaving a gap despite 67% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get warnings, contraindications, and adverse reactions for a drug' with a specific verb and resource, differentiating it from sibling tools like check_drug_interaction or get_drug_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description includes an agent contract about handling structuredContent, but does not explicitly state when to use this tool versus alternatives like check_drug_interaction or get_drug_dosage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It adds some behavioral context about handling results (using structuredContent, preserving fields, not inferring facts), but does not disclose if the operation is read-only, requires authentication, or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences. The second sentence is somewhat long but contains important contract information, and the overall structure is clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, so the description doesn't need to detail return values. The contract provides some completeness, but it could mention the type of data returned (e.g., price as number with currency).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only adds meaning for the 'nhi_code' parameter (by mentioning 'by NHI code'), but does not elaborate on 'locale' or 'output_format'. With 67% schema coverage, the description adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get NHI reimbursement price for a drug by NHI code', which uses a specific verb and resource, and distinguishes it from sibling tools like get_drug_info or search_drug.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an 'Agent contract' that explains how to handle the response, but it does not explicitly state when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds some behavioral context: the agent must treat structuredContent as source of truth and not infer missing facts. However, it does not disclose rate limits, auth needs, or destructive potential, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose. Every sentence adds value—purpose and handling contract. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks usage examples, parameter explanations, and context for when to invoke. Agent has limited guidance beyond the purpose statement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
At 40% schema description coverage, the description fails to explain key parameters like query, limit, and search_type beyond their names. It adds no meaningful guidance over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool searches the Taiwan TFDA drug database for permits and product information. This distinguishes it from siblings like search_drug or get_drug_info by specifying the TFDA Taiwan scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an 'Agent contract' about handling output, but does not specify when to use this tool versus alternatives (e.g., when to prefer search_drug or get_drug_info). No explicit context for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It adds result handling instructions (use structuredContent, preserve fields) but does not disclose if the operation is destructive, requires permissions, or has side effects on other parts of the system.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: a clear purpose statement followed by a focused agent contract. Every sentence adds value without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core action and provides some result handling context, but misses parameter descriptions and usage guidance. Given the existence of an output schema, the return values are likely documented, but the input side remains incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain any parameters. Schema coverage is only 50% with locale and output_format described, but reason and order_id are left without any added meaning. The description fails to compensate for the incomplete schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Discontinue an active medication order', which is a specific verb and resource. This distinguishes it from sibling tools like submit_order or validate_order, and is not a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or related tools, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states 'Get full metadata' and an agent contract, missing explicit statements about safety (e.g., read-only), authorization needs, rate limits, or error conditions. The contract focuses on agent behavior, not tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the purpose. Every sentence adds value: the first explains the action, the second provides critical agent handling instructions. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values are covered. However, the description lacks context on what constitutes a 'trusted' formula and does not explain the formula_id parameter. While the agent contract is useful, the description could better guide parameter usage given only 67% schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (two of three parameters have descriptions). The description adds one useful note about output_format ('structuredContent always follows the versioned outputSchema') but does not clarify formula_id (missing description in schema) or locale beyond the schema's text. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get full metadata for a trusted PK/DDI formula,' specifying a distinct resource type (trusted PK/DDI formula) that differentiates it from sibling tools like get_formulary_item or search_formulary. The verb 'get' is precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an 'Agent contract' with handling instructions but does not explicitly state when to use this tool versus alternatives like search_formulary or get_formulary_item. Usage context is implied but lacks explicit when-to-use/when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description adds behavioral context via the agent contract: using structuredContent as truth, preserving meta fields, and prohibiting inference. However, it does not disclose read-only nature, authentication, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: one for purpose and one for agent contract. It is concise, front-loaded, and every sentence adds value without repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, return values are not needed. However, the description lacks clinical context such as what a renal adjustment recommendation entails, prerequisites, or how results integrate with other tools. The agent contract adds important operational detail but overall completeness is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, missing descriptions for 'drug_code' and 'crcl'. The description mentions CrCl but does not explain units or range. It adds little meaning beyond the schema for 'output_format' and 'locale'. The drug_code parameter is not elaborated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves renal dosing adjustment recommendations based on CrCl. It distinguishes itself from siblings like 'get_drug_dosage' or 'calculate_creatinine_clearance' by focusing on adjustment recommendations. The agent contract further clarifies the tool's specific role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool vs alternatives. The agent contract gives guidance on handling results but no context for selection among siblings. Usage is implied by the tool's name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the tool lists data from the local database, without discussing safety (e.g., read-only), auth requirements, or error scenarios. The agent contract adds some guidance on output handling but is insufficient for a full behavioral picture.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences: the first states the main action, the second provides the agent contract. No unnecessary words; the primary purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity of the tool and the presence of an output schema (so return values are covered), the description is reasonably complete. It includes a key contract for output handling. However, it lacks notes on any response limits or assumptions about database availability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters (locale and output_format) are described with defaults and enums in the schema. The description adds no additional meaning beyond what the schema provides, so it meets the baseline but does not enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all NHI coverage rules from the local database, using a specific verb ('List') and resource ('NHI coverage rules'). This distinguishes it from sibling tools like get_nhi_coverage or get_nhi_drug_price, which are more focused.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an 'Agent contract' that guides how to handle the output, but it does not explicitly state when to use this tool versus alternatives or mention any exclusions. Usage context is implied rather than clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions that the tool returns 'structuredContent' and specifies fields to preserve, hinting at a read-only search operation. However, it does not cover auth requirements, rate limits, or any destructive potential.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for purpose and one sentence for usage guidance. It is front-loaded with the core action and provides essential instructions without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (which documents return values), the description adequately covers the tool's operation, including how to handle results. It misses potential details like pagination or error handling, but overall is sufficient for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (two of four parameters have descriptions in the schema). The tool description adds no additional parameter meaning beyond the schema. It focuses on output handling, not input semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search hospital formulary by drug name or code' uses a specific verb and resource, making the tool's purpose clear. It is distinguishable from siblings like 'search_drug' which likely searches a broader drug database.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an 'agent contract' instructing how to handle the output (preserve fields, not infer facts), but does not explicitly state when to use this tool versus alternatives like 'search_drug' or 'get_drug_info'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description adds significant behavioral context through the 'Agent contract,' requiring use of structuredContent and preservation of specific fields. It clarifies the role of the agent and constraints on data handling, though it does not explicitly state read-only behavior or other operational limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences: one for purpose and one for agent contract. It is front-loaded and avoids redundancy, though the agent contract is somewhat detailed but necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, output schema exists, no annotations), the description is adequate but minimal. It explains the purpose and output handling but does not describe the content of interactions (e.g., severity, mechanisms). The output schema likely covers return structure, so this is acceptable but leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, but the description adds no extra meaning for parameters 'drug1' and 'drug2.' It does not clarify their format or expected values (e.g., drug names or codes). Locale and output_format have schema descriptions, but the tool description fails to compensate for the missing param documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Check for interactions between two drugs,' which is a specific verb and resource. It distinguishes from siblings like 'check_multi_drug_interactions' and 'check_food_drug_interaction' by focusing on exactly two drugs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Agent contract' provides guidance on handling the output but does not explicitly state when to use this tool versus alternatives like 'check_multi_drug_interactions' or 'check_food_drug_interaction.' Usage context is implied, but no explicit when/when-not guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It adds a clear 'Agent contract' specifying that structuredContent is the source of truth and that certain fields must be preserved. This provides crucial behavioral context beyond the basic read operation, though it omits details like authentication requirements 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences. The first sentence states the purpose, and the second provides critical behavioral instructions. Every word adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and many sibling tools are listed, the description provides essential information for a simple lookup tool. It covers the key behavioral contract and clarifies the input parameter. Minor lack of usage guidance and sibling differentiation prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 67% description coverage (locale and output_format have descriptions, drug_code does not). The description clarifies that drug_code is the lookup key, compensating for the missing schema description. It does not add further semantics for the other parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves hospital formulary item details by drug code. However, it does not differentiate from sibling tools like 'search_formulary' or 'get_drug_info', which could cause confusion about when to use this specific tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks any 'when to use' or 'when not to use' hints, relying solely on the tool's name to imply its purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the result handling behavior (preserving structuredContent fields) but does not mention error cases, authentication needs, or rate limits. The mention of versioned outputSchema adds some transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and efficient. The first sentence states purpose, the second provides agent contract. No irrelevant details, but the contract could be integrated more seamlessly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists and no annotations, the description covers main purpose and result handling. However, it omits details on error states or coverage interpretation. For a moderate-complexity tool, it meets basic needs but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, with locale and output_format described but drug_name only titled. The description adds minimal parameter info beyond stating the tool checks a drug's coverage. It does not specify drug_name format or provide usage examples, failing to fully compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks NHI coverage for a drug, using a specific verb (check) and resource (NHI coverage). It distinguishes from sibling tools like get_nhi_drug_price and list_nhi_coverage_rules by focusing on coverage status and details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an agent contract that tells the agent how to handle the result (use structuredContent as source of truth, preserve fields). However, it does not explicitly state when to use this tool versus alternatives like search_drug or get_drug_info, though the context of NHI coverage is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden of behavioral disclosure. It adds a contract about handling structuredContent (using it as source of truth, preserving meta fields, not inferring clinical facts), which is helpful but does not disclose mutability, authorization needs, or other operational traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with one sentence for purpose and a short contract. It is front-loaded with the core function, and the contract is necessary guidance. However, it could be slightly more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (list with two optional parameters, output schema exists), the description adequately covers the purpose and provides a behavioral contract. It does not mention pagination or sample output, but the output schema covers return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any parameter-specific meaning beyond what the schema already provides for 'locale' and 'output_format'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List drugs requiring NHI prior authorization,' specifying a distinct verb ('list') and resource ('drugs requiring NHI prior authorization'). This differentiates it from sibling tools like 'search_drug' or 'get_drug_info' which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or when not to use it. The usage is implied only by the name and brief purpose, leaving the agent to infer context from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It details an agent contract specifying using structuredContent as source of truth, preserving fields, and not inferring facts. However, it does not explicitly state that the tool is read-only or disclose any prerequisites or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no unnecessary words. The first conveys purpose, the second an important behavioral contract. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple and has an output schema, so return values need not be explained. The agent contract covers result handling. However, missing parameter guidance for drug_name and lack of usage context reduce completeness slightly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, with locale and output_format described. The description adds no additional meaning to the parameters; in particular, the required drug_name parameter is left without semantic context beyond its name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks for food-drug interactions for a specific drug. It distinguishes from sibling tools like check_drug_interaction (drug-drug) and check_multi_drug_interactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. Sibling tools exist for similar purposes, but no explicit when-to-use or when-not-to-use information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states an 'Agent contract' with rules like never infer missing facts, but fails to mention read-only nature, authentication needs, rate limits, or side effects, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two succinct sentences with no wasted words: the first states function and scope, the second gives behavioral instructions. Every part adds value, making it highly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 params, output schema exists), the description covers core purpose and result handling via the contract. It lacks detail on output structure beyond 'structuredContent', but the existence of an output schema reduces the need, making it mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (29%), and the description does not individually explain parameters. However, it adds overall context by listing queried sources, partially compensating. The enums in schema provide some semantics, resulting in an adequate but not strong score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states it is a 'single pharmaceutical knowledge entry point' that queries multiple sources concurrently, clearly defining its comprehensive scope. It differentiates from specific sibling tools like get_drug_info or check_drug_interaction by being a unified query interface.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for broad queries across multiple sources with 'single entry point' and 'concurrently', providing context for when to invoke. However, it lacks explicit when-not-to-use or alternative mentions, earning a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although no annotations are provided, the description includes an ‘Agent contract’ that discloses important behavioral traits: using structuredContent as source of truth, preserving schema fields (schema_version, status, sources, warnings, errors, meta), and never inferring missing clinical facts. This adds valuable context about data handling beyond what annotations might provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences: one stating the primary function and formula, and one laying out the agent contract. It is efficient and front-loaded with the key purpose, though the agent contract might be considered slightly verbose for non-agent users.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (mentioned in the description), the tool is fairly complete. It explains the purpose, formula, and data handling rules. One minor gap is not explicitly stating that values should be in specific units (e.g., mg/dL for creatinine), but the clinical context and formula name likely suffice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (33%), with only locale and output_format having descriptions. The tool description does not elaborate on the required parameters (age_years, weight_kg, serum_creatinine, gender) beyond what is implied by the tool's purpose. However, these clinical parameters are self-explanatory given the Cockcroft-Gault formula, so the description adds moderate value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates creatinine clearance using the Cockcroft-Gault formula for renal dosing adjustments. This specific verb-resource combination (‘calculate creatinine clearance’) and the mention of the formula make it distinct from siblings like check_drug_interaction or get_renal_adjustment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for renal dosing adjustments, which is a reasonable usage context. However, it does not explicitly state when to use this tool vs. alternatives like get_renal_adjustment, nor does it provide instructions on when not to use it (e.g., in patients with unstable renal function).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a behavioral contract instructing agents to treat structuredContent as source of truth and preserve metadata fields, which goes beyond basic purpose. However, with no annotations, it omits other traits like idempotency or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the purpose and then add a critical behavioral contract. No redundant words; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema and multiple siblings, the description covers the core purpose and a key behavioral rule. It could mention when drug_name must be exact or error handling, but it is sufficient for an agent to use the tool safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (two of three parameters have descriptions). The tool description does not add meaning to the undocumented drug_name parameter and only indirectly relates to locale/output_format via the contract. No param-specific elaboration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get dosage and administration information for a drug,' which is a specific verb-resource pair. It distinguishes the tool from siblings like get_drug_info or get_drug_warnings by focusing on dosage and administration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Agent contract' provides behavioral instructions but does not explicitly state when to use this tool vs alternatives like get_drug_info. There is no guidance on when not to use it or prerequisites, leaving the agent to infer context from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds behavioral context via the agent contract (use structuredContent as truth, preserve fields). This aids correct usage, though it omits details like auth needs 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences; the first is clear and informative, the second adds behavioral guidance. It is reasonably concise, though the second sentence could be integrated more smoothly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and many sibling tools, the description distinguishes its comprehensive scope well. It mentions preserving fields, but lacks detail on error handling or edge cases. Output schema is referenced, so return values are covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (2 of 3 params described). The description does not elaborate on parameters beyond the schema. Since coverage is high, baseline is 3; no additional value is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get comprehensive information about a drug including indications, dosage, warnings, and pharmacology.' This specific verb+resource+scope differentiates it from sibling tools like `get_drug_dosage` or `get_drug_warnings`, which cover only subsets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an 'Agent contract' but does not explicitly state when to use this tool versus alternatives. It implies comprehensive info, but lacks explicit when-not conditions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses result handling rules: use structuredContent, preserve schema fields, never infer missing facts. Provides clear behavioral contract.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first defines purpose, second provides agent contract. No wasted words, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists so return values are externally documented. Agent contract covers error preservation. Lacks details on edge cases (empty drugs list, unrecognized drugs) but sufficient given the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 67% of parameters with descriptions (locale and output_format). Description does not add meaning for the 'drugs' parameter beyond schema. Baseline 3 for high coverage but no added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Check' and resource 'interactions among multiple drugs' with context 'medication list review'. Distinct from sibling 'check_drug_interaction' which likely handles pairwise checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use compared to alternatives like 'check_drug_interaction' or 'query_pharmacy'. The agent contract provides behavioral instructions but not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It implies list is read-only but doesn't explicitly confirm safety or required permissions. It adds value by detailing output structure (schema_version, status, etc.) but could be more upfront about behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundancy. First sentence defines scope, second provides behavioral contract. Every sentence is essential and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description need not detail return values. It covers purpose, key parameters implicitly, and agent contract. For a listing tool with no required parameters, this is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (locale and output_format have descriptions). The description hints at filtering by 'state' and 'capability' via the list scope, but does not explicitly map these parameters. It adds some meaning but not enough to fully compensate for undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists 'cataloged pharmacy knowledge sources' and specifies the attributes covered (capabilities, readiness, credential requirements, registration state). This distinguishes it from sibling tools which are specific queries or calculations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Agent contract' provides explicit instructions on handling the result (using structuredContent as source of truth, preserving fields). While not explicitly saying when not to use, the context of siblings makes it clear this is for listing sources, not drug-specific queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It adds an 'Agent contract' specifying to use structuredContent as source of truth, preserve schema_version/status/sources/warnings/errors/meta, and never infer missing clinical facts. This instructs the agent on handling results beyond what the schema reveals, adding behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a three-sentence agent contract. It is front-loaded with the purpose and necessary behavioral instructions. While concise, the agent contract could be slightly tighter, but it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mechanistic DDI explanation), no annotations, and an output schema covering return values, the description is fairly complete. It explains the purpose, mentions simulation parameters, and provides data handling rules. It lacks prerequisites or limitations but is sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (drug1 and drug2 lack descriptions). The description mentions 'drug pair' covering those two, but does not further detail locale or output_format meaning beyond the schema defaults. It adds some value but does not fully compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Explain the supported mechanistic DDI pathway for a drug pair, including required simulation parameters.' It uses a specific verb ('explain') and resource ('mechanistic DDI pathway'), distinguishing it from siblings like 'check_drug_interaction' (just checks existence) and 'simulate_pk_interaction' (simulates PK, not mechanism).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (for mechanistic explanation of a drug pair), but does not explicitly state when not to use it or provide alternatives. However, given the self-explanatory name and sibling context, the guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It discloses reliance on local mapping data (implying limited availability) and includes behavioral contract about preserving structuredContent and not inferring clinical facts. This adds useful context for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is two sentences: one clear statement of purpose and one concise agent contract. Front-loaded with key information, no extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, description adequately covers purpose and behavioral rules. Could mention error handling if mapping unavailable, but overall sufficient for a simple translation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% with only locale and output_format having descriptions. The tool description does not add any additional parameter meaning beyond the schema, and the required 'name' parameter lacks any description in both schema and description, leaving ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool translates drug names between English and Traditional Chinese using local mapping data. It specifies verb 'translate', resource 'drug names', and language pair, distinguishing it from sibling tools like search_drug or get_drug_info which do not perform translation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Agent contract provides explicit instructions on handling output (preserve fields, don't infer missing facts), guiding when to use this tool and how to process results. However, no explicit when-not-to-use or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It declares the tool inspects without forcing a download, implying read-only. The contract details how to treat the output. However, it does not mention side effects, auth needs, or caching behavior. Still, it is clear about non-destructive nature and output handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: one for core purpose, one for agent contract. Front-loaded, no wasted words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, description need not explain return values. Covers purpose, parameters, and behavioral contract. For a simple inspection tool, this is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description adds minimal meaning beyond the schema. Parameters locale and output_format are already clear from schema. The description's focus on output handling does not enhance parameter understanding. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Inspect the Taiwan NHI official index freshness, row count, local path, and upstream dataset URL' – a specific verb and resource. It distinguishes from a download action and is distinct from sibling tools like get_nhi_coverage or get_nhi_drug_price.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'without forcing a download,' implying when to use this inspect tool. The 'Agent contract' provides explicit guidance on handling results (use structuredContent, preserve fields, do not infer). Does not explicitly exclude alternatives or state when not to use, but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![pharmacy-mcp MCP server](https://glama.ai/mcp/servers/u9401066/pharmacy-mcp/badges/card.svg)](https://glama.ai/mcp/servers/u9401066/pharmacy-mcp)

Score Badge

Copy to your README.md:

[![pharmacy-mcp MCP server](https://glama.ai/mcp/servers/u9401066/pharmacy-mcp/badges/score.svg)](https://glama.ai/mcp/servers/u9401066/pharmacy-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/u9401066/pharmacy-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server