vghsdk-mcp
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation4/5
Most tools have clear list/detail pairings (e.g., patient_drug_list vs patient_drug_content), but there is potential confusion between consent_list and consent_search, and between patient_op_schedule and consent_opschedule. patient_opd_list_search also overlaps with patient_opd_list.
Naming Consistency4/5Tool names mostly follow a snake_case pattern with domain prefixes (e.g., patient_*, surgery_*, doc_*). Minor deviations like consent_opschedule and ivi_fetch_schedule break the noun_verb pattern, but overall the convention is consistent.
Tool Count3/527 tools is heavy, but the server covers multiple hospital subsystems (patient records, surgery, OPD, drugs, consents, schedules). The count feels justified for the broad scope, though some consolidation could reduce redundancy.
Completeness4/5The surface covers most hospital workflows: patient demographics, OPD/admission notes, surgery records and schedules, drug lists, consult notes, and consent management. Minor gaps exist (e.g., no lab results or allergy data), but the core needs are well covered.
Average 3.6/5 across 27 of 27 tools scored. Lowest: 2.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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.jsonto 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?
The verb '取得' and the noun '清單' minimally indicate a read-only list operation. However, with no annotations, the description fails to disclose authentication expectations, pagination, return structure, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no fluff, but it is excessively terse and reads more like a label than a functional description. It omits essential context that should accompany the purpose statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema or annotations, and the description does not explain return values, authentication flow, or error cases. For a tool requiring credentials, this is incomplete, though the basic purpose statement provides a minimal baseline.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only hints that '科別' may map to the tdept parameter (department). The required eip_id and eip_password parameters are completely unexplained, leaving credential semantics ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb '取得' (get) and the resource '科別掃描病歷清單' (department scanned medical record list), clearly stating a list-retrieval purpose. It does not explicitly differentiate from sibling tools like patient_opd_note or patient_op_list, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, nor are prerequisites or exclusions mentioned. The department scope ('科別') is implied but not framed as a selection criterion.
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 provided, the description carries the behavioral disclosure burden. It does add value by stating the return format (HTML) and the automatic conversion to ROC-era 8-digit format (01141104), which are useful operational details. However, it doesn't disclose authentication needs (though eip_id/eip_password are params), potential errors, or side effects, so transparency is only partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and structured with an Args section, Returns line, and internal conversion note. It is front-loaded with the primary purpose and avoids fluff. The Args section does partially duplicate schema info, but the included example adds value, making it efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 required parameters, no annotations, and no output schema, the description needs to provide more context. It conveys the core function and return format but omits the meaning of three parameters, any usage scenarios, and error/edge-case behavior. For a moderately complex tool, this is insufficient for an agent to confidently select and invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage, so the description must explain all parameters. It thoroughly explains 'dt' with a format example (YYYY-MM-DD and auto-conversion), but the other three required parameters (eip_id, eip_password, hisno) are not mentioned at all. This leaves 75% of parameters semantically opaque, which is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a surgical record (手術病歷) as HTML, using a specific verb ('取得') and resource. While it doesn't explicitly differentiate from sibling tools like patient_op_list or patient_op_schedule, the term '手術病歷' is specific enough to distinguish it from outpatient or admission notes, so it nearly meets the bar for explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, nor does it mention any exclusions or prerequisites. The only operational note is about automatic date format conversion, which is a detail of invocation, not usage context. This leaves the agent without clear direction among many patient/surgery-related siblings.
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 transparency burden. It does disclose the default date range and the return structure (jobs array with JOB_DOC_ID, TEMP_NAME, JOB_STATUS), but it does not explicitly state that the operation is read-only, nor does it mention authentication requirements or potential 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loads the purpose, and uses a clear Args/Returns structure. Every sentence provides useful information without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should compensate, but it only covers optional date parameters and return field names. It does not explain required parameter semantics, authentication, or relationship to sibling consent tools, making it incomplete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for start_date and end_date (format and defaults) but completely omits the three required parameters (hisno, eip_id, eip_password), which are essential for invoking the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '取得病人同意書清單' (get patient consent form list), providing a specific verb and resource. However, it does not differentiate itself from sibling tools like consent_search or consent_opschedule, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as consent_search. The date range defaults imply a typical use case, but there are 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It does disclose the return fields (排程日期, 手術名稱, 主刀醫師, 預定時間), which is useful, but provides no information about authentication requirements, potential errors, or side effects. This is adequate but with clear 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, front-loading the purpose and then listing return fields. Every sentence earns its place with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the many sibling schedule tools, this description is too sparse. It does not explain how this tool relates to the consent system, what the parameters mean, or how it differs from similar tools like patient_op_schedule or surgery_schedule_detail. The low parameter documentation and lack of usage guidance make it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the three parameters (eip_id, eip_password, hisno). The schema only provides bare titles, not semantic meaning. The description fails to compensate for this lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '查詢病人手術排程' (query patient surgery schedule) with a specific verb and resource, and adds '(同意書系統)' (consent system) to distinguish from generic schedule tools like patient_op_schedule. This differentiates it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 parenthetical '同意書系統' implies a specific context, but it does not state exclusions or alternatives, leaving the agent without adequate decision support.
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 provided, the description partially discloses behavior: it mentions default scope (ophthalmology + completed) and explains the return_id flag. However, it does not state whether the operation is read-only, what credentials are required beyond the schema, or what the default return format is, leaving significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with the main purpose stated first and parameter details listed separately. It avoids unnecessary words, but the structure is slightly fragmented due to mixing Chinese and English and the lack of a cohesive explanatory paragraph.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, no output schema, and no annotations, the description covers only a fraction of the needed context. Missing details include date range semantics, credential usage, default return behavior, and differentiation from sibling tools, making it incomplete for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains only two of seven parameters (target_keyword and return_id), while the required parameters (eip_id, eip_password, hisno) and date fields (start_date, end_date) remain undocumented. This is insufficient for effective usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for consent forms ('搜尋同意書') and specifies default filters (ophthalmology + completed), giving a specific verb and resource. However, it does not distinguish this from sibling tools like consent_list or consent_opschedule, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for searching consent forms with default filters, but provides no explicit guidance on when to use this tool versus alternatives such as consent_list or consent_opschedule. There are no exclusions or alternative tool references, so it only offers implied 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 of disclosure. It lists return fields and mentions the linkage to patient_consult_note, which provides useful behavioral context. However, it does not discuss authentication, result scope, ordering, or side effects, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the purpose, and logically structured with Returns and Note sections. Every sentence adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 required parameters, no output schema, and no annotations. The description provides return fields and a linkage hint but omits parameter meaning, authentication context, and list behavior (e.g., ordering, pagination). This is insufficient for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain eip_id, eip_password, or hisno at all. The description completely fails to compensate for the lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '取得病人會診清單' clearly states a specific verb (get) and resource (patient consultation list). It distinguishes itself from the sibling patient_consult_note by implicitly focusing on the list, but it does not explicitly contrast with other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The note that caseno and oseq can be used in patient_consult_note implies a workflow for fetching details, but it does not explicitly state when to use this tool versus alternatives or when not to use it. Usage context is only 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, the description provides some behavioral context by listing the exact returned fields, implying a read operation. However, it does not disclose authentication requirements, behavior for missing patient IDs, or any potential side effects or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and clear, with a single introductory line and a list of returned fields. No unnecessary redundancy exists, and the structure is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple info retrieval, the description is reasonably complete in that it lists the output fields. However, given no annotations and no usage guidance, and the need for credentials, it falls short of fully preparing an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides parameter names only (eip_id, eip_password, hisno) with no descriptions, and the tool description does not explain their meanings or relationships. The names hint at credentials and a patient number, but this is insufficient to fully understand the expected values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves complete patient basic information using the verb '取得' (retrieve) and specifies the resource (patient info). It enumerates the returned fields, which distinguishes it from list/note tools, but it does not explicitly compare to siblings such as patient_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives; it does not mention that this is for retrieving data for a specific patient (by hisno) rather than searching, nor any preconditions such as authentication using eip_id/password.
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 description adds some behavioral detail by revealing the return fields and explaining the `old_than_four_years` flag (include records older than 4 years). However, with no annotations, it does not explicitly state that this is a read-only operation, does not explain the required credentials (`eip_id` and `eip_password`), and omits any mention of pagination, sorting, or error behaviors. Thus it only partially carries the transparency burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured with distinct Args and Returns sections. Each line serves a purpose, with no filler or redundant content. It is front-loaded with a clear summary statement and remains easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description provides the essential return fields and one option, which is adequate for basic usage. However, it leaves out authentication parameters, ordering details, and differentiation from the search-based sibling. Given that there is no output schema and no annotations, a bit more context (e.g., the meaning of `eip_id`/`eip_password`, or an explicit 'use this when you have a hisno') would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description covers two of the four parameters: `hisno` and `old_than_four_years`. The required parameters `eip_id` and `eip_password` are completely omitted, and schema coverage is 0%. Since the description is the only source of parameter meaning, the lack of documentation for these credentials is a significant gap. The explanation of `old_than_four_years` is also minimal ('包含 4 年前紀錄') without clarifying default behavior or impact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: '取得病人門診清單' (retrieve patient outpatient list), enumerates the expected return fields (date, time, physician, department, diagnosis code), and identifies the key parameter `hisno`. However, it does not distinguish itself from the sibling tool `patient_opd_list_search`, creating ambiguity about the difference between a direct list fetch versus a search operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 simply states what it does without mentioning any prerequisites, exclusions, or the presence of sibling tools such as `patient_opd_list_search` or `patient_info`. This leaves the agent to infer usage context on its own.
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 only mentions two filter parameters and does not state whether the operation is read-only, what authentication is required, what the return shape is, or any side effects. For a search tool, read-only behavior is implied but not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the purpose, followed by the args. It is concise and wastes no words, though the brevity contributes to missing critical information. Structurally effective for what it covers.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With six parameters, three required, no annotations, and no output schema, the description covers only a fraction of the tool's interface. It omits credentials, the hisno context, and the boolean flag, and does not describe return values or behavior. The tool is complex enough to require a fuller description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds useful examples and format hints for doc_regex and dept_regex, which helps beyond the schema titles. However, it ignores required parameters (eip_id, eip_password, hisno) and the old_than_four_years flag, leaving those without semantic guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states '搜尋門診清單' (search outpatient list), a clear verb+resource pairing. The regex filtering qualifier adds specificity, but it does not explicitly differentiate from the sibling tool patient_opd_list, which likely also deals with outpatient lists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for searching with regex filters on doctors and departments, but it does not explicitly state when to use this over alternatives like patient_opd_list. No exclusions or alternative recommendations are 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 carries the full burden of behavioral disclosure. It only lists return fields and gives a workflow note, but does not explicitly state authentication needs (though params imply credentials), side effects, rate limits, or error behavior. The read-only nature is implied by '取得' but not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a concise main sentence, a Returns block, and a Note. It is front-loaded with the purpose and every line earns its place. The field list is necessary given the absence of an output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the explicit Returns list partially compensates. The workflow note adds useful integration context. However, the description lacks details on sorting, filtering, or error handling, leaving some ambiguity for a list-fetching operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description completely omits the two parameters (eip_id, eip_password), and the schema description coverage is 0%. Since the description must compensate for low schema coverage, it fails to do so. The schema titles 'Eip Id' and 'Eip Password' are self-descriptive but the description adds no additional value or context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving a list of a doctor's future outpatient appointment dates. The Returns section enumerates the specific fields, making the purpose unambiguous. However, it does not explicitly distinguish from sibling tools, though the note hints at a workflow connection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The Note explicitly instructs the user that the returned fields can be used with doc_opd_patient_list_appointment to obtain the appointment list, providing a clear usage context. It does not, however, specify when to prefer this tool over alternatives or mention any 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?
With no annotations, the description carries the burden. It discloses the internal conversion to 民國 format and lists the returned fields, which is useful. However, it does not explicitly state read-only behavior or any side effects, though '查詢' implies query-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses a structured format (Args, Returns, Internal conversion) and is front-loaded with the purpose. It is concise but includes necessary details; the internal conversion note is valuable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description includes return fields and the date conversion behavior, which is helpful given no output schema. However, it omits explanations for the auth parameters and does not describe the structure of the returned data (e.g., list vs object, pagination). Adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no property descriptions (0% coverage), so the description must compensate. It explains 'query' as doctor lamp number and 'date' as YYYY-MM-DD with blank meaning today. However, it does not explain 'eip_id' or 'eip_password', which are required and undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '查詢醫師的手術排程' (query doctor's surgery schedule), specifying the resource and scope. It distinguishes from sibling tools implicitly by focusing on a doctor (醫師) rather than department or detail, but does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides parameter usage (e.g., doctor lamp number, date format) but does not specify when to use this tool vs alternatives or any exclusion criteria. No guidance on 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?
With no annotations, the description carries full burden for behavioral disclosure. It only states the output is HTML and shows a usage example. It does not describe the HTML structure, potential errors, or explicitly confirm read-only behavior, 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the purpose. The example is useful but somewhat redundant with the argument list, yet it still earns its place by demonstrating the workflow. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 required parameters, no output schema, and no annotations, the description should offer more detail. It explains the dependency on patient_consult_list but omits the output format, error cases, and any caveats, making it incomplete for an agent to confidently use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage, so the description's explanations for caseno and oseq (returned by patient_consult_list) are valuable. However, eip_id, eip_password, and hisno are left undocumented, relying on implicit context from sibling tools. Partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves consultation content (HTML), using a specific verb and resource. The example further clarifies it as the follow-up to patient_consult_list. While it doesn't explicitly contrast with sibling note tools, the 'consult' qualifier distinguishes it adequately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The example provides a clear two-step workflow: first call patient_consult_list to obtain caseno and oseq, then call this tool with those values. This implies when to use the tool, though it does not explicitly mention alternatives or exclusion conditions.
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 provided, the description bears the full burden of behavioral disclosure. It discloses a key constraint (no future dates) and lists the return fields, which is helpful. However, it does not explicitly state that this is a read-only operation, nor does it mention authentication requirements or potential rate limits, leaving some behavioral traits undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a clear purpose statement, a behavioral constraint, and separate Args and Returns sections. Every line contributes value, and the structure makes it easy for an agent to locate key information. It could be slightly more detailed on parameter interaction, but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description appropriately lists return fields. However, it lacks explicit mention that eip_id and eip_password are required, does not specify whether the date parameters are mandatory or how they interact, and omits details about pagination or result size limits. These gaps leave some context incomplete for an agent deciding whether 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.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description compensates by explaining the 'date' parameter as a single date in YYYY-MM-DD format and 'start_date/end_date' as a range. However, it does not explain the purpose or format for 'eip_id' and 'eip_password', nor does it clarify whether 'date' and 'start_date/end_date' are mutually exclusive or if both can be provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it downloads IVI schedule from CKS, with a specific verb and resource. It also specifies the scope by prohibiting future date queries, and the return field list further clarifies what the tool outputs. This distinguishes it from sibling tools like doc_opd_schedule or surgery schedules, which target different scheduling domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context such as the date formats and the ability to query a single date or a range, plus the explicit constraint that future dates are not allowed. However, it does not explicitly state when to use this tool over siblings like surgery_doc_schedule_list or doc_opd_schedule, nor does it mention any exclusions or alternative tools.
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 discloses the automatic YYYYMMDD conversion and lists return fields, which is useful. However, it does not explicitly state that the operation is read-only or describe error behavior, access permissions, or side effects. The verb '取得' implies retrieval but lacks explicit safety disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an introduction, Args, Returns, Example, and internal conversion note. Each section adds value without redundancy. It is front-loaded with the purpose and provides a practical example. Slightly verbose but acceptable for a complex multi-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the Returns section is valuable. The example gives a concrete calling pattern. The description covers most functional aspects: parameters, return fields, auto-conversion, and a conditional parameter. Missing credential parameter explanations and error handling are minor gaps given the tool's straightforward read-only nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description must compensate. It explains caseno, dt, type, dept, and dt1 with meanings and formats. However, it completely omits eip_id, eip_password, and hisno, which are required parameters. These are likely common authentication/patient identifiers, but their absence leaves a gap, especially for agents unfamiliar with the system.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states '取得用藥詳細內容' (get medication details), which is a specific verb+resource. It clearly indicates this tool retrieves detailed drug content for a specific case, distinguishing it from patient_drug_list which returns a list. The example shows a two-step workflow, reinforcing its role as the detail-fetching counterpart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The example provides clear usage context: first call patient_drug_list to obtain caseno, then use this tool with those parameters. It also gives conditional guidance for dt1 ('僅住院需要' - only needed for inpatient). However, it does not explicitly contrast with alternative tools or state 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?
The description discloses the return fields (S, O, P, soap, drugs, orders), which is useful behavioral context. However, no annotations are present, so the description must convey all safety and side-effect information; it does not explicitly state that this is a read-only operation, nor does it mention authentication requirements or error behavior. The 'Returns' section adds value but leaves 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with three clearly separated sections: purpose, prerequisite, and returns. Every sentence earns its place and the most important information (what it does) is front-loaded. No redundant text exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must explain everything. It covers purpose, a prerequisite, and returns, but fails to define many return fields (e.g., what 'soap' contains vs S/O/P) and leaves the meaning of several parameters unexplained. For a moderate-complexity tool with 7 parameters and no structured aids, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only explains that dt and dept should be obtained from patient_opd_list, giving those parameters meaning. The other five parameters (eip_id, eip_password, hisno, doc, deptnm) receive no semantic explanation. This is insufficient for a 7-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '取得門診 SOAP 病歷' (get outpatient SOAP medical record), with a specific verb and resource. It further distinguishes itself from siblings by listing the return fields (S, O, P, soap, drugs, orders), which identifies this as the OPD note retrieval tool versus operation note (patient_op_note) or list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit prerequisite: '需先用 patient_opd_list 取得 dt、dept 參數' (must first use patient_opd_list to obtain dt, dept parameters). This names a sibling tool as the correct preceding step, giving clear contextual guidance. It does not explicitly state when not to use this tool, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 discloses the output format (Base64) and the prerequisite (jid from consent_search). However, it does not describe authentication behavior, idempotency, or error handling for invalid jid—minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two short, focused sentences: the first states the tool's purpose, the second gives a prerequisite. There is no redundancy or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description does state the output type (Base64 PDF) and includes a necessary prerequisite. However, it omits descriptions for two of three parameters and does not cover potential errors or output usage. For a simple download tool, this is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only explains 'jid' (as obtained from consent_search). The parameters 'eip_id' and 'eip_password' are not described at all, leaving their purpose and format unexplained. The description adds very little semantic value beyond the bare parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states '下載同意書 PDF (Base64)' which clearly identifies the action (download) and the resource (consent PDF in Base64 format). This distinguishes it from sibling tools like consent_search which is a prerequisite search, and consent_list which likely lists consents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states '需先用 consent_search 取得 jid' (need to first use consent_search to get jid), providing a clear prerequisite and directing the agent to a specific sibling tool. It doesn't mention when not to use, but the usage context is unambiguous.
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 carry the behavioral disclosure burden. It lists the return fields (住院日期, 住院日期_iso, 科別, caseno, adidate) and explains the linkage to patient_ad_note. However, it does not mention that this is a read-only operation, potential pagination, ordering, or scope limitations, which are relevant for a list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the primary purpose. The Returns and Note sections are structured for easy scanning, and every sentence contributes useful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with no output schema and no annotations, the description comes partially complete: it lists output columns and cross-references patient_ad_note. It lacks explicit clarification of key input semantics (e.g., what hisno represents) and behavioral details like order or read-only nature, leaving some gaps for an agent to resolve.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no meaning to the parameters (eip_id, eip_password, hisno). The parameter names are somewhat self-explanatory (credentials and a hospital number), but the description fails to clarify the format or role of hisno, which is important for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with '取得病人住院清單' (get patient admission list), a specific verb and resource. It clearly distinguishes itself from the sibling tool patient_ad_note by stating that the returned caseno and 住院日期_iso can be used to obtain admission details via patient_ad_note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage: it is the list-level tool whose output feeds into patient_ad_note for details. It does not explicitly state when not to use it or mention alternatives, but the note about downstream usage gives actionable 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?
With no annotations, the description discloses the operation's slow nature and built-in protections (delays, error handling, pauses), providing useful behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinctly organized into Args, Returns, and Protection sections, presenting all key information without any filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
It covers purpose, key params, return fields, and operational safeguards, but lacks explanations for the required auth credentials and the overall response structure, which is important given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains formats and defaults for date_start, date_end, limit, and target_depts, but omits the required eip_id and eip_password, and gives a default for date_end that conflicts with the schema's empty string.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it batch retrieves outpatient SOAP notes and lists the returned fields (S, O, P, soap, drugs), distinguishing it from single-note tools like patient_opd_note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for batch retrieval via its name and time-consuming warning, but does not explicitly state when to use this tool over alternatives or provide 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 burden. It adds useful context: the return format is HTML, and the API requires YYYYMMDD format but the tool automatically converts from YYYY-MM-DD. Nevertheless, it does not mention authentication requirements beyond the schema parameters, error behaviors, or what happens if no record is found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a one-line purpose, an Args section, a detailed example, and a brief note about internal conversion. It is not overly verbose and the example is genuinely useful for executing the tool correctly. It slightly exceeds the minimal needed but each section earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers the essential usage: what the tool does, how to obtain required inputs, and the date format conversion. It is adequate for a note-retrieval tool, though it could benefit from stating the output structure or any error scenarios. Overall it is complete enough for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains caseno as the admission case number from patient_ad_list and adidate as the admission date with format flexibility and conversion. However, it does not describe eip_id, eip_password, and hisno, which are likely common across siblings but still undocumented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '取得住院病歷摘要 (HTML)' which means get inpatient admission note summary in HTML format. It identifies the specific resource (住院病歷摘要 / admission note) and distinguishes it from sibling tools like patient_opd_note and patient_consult_note which handle different clinical document types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear step-by-step example showing that the tool should be used after patient_ad_list, and it explains exactly how to obtain and pass the required caseno and adidate from that prior call. However, it does not explicitly state when to avoid using this tool or mention alternative tools.
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 present, so the description bears the full burden. It discloses that the API requires YYYYMMDD format and auto-converts the input, and it lists returned fields. However, it does not mention read-only nature, auth requirements, or error behavior beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized into sections (summary, args, returns, example, internal conversion). Every section adds value, and the example is concise and illuminates the intended usage. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the full workflow, parameter sources, return fields, and internal format conversion. With no output schema, it adequately explains what the tool returns. It lacks edge-case notes (e.g., invalid inputs), but for an agent to invoke it correctly, the provided context is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides source and format for date, ect, and room, including examples. However, eip_id and eip_password are not described at all, leaving two required parameters undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '取得醫師特定門診時段的掛號名單' (get registration list for a physician's specific outpatient clinic time slot). It references doc_opd_schedule for inputs, distinguishing it from previous-list and patient-list tools. The verb and resource are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: the parameters come from doc_opd_schedule, and a two-step example shows when to invoke this tool. It implies the workflow but does not explicitly mention exclusions or alternative tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses a key behavioral limitation (date restriction) and an internal conversion (auto-formatting to YYYYMMDD), plus lists return fields. These insights go beyond the bare schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-organized with clearly labeled sections: purpose, caveat, args, returns, and internal conversion. Every sentence contributes, with no redundant fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers core behavior, return fields, and date constraints, but leaves ambiguity around whether 'date' and 'date_start/date_end' are mutually exclusive, and fails to explain the required eip_id/eip_password parameters. Adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics for date, date_start, and date_end with format and example, but it entirely omits eip_id and eip_password, which are required. Given 0% schema coverage, this partial compensation is insufficient for the auth parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with '取得醫師過去看診名單' (retrieve doctor's past outpatient visit list), which clearly states the tool's verb and resource. The note '僅能查詢過去日期' reinforces the 'previous' scope, distinguishing it from appointment-related siblings like doc_opd_patient_list_appointment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when the tool can and cannot be used: only past dates are queryable; today or future dates return no data. This provides clear usage context, though it does not mention alternative tools for future or appointment 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, the description carries the transparency burden. It discloses the return fields (日期, 日期_iso, 類別, 科別, caseno, dt, type, dept, dt1) and the linkage to patient_drug_content. It does not mention side effects or errors, but the read-only nature is implied by '取得', making this adequate for a simple list retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear title statement, a structured 'Returns:' section listing fields, and a brief 'Note:' for cross-tool usage. Every sentence adds value without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description helpfully lists return fields and explains how to proceed to patient_drug_content. It covers the essential workflow for an agent to invoke the tool and use its output. However, it omits details like date formats, authentication prerequisites, or pagination, leaving minor gaps for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no parameter explanations. The parameter names (eip_id, eip_password, hisno) convey some meaning but leave ambiguity about authentication flow and the exact format of hisno. Since the description does not compensate for the low schema coverage, this dimension is weak.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with '取得病人用藥清單' (get patient medication list), which is a specific verb+resource statement. It clearly distinguishes itself from siblings like patient_drug_content (list vs. details) and other patient list tools by explicitly focusing on medication.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The note '返回的參數可用於 patient_drug_content 取得用藥詳情' provides clear context: use this tool to obtain a list of medication records whose parameters can then feed into patient_drug_content for details. While it doesn't explicitly state when not to use it versus all siblings, it gives a concrete workflow context, which is more than implied 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?
With no annotations, the description carries the full burden. It clearly marks the operation as a read ('查詢'), discloses the internal ROC date auto-conversion, and states the default date behavior. These are non-obvious traits beyond the schema, though it does not mention permissions 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with a clear first-line purpose. It includes necessary parameter details, a return reference, and a conversion note, with no filler or repetition. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must explain return values. It says 'Returns: 同 surgery_doc_schedule_list', which is not self-contained and relies on another tool's description. It also lacks explicit usage alternatives. Parameters and conversion are covered, but these gaps make it incomplete for a standalone tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the query parameter with an example ('OPH'), the date format and default, and the internal conversion. eip_id and eip_password are not described, but their purpose is self-evident from their names within this auth-required context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with '查詢科別的手術排程' (query department surgery schedule), a specific verb + resource. It explicitly says '科別' (department), distinguishing it from doctor-level sibling surgery_doc_schedule_list, and details the query parameter as a department code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the department scope ('科別') and the return-format reference to surgery_doc_schedule_list, but there is no explicit when-to-use/when-not-to-use or alternative recommendation. An agent must infer that department-level queries belong here.
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 the full burden of behavioral disclosure. It discloses that only completed surgeries are returned, specifies the return fields (手術日期, 手術日期_iso, 手術名稱, 主刀醫師), and provides an integration hint with patient_op_note. While it doesn't mention authentication or error conditions, for a read-only query tool this is a solid level of 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and largely well-structured, with the purpose stated first and a clear note about an alternative tool. There is minor redundancy between the first two sentences ('取得病人已完成的手術紀錄清單' and '查詢過去已執行完成的手術'), but overall it is efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list-retrieval tool, the description covers the essential aspects: it defines the scope (past completed surgeries), lists the return fields, and provides a cross-reference to patient_op_note. However, it does not explain the required parameters or mention any ordering/filtering behavior, leaving slight room for ambiguity. Still, the core contextual information is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has three required parameters (eip_id, eip_password, hisno) with zero description coverage. The tool description does not explain any of these parameters, leaving the agent to infer that eip_id/eip_password are credentials and hisno is a patient identifier. With 0% schema coverage and no param explanation, this is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '取得病人已完成的手術紀錄清單' (get the list of completed surgical records for a patient). It uses a specific verb and resource, and explicitly distinguishes itself from the sibling tool patient_op_schedule by noting that future scheduled surgeries should use that tool instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: it states when to use this tool (for past completed surgeries) and when not to use it (for future scheduled surgeries, use patient_op_schedule). It also adds a practical note about using the returned '手術日期_iso' field directly with patient_op_note, which is helpful cross-tool 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?
Without annotations, the description carries the burden; it clearly indicates this is a read/query operation, defines the time scope (future), and lists the exact return fields. It does not mention potential edge cases or permission requirements beyond the implied credentials.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main purpose, then provides usage guidance in the second sentence, and ends with a clear list of return fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with 3 required params and no output schema. The description covers purpose, scope, and return fields, and distinguishes the sibling tool. However, it fails to describe the parameters, which are essential for invocation, especially given zero schema descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not explain the meaning of hisno, eip_id, or eip_password, leaving the agent to infer from context. Some minimal implication exists (hisno is likely the patient identifier), but no explicit details are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a patient's scheduled surgery list and specifies it queries future scheduled procedures, differentiating from sibling tool patient_op_list for past records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use patient_op_list for past completed surgeries, providing a clear alternative and exclusion criteria.
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 must carry the burden. It discloses the return fields and the ward default ('預設不限'), but does not explicitly state read-only behavior, pagination, or error handling. For a search tool, this is moderately transparent but lacks edge-case 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured with an intro, Args block, and Returns block. Each line adds value; there is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema or annotations, the description provides the return schema and key constraints. It lacks details on authentication behavior and error responses, but for a simple search tool it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters fully. It does so by listing every argument with Chinese labels and mapping ward's default '0' to '不限' (unlimited). It also clarifies the mutual-exclusion requirement, adding meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb '搜尋' (search) with a clear resource '病人' (patient) and specifies the query keys: 病歷號/身分證號/姓名. This distinguishes it from siblings like patient_info or patient_opd_list_search by focusing on identifier-based patient lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states the precondition '至少需提供 hisno、pidno、name 其中之一' (at least one of these is required), which is clear usage guidance. It does not mention alternatives or exclusions, but the search scope is well defined.
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 present, so the description carries the burden. It adds meaningful behavioral context by explaining the prerequisite (link_url from a list tool) and enumerating the exact return fields. It does not mention read-only status or error conditions, but the detail-retrieval nature is implied and the output list is valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear purpose sentence, a prerequisite sentence, and a clean list of return fields. No unnecessary content; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple detail-fetch tool with 3 parameters, the description covers the key workflow and output expectations. Missing details about authentication parameters, but overall it provides sufficient context for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It only explains link_url (how to obtain it), but eip_id and eip_password are not addressed at all. This leaves the agent without semantic meaning for two of the three required parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves detailed surgery information (取得手術詳細資訊) and lists the specific return fields, making its purpose unambiguous. It also distinguishes itself from sibling list tools by requiring a link_url obtained from surgery_*_schedule_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to first get link_url from surgery_*_schedule_list before using this tool, providing a clear workflow and distinguishing when to use this detail tool versus the list tools. This is strong usage guidance.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/eyeduck-ai/vghsdk-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server