opdstar-nhi-mcp

Server Quality Checklist

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

Latest release: v0.9.1
Disambiguation5/5
Every tool has a distinct, well-defined purpose. Descriptions explicitly state when to use and when not to use each tool, preventing ambiguity. For instance, `get_indicator` and `lookup_audit_indicator` target different indicator systems, and the guidance clearly delineates their use.
Naming Consistency4/5
Most tools follow a verb_noun pattern (e.g., `lookup_fee_code`, `search_audit_guidelines`). Minor deviations include `recent_nhi_amendments` (no verb) and `check_icd_for_major_illness_eligibility` (long phrase). However, the naming is overall predictable and clear.
Tool Count4/5
With 24 tools, the count is on the higher end but justified by the complexity of the NHI domain, covering drugs, procedures, audits, appeals, and more. Each tool serves a specific, non-redundant purpose, making the set appropriately scoped.
Completeness5/5
The tool set comprehensively covers the NHI domain: ICD-10, procedures, drugs, payment rules, rejection codes, audit clauses, appeal statistics, major illness, preventive services, chronic prescriptions, amendments, and official interpretations. No significant gaps are apparent for the server's stated purpose.
Average 4.6/5 across 24 of 24 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on May 28, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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.
This repository includes a glama.json configuration file.
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context by emphasizing the tool is a 'Reference only' and mentions the need for physician confirmation, which goes beyond annotations. No contradiction.
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 moderately concise (about 100 words) and front-loads the main purpose. It uses formatting (bold) to highlight usage guidance. Every sentence adds value, though some details could be streamlined.
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?
Despite no output schema, the description fully explains what the tool returns: whether the condition qualifies and the specific dispensing limits. It also mentions the data source and official regulation, making it complete for a lookup tool with good annotations.
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 repeats some parameter information (e.g., 'Given an ICD-10 code or a disease name') but does not add significant value beyond what the schema already provides for each parameter.
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 it looks up Taiwan NHI chronic-disease continuous-prescription rules, specifying inputs (ICD-10 code or disease name) and outputs (qualification and dispensing limits). It distinguishes this tool from sibling tools like lookup_major_illness by focusing on chronic prescription specifically.
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 explicit 'Use when' clause indicating the exact scenario for using this tool. It also provides a caution that it is for reference only and requires physician confirmation. However, it does not explicitly mention when not to use or suggest alternatives.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds that the data is curated by OPDSTAR and eligibility must be confirmed by the provider, providing useful context without contradicting annotations.
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 front-loaded with the main purpose and provides detailed examples and usage notes. While concise, it could be slightly shorter, but 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?
Given no output schema, the description explains what is returned (target population, eligibility, frequency, screening tool). It also notes the source and limitations. For a lookup tool with two optional parameters, this is complete and informative.
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% with descriptions for both parameters. The description adds Chinese keyword examples (e.g., '乳房', '塗氟') and clarifies the purpose of each parameter, providing marginal added 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 the tool browses Taiwan NHI preventive-care and screening services, listing specific examples like adult health checks, cancer screenings, and child dental programs. This distinguishes it from sibling tools which focus on drugs, ICD codes, and audit guidelines.
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 explicit 'Use when' guidance for eligibility and subsidy lookups, and states 'Reference only' to indicate it's informational. However, it lacks explicit exclusions or alternatives, though siblings are distinctly different.
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?
Annotations already provide readOnly and idempotent hints. The description adds valuable context about auto-detection of four input shapes, dynamic behavior, and return fields, enhancing transparency beyond annotations.
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?
Description is moderately long but well-structured with clear sections and bullet points. Every sentence adds value, though could be slightly more concise.
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?
Given no output schema, the description thoroughly explains return fields, input shapes, usage context, typical follow-ups, and out-of-scope items, making it highly complete for a complex 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 coverage is 100% with descriptions for each parameter. The description reinforces parameter usage but adds no new semantic details beyond what is in the schema.
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 Taiwan drugs across NHI and TFDA registries and lists return fields. It distinguishes from many siblings but does not explicitly differentiate from the similarly named 'lookup_drug' sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: when an agent has any drug identifier for billing/SOAP/appeal. Lists typical follow-ups and out-of-scope items, providing clear guidance on alternatives.
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?
Annotations already declare read-only, non-destructive, idempotent behavior. The description adds context about return fields and emphasizes that final eligibility requires formal application, which is important beyond the annotations.
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, front-loads the purpose, and uses clear structure. It could be slightly trimmed but is well-organized for an agent to parse.
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 output schema, the description explains return fields and references a sibling tool for alternative use. It also notes reference nature and source. For a lookup 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 100% with descriptions for both parameters. The description mentions `category_code` and `keyword` but does not add significant new meaning beyond what the schema provides, so 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 clearly states the tool browses Taiwan NHI major illness categories and lists the return fields, distinguishing it from the sibling tool `check_icd_for_major_illness_eligibility` which handles a different use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('enumerate or filter major-illness categories') and when not to use ('if you already have an ICD-10 code... call check_icd... instead'), providing clear decision criteria.
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?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds value by stating 'Reference only — official 健保署審查注意事項 (current edition) is authoritative; clause summaries are previews.' This informs the agent about the limitations of the data. No contradiction with annotations.
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 concise (5 sentences) with clear structure: purpose, use case, alternative, and reference note. Bolded key phrases aid readability. No unnecessary information.
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 output schema, description adequately explains what is returned (clause headlines, risk flags, preview). It covers usage context and limitations. Could mention result format or pagination, but still strong overall.
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% with detailed parameter descriptions. The description does not add significant new semantics beyond what the schema already provides. It lists example specialties and risk flags, but these are already covered in the schema. 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?
Description clearly states 'Browse Taiwan NHI 審查注意事項 clauses for a specific medical specialty' with specific verb and resource. It distinguishes from sibling tool `lookup_audit_clauses_for_procedure` by explicitly stating when not to use this tool and naming the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance: 'Use when an agent needs section-wide audit context before assisting with claim coding for a specialty.' It also clearly says 'Don't use for clauses tied to a known specific procedure code' and provides the exact alternative 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?
Annotations already declare this as a safe, read-only, idempotent operation. The description adds important behavioral context: the tool is 'Reference only' and confirmed eligibility requires a formal application with supporting documentation. No contradictions with annotations.
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?
Three sentences, each with clear purpose: first states what it does, second gives usage guidelines with bold cues, third adds a reference caveat and attribution. Front-loaded, no filler, well-structured for agent scanning.
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?
For a simple tool with one parameter and no output schema, the description fully covers purpose, return content, usage boundaries, and important disclaimers. Sibling differentiations are clear, and the note about formal application adds necessary context for proper use.
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?
The input schema already provides a thorough description for `icd_code` (required, case-insensitive, prefix-matching, examples). Schema coverage is 100%, so baseline is 3. The description adds minimal new detail beyond the schema, only restating 'single ICD-10 code'.
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 as a reverse-lookup from ICD-10 code to Taiwan NHI major illness categories, listing specific return fields. It explicitly distinguishes from the sibling tool `lookup_major_illness` which performs the opposite direction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases ('when an agent has a diagnosis... before claim submission'), explicit non-use cases ('Don't use to browse all categories'), and a direct alternative (`lookup_major_illness` instead). It also specifies the opposite direction usage.
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?
Annotations already declare safe read-only, idempotent behavior. Description adds useful context: returns up to 50 results, categories listed, reference to authoritative source, and curation by OPDSTAR. No contradiction with annotations.
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?
Every sentence serves a purpose. Usage guidelines are front-loaded with bold markers. Categories listed compactly. No redundancy or filler. Excellent structure.
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?
Despite no output schema, description specifies return fields (code, severity, short description) and limit (50 per call). Covers categories, usage context, and authority. Complete for a browsing 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 covers both parameters fully (100% coverage). Description lists category codes inline, which duplicates enum but adds no new semantic value beyond what schema provides. 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?
Clear verb 'browse' with specific resource 'Taiwan NHI rejection codes' and scope 'by category (00-09)'. Distinguishes from sibling 'lookup_rejection_code' by explicitly contrasting discovery vs. known code lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (enumerate within workflow domain) and when not to (look up known code), with named alternative 'lookup_rejection_code'. Bold markers clearly demarcate guidance.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds a 'Reference only' caveat clarifying that summaries are first-sentence previews and the official source is authoritative, which provides useful context beyond the annotations.
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 only four sentences, each earning its place: purpose, usage, exclusions, and reference caveat. Highly efficient and well-structured.
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?
Given no output schema, the description explains return values (clause summary, specialty, risk flags) and the meaning of risk flags. It also credits the source and warns about data freshness, making it self-contained.
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% with detailed parameter descriptions. The description reinforces with code format hints and example values but does not add significant new meaning 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 has a specific verb+resource 'Find Taiwan NHI 審查注意事項 clauses' and clearly distinguishes from siblings by naming alternatives like lookup_fee_code and lookup_audit_clauses_for_specialty.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'Use when' and 'Don't use' sections with alternative tool names (lookup_fee_code, lookup_audit_clauses_for_specialty) provide clear guidance on when to invoke this tool versus others.
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?
Annotations already declare readOnlyHint true and idempotentHint true. Description adds that results are limited to 10 matches and that the catalog is a working snapshot, noting the official source is authoritative. No contradiction.
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?
Very concise, front-loaded with purpose, uses bold markers for use/don't use. 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?
Despite no output schema, the description enumerates return fields and states limitations (10 matches, working snapshot, authoritative source). Comprehensive 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 coverage is 100% with detailed descriptions including examples and constraints. Tool description does not add meaningfully beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool looks up the Taiwan NHI drug catalog by multiple identifiers, returns up to 10 matches with specific fields. It distinguishes itself from siblings like search_taiwan_drug and get_drug_rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use (identify/disambiguate drug for SOAP draft) and when not to use (payment rules, audit clauses), with direct sibling tool names (get_drug_rules, search_audit_guidelines).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the annotations: it explains the behavior with no year (returns latest settled value per region × sector) and with year/quarter (returns quarterly time series). It also clarifies that values are typically less than NT$1. No contradiction with annotations, which already mark it as readOnly and idempotent.
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 well-structured: starts with the core function, explains the context, then parameter behavior, and ends with usage guidance and attribution. It is slightly verbose but each sentence serves a purpose. Could be trimmed slightly without losing meaning.
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 complexity of the NHI point value system, the description provides enough context for an agent to understand what the tool does and when to use it. It mentions the output (settled rates, quarterly time series) but not the exact format. Since there's no output schema, a bit more detail on the return structure would improve completeness, but it is adequate.
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?
All parameters have descriptions in the schema (100% coverage), so the description doesn't need to repeat them. However, it adds domain-specific context (e.g., 'floating' vs 'average' metric) and explains the interaction between year and quarter. This adds 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 the tool's purpose: looking up Taiwan NHI floating point values, the settled per-point payment amount by region and sector. It explains the context of the global budget system and distinguishes the tool from sibling tools by focusing on a specific domain (point values) rather than other NHI lookups.
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 explicitly tells when to use the tool: 'Use when an agent needs to estimate actual reimbursement.' It also notes the official source for reference. While it doesn't explicitly state when not to use it or compare with alternatives, the use case is clear and actionable.
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 discloses that it returns a not-found message (not an error), that thresholds may change per NHI release, and that agents should re-read each session rather than cache. Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, which this description complements with behavioral nuance.
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 thorough but slightly long; however, it is well-structured with clear sections (code format, usage, follow-up, caveat) and front-loaded with the core purpose. Every sentence adds value, and the length is justified by the complexity of the domain.
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?
Given the simple input schema (one parameter) and no output schema, the description fully covers expected behavior: return value (indicator name, threshold, drugs/diagnoses, compliance meaning), not-found handling, typical follow-ups, and versioning caveat. It leaves no ambiguity for the agent.
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 single parameter `code` is fully described in the schema (100% coverage). The description adds value by specifying exact format (e.g., '008' not '8'), whitespace trimming, and case normalization, providing practical usage details 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 'Look up a single Taiwan NHI prescribing-pattern indicator,' specifies the code format (1-4 characters, numeric or P-prefixed), and distinguishes itself from the sibling tool `lookup_audit_indicator` by explicitly noting it is for a different system.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Use when' an agent needs human-readable explanation for a specific indicator code, and 'Don't use' for the percentage-cap audit list (calling `lookup_audit_indicator` instead). It also lists typical follow-ups like `get_drug_rules` and `search_audit_guidelines`.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds key behavioral details: never returns individual case details or arguments, and that it is reference only (historical signal does not predict future outcomes). No contradiction with annotations.
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 a single paragraph but efficiently conveys purpose, constraints, use cases, and limitations. It is front-loaded with key information and is not overly verbose. Could be structured with bullet points but remains concise.
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?
Given the simple parameter set (2 enums, 1 required), rich annotations, and no output schema, the description covers all necessary context: what the tool does, when to use it, limitations, and source curation. An agent can fully understand its role and constraints.
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 baseline is 3. The schema already provides detailed descriptions for both parameters, including enum meanings. The description adds minimal additional parameter-specific semantics beyond what is in 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 it aggregates dispute-resolution statistics for Taiwan NHI claim disputes by category and optionally review stage. It specifies what it returns (category counts, rough win-rate signals) and what it does not (individual case details). It also distinguishes from the sibling tool 'count_appeal_precedents_for_rejection_code' by stating it is not for code-specific signals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides use cases ('Use when an agent is helping a clinician understand the general dispute landscape') and counter-indications ('Don't use for code-specific signals'), naming the alternative tool. It also includes a caution about reference only and not predicting future outcomes.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true. Description adds that a not-found message (not an error) is returned for non-existent codes, and mentions the data source. No contradictions. Adds useful behavioral context beyond annotations.
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?
Description is fairly long but every sentence adds value. Front-loaded with purpose and format, then use guidelines. Could be slightly more concise but well-organized and efficient.
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?
No output schema, but description explicitly explains return values (severity, category, Chinese description) and error handling (not-found message). Also mentions follow-up tools. Complete for a single-param lookup tool.
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 single parameter 'code' has full schema coverage with pattern and description. Description adds auto-uppercasing and whitespace trimming details not in schema, providing extra guidance for agents.
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 looks up a single Taiwan NHI rejection code, specifies the 5-character format, and describes returned fields (severity, category, Chinese description). Distinguishes itself from siblings like get_rejection_code_category and count_appeal_precedents_for_rejection_code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (encountering a known rejection code) and when not to use (enumeration by category) with a sibling alternative. Also suggests typical follow-up calls for different categories, providing clear action paths.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds valuable context: it is a 'signal-only' summary, 'reference only', and historical signal does not predict future outcomes. No contradiction with annotations.
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 well-structured: main functionality first, then usage guidance, then caveats and attribution. While slightly long, every sentence serves a purpose and the core message is front-loaded. Could be marginally more concise but remains effective.
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 output schema, the description adequately explains the output components (volume bucket, win-rate, review stages) and the reference nature. It also covers the tool's purpose and limitations. Missing exact output keys or types, but sufficient for an agent to understand what to expect.
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?
Schema coverage is 100% with descriptions for both parameters. The description reinforces the requirement that at least one must be provided, gives character length examples (e.g., '0312A', '86008C'), and clarifies the optional nature. This adds moderate 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 the tool aggregates a summary of dispute resolutions for a given NHI rejection code or procedure code, specifying the output (volume bucket, win-rate signal, review stages). It also distinguishes from the sibling tool lookup_appeal_statistics_by_category, which provides broader landscape data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides 'Use when' (triaging contesting a specific code) and 'Don't use' (fetching individual case details) guidance, and directs to an alternative (lookup_appeal_statistics_by_category) for broader analysis. This leaves no ambiguity about when to invoke this tool.
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?
Annotations declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and the description adds that the tool is a curated subset, not exhaustive, and the official source is authoritative. This provides useful context beyond annotations, though no additional detail on rate limits or pagination is given.
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 four sentences, front-loaded with the core purpose, then listing filters, usage guidance, and a disclaimer. Every sentence adds value, and there is no redundancy or wasted words.
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?
For a read-only listing tool with three parameters and no output schema, the description covers the purpose, required filters, use cases, alternatives, and the curated nature of the data. An agent has sufficient information to decide when and how to invoke the tool.
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?
Schema description coverage is 100%, so baseline is 3. The description adds the important constraint that at least one of the three filters must be provided, which is not captured in the schema's required list. This adds value, though it mildly contradicts the schema indicating no required 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 starts with 'Look up Taiwan NHI drug payment rules' providing a specific verb and resource. It further clarifies the tool returns reimbursement status with severity and citation, and explicitly distinguishes from sibling tools like lookup_drug for identifying specific drugs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when to use: 'when an agent is checking whether a drug choice will trigger a rejection before submission, or wants to read the rule behind a known rejection code.' It also explicitly says when not to use and names alternative tools (lookup_drug, lookup_audit_clauses_for_procedure, lookup_audit_clauses_for_specialty).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint annotation, the description adds significant behavioral context: results ordered by curated relevance, capped at limit, returns empty list for missing mappings (intentionally conservative), and clarifies it is not a billing source of truth. No contradiction with annotations.
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 concise (7 sentences) and well-structured: what it does, ordering/limits, empty edge case, use case, follow-up, don't use, curational source. Every sentence adds value; no redundancy.
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?
Despite no output schema, the description fully covers return structure (procedure code, names, points, audit_notes), ordering, limits, and empty-list behavior. It also explains input format and specialty matching, making the tool's behavior predictable.
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 baseline is 3. The main description provides functional context (e.g., curational nature) but does not add meaning beyond what the input schema already describes for each parameter (format, examples, defaults, enum).
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 verb 'return' and specific resource 'NHI procedure codes' for a given ICD-10 code and specialty. It distinguishes from sibling tools like lookup_fee_code and lookup_audit_clauses_for_procedure by noting typical follow-ups and cautioning against using it as a billing source of truth.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (drafting SOAP, starting set of procedure codes) with an example (dermatologist with L30.9). Provides when-not-to-use (as billing source of truth) and directly names alternatives (lookup_fee_code for canonical entry). Also outlines typical follow-up steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as readOnly, non-destructive, and idempotent. The description adds key behavioral context: it is 'Reference only', requires physician judgment for clinical coding, and discloses data limitations (currently a ~3,000 code subset from OPDSTAR, with full set planned). This fully informs the agent of constraints and reliability.
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 moderately long but well-structured with bold headers, bullet points, and clear sections. Every sentence adds value, covering purpose, usage, scope, limitations, and follow-ups. Minor redundancy could be trimmed, but overall efficient for the information conveyed.
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 and rich annotations/schema, the description is complete: it covers purpose, usage, behavioral constraints, parameter behavior, and scope. No output schema exists, but the description implies return of code, descriptions, category, and specialties. A brief note on result format would improve completeness slightly.
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?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining auto-normalization for the code parameter (uppercased, dotted/undotted forms), and clarifies that keyword searches across English, Chinese, and code prefix. This enhances understanding 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 identifies the tool as a lookup for ICD-10-CM diagnosis codes with English/Chinese descriptions, category, and OPDSTAR specialties. It distinguishes itself from sibling tools by explicitly stating typical follow-up chains (get_procedures_for_icd, check_icd_for_major_illness_eligibility) and scope limitations (subset vs full set).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use ('when the agent encounters an ICD-10 code...needs canonical name, or wants to free-text search') and provides specific scenarios (note, claim, rejection notice). It also lists out-of-scope items (SNOMED CT, ICD-10-PCS) and directs to alternative tools for follow-ups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, description discloses result limitations (first sentence only, up to 10 results), preview nature, and authoritative source, adding significant context.
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 concise with front-loaded main action, followed by usage and disclaimers, no unnecessary text.
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?
Given no output schema, description effectively explains return value structure (reason+suggestion, first sentence, max 10) and provides context about tool purpose and limitations.
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 baseline is 3. Description provides examples matching schema but does not add new semantic details about 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?
Description clearly states the tool performs free-text search over Taiwan NHI audit rules and returns summaries, differentiating from siblings like lookup_audit_clauses_for_procedure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides 'Use when' and 'Don't use' guidance with examples, and names the alternative tool for specific procedure codes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds context that the tool is a 'Reference only — phrasing patterns reflect curated review experience, not formal NHI directives' and that it returns up to 5 scenarios per call. No contradictions with annotations.
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 well-structured with a clear first sentence summarizing purpose, followed by use/don't use guidelines and additional context. It is slightly long but every sentence adds value, making it efficient overall.
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?
Given no output schema, the description adequately explains what the tool returns (scenario name, high-risk wording, key difference, first sentence) and its limitations (up to 5 scenarios, preview only, not official directives). It also directs to the full product and alternative tool, providing complete context for the agent.
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?
Schema description coverage is 100%, so baseline is 3. Description adds value by giving concrete examples (e.g., 'dermatology + 抗生素') and stating that scenario_query is an ILIKE match, which helps the agent understand usage 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 that the tool previews OPDSTAR-curated NHI-safe phrasing patterns for a given specialty, returning scenario name, high-risk wording, key difference, and first safe-phrasing example. It distinguishes itself from sibling tool 'search_audit_guidelines' by explicitly stating the different use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use ('helping draft SOAP wording and needs to flag risky phrasing before submission'), when not to use ('Don't use to retrieve full ready-to-copy templates'), and directs to an alternative tool ('call search_audit_guidelines'). This provides clear guidance for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds nuance: 'Reference only — thresholds change with each official release,' and describes what the tool returns, which is consistent with a safe, read-only operation. No contradictions.
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 concise (under 150 words) and well-structured: first sentence defines the resource, then usage guidance, then parameter omission behavior, then exclusions, then limitations and credit. Bolded cues enhance readability.
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?
Given the tool's moderate complexity (4 optional params, no output schema), the description covers purpose, parameter behavior, usage boundaries, return fields, and update frequency. It is sufficient for an agent to correctly select and invoke the tool, even in a rich sibling context.
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?
Schema coverage is 100%, with each parameter described. The description adds value by explaining how to browse by omitting indicator_code ('Omit indicator_code to browse by category / specialty / procedure') and provides an example that ties parameters together. However, since the schema already covers parameter definitions well, the added semantics are modest but meaningful.
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 specifies the resource (Taiwan NHI threshold-based audit rules) and the verb (look up). It also distinguishes from the sibling tool 'get_indicator' by explicitly noting that prescribing-pattern indicators are handled elsewhere.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use ('Use when an agent needs to know whether a procedure code is under a percentage-cap audit') and when not to use ('Don't use for prescribing-pattern indicators... those live in get_indicator'), with a concrete example. This provides clear decision guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, non-destructive, idempotent. Description adds that audit notes are truncated to 600 chars, icd filter is sparse, and tool is reference only. No contradictions.
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?
Description is a single paragraph but well-organized, each sentence adds value. Could be slightly more structured but remains clear and efficient.
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?
Covers purpose, parameters, return fields (code, points, dates, audit notes truncated), caveats (sparse icd, reference only), and examples. Adequate given 3 params and no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. Description adds context: how q matches (exact vs ILIKE), examples, category prefix meanings, and icd sparsity. This meaningfully extends 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?
Description specifies verb 'Look up' and resource 'Taiwan NHI fee schedule', details search by code or name, and explicitly distinguishes from siblings by stating not to use for drugs or ICD-10 procedure suggestions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear 'Use when' and 'Don't use' guidance, explains category prefix usage, mentions sparse icd filter, and references alternative tools (lookup_drug, get_procedures_for_icd).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds that the tool is for 'Reference only' and that official 健保署 announcements are authoritative, disclosing behavioral boundaries beyond annotations.
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 roughly 5 sentences, front-loaded with purpose and return details, followed by usage guidance, then a note on authority. Every sentence serves a distinct purpose without redundancy.
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?
No output schema exists, but the description fully enumerates return fields (dates, title, type, links). Combined with clear parameter semantics and annotations, it provides complete context for agent decision-making.
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?
Schema has 100% coverage with parameter descriptions. The description adds value by clarifying the type enum values with parenthetical explanations (e.g., 'primary = main regulation update') and explicitly stating defaults in Chinese, but the schema already handles the basics well.
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 explicitly states the tool lists recent amendments to Taiwan NHI rules and audit guidelines, specifying return fields (dates, title, type, links). It distinguishes from siblings by suggesting typical follow-ups like search_audit_guidelines and lookup_rejection_code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit 'Use when' scenarios (e.g., 'what NHI rule changes are coming?') and advises on alternatives via 'Typical follow-up' calls to sibling tools, providing clear contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds that it is a reference only, the official publication is authoritative, excerpts may lag, and to open the source URL for binding text. No contradiction.
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?
Well-structured with purpose first, then output details, usage guidance, and caveats. Every sentence adds value but could be slightly more concise (e.g., 'excerpt may lag the latest revision and is not the full document' could be shortened).
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?
For a search tool, description covers ranking (top 10), error behavior (empty list not error), return format, and important caveats (reference only, authoritative source, open URL for binding text). No output schema needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. Description adds practical guidance: query can be natural language or document number, multi-word phrases best, single characters unlikely to work; limit usage advice (increase for survey, keep low for targeted lookup).
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 it searches Taiwan's NHI administrative interpretations, specifies the returned fields (document number, issue date, subject, excerpt, URL), and distinguishes from sibling tools by listing when not to use it (rejection code, fee code, drug name).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use when' and 'Don't use' with concrete examples (e.g., '函釋怎麼說人工水晶體的給付規定', '健保審字第1090017813號'), and names alternative sibling tools like lookup_rejection_code.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnly, non-destructive, idempotent. Description adds that results are up to 10 ranked excerpts, returns empty list for no matches, may lag latest revision, and snippet is not full document. No contradictions with annotations.
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?
Well-structured with a clear one-liner, category list, return format, and usage guidance. Slightly lengthy but every sentence adds value. Could be tightened slightly.
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?
No output schema but description explains return structure (excerpts with fields). Annotations provide safety context. Sibling tools differentiation is thorough. Complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. Description adds usage examples for 'query', explains enum values for 'category', and provides default and range advice for 'limit'. Adds meaning beyond the raw 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 it searches Taiwan's NHI knowledge base for natural-language background questions, lists 9 categories, and specifies it returns ranked excerpts. It distinguishes from siblings by stating not to use when a specific code/tool is known.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (broad NHI policy background) and when not to use (when a specific code/tool applies). Provides typical follow-up actions and references dedicated tools. Offers clear exclusion criteria and alternative tool names.
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:

[![opdstar-nhi-mcp MCP server](https://glama.ai/mcp/servers/tatsuju/opdstar-nhi-mcp/badges/card.svg)](https://glama.ai/mcp/servers/tatsuju/opdstar-nhi-mcp)

Score Badge

Copy to your README.md:

[![opdstar-nhi-mcp MCP server](https://glama.ai/mcp/servers/tatsuju/opdstar-nhi-mcp/badges/score.svg)](https://glama.ai/mcp/servers/tatsuju/opdstar-nhi-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/tatsuju/opdstar-nhi-mcp'

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