Sourced facts on treatment in China: hospitals, dated price ranges and process guides. Read-only.
Scored across 4 tools
Each tool targets a clearly distinct resource: topical guides, a specific hospital, treatment prices, and treatment/condition discovery. The guide and treatment-search tools are broad but still separable by intent and description.
All names use snake_case verb_noun form, with get_* for direct retrieval and search_* for discovery. The single search verb is appropriate to its action rather than an inconsistency.
Four tools are well matched to a focused China health information server, with each tool covering a distinct lookup need. The surface stays small without feeling arbitrarily thin.
Core lookup areas are covered, but there is no tool to search or list hospitals, so agents need to already know a hospital name to use get_hospital. That creates a notable dead end for common discovery queries.
Return the summary of a ChinaHealth guide on visas, payment, records, insurance, follow-up or clinical trials.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds one useful trait beyond that – it returns a summary rather than full guide content – but says nothing about auth, empty results, or what a summary contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the verb and resource, with zero filler. Nothing could be cut without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, single-enum-parameter lookup with no output schema, the description is nearly sufficient: the agent knows what it retrieves and at what granularity. Only the return shape and failure behavior on an invalid topic are left to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% but the single parameter is a closed enum whose six values are restated in the description with slight domain framing (e.g. 'records' = medical records, 'follow-up' care). This adds marginal meaning, but it largely mirrors the enum rather than explaining value semantics or defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Return the summary'), a specific resource (a ChinaHealth guide), and an explicit topic scope covering all six enum values. The resource is clearly disjoint from the siblings (get_hospital, get_price_ranges, search_treatments), though the description never says so explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The topic enumeration implicitly tells the agent which subject areas are covered, and 'summary' hints at the expected depth. But there is no explicit when-to-use or when-not statement and no mention of the sibling tools as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return sourced facts about one hospital in China (city, international department, documented strengths).
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds that facts are 'sourced', which is useful context about provenance, but says nothing about behavior when the slug is unknown or how large the response is.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with the verb, scope, and returned fields; no filler or repetition of structured data.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description usefully previews return content (city, international department, documented strengths) despite no output schema, and annotations cover the safety profile. However, for a lookup keyed on an opaque slug, omitting how to obtain or format that identifier leaves a real gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one parameter with 0% schema description coverage: 'slug' is typed as a bare string with no explanation. The description only implies it identifies one hospital and gives no format, example, or guidance on where to obtain the slug, so it fails to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource (return facts about one hospital) and scopes it geographically (China), plus lists the fact categories covered. It implies a single-record lookup, which contrasts with the sibling search_treatments, though it never names a sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the phrase 'one hospital' signals a single-record lookup, so an agent can infer it follows a search. There is no explicit when-to-use/when-not or pointer to get_guide, get_price_ranges, or search_treatments as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return price entries for a treatment in China. Each entry has a source, year and verification status. Prices are not quotes.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| treatment | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, non-destructive, closed-world), so the bar is lower; the description still adds real value by disclosing that each entry carries a source, year and verification status, and by warning that prices are not quotes. It omits result size, pagination, and what an unverified entry means, which keeps it off a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, front-loaded with what is returned, followed by entry shape, then the caveat. No filler and every sentence adds information an agent would otherwise lack.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only lookup with no output schema, the description does explain the entry fields, which is the main thing. But with zero schema coverage it should have covered the city parameter and stated the price currency/unit for China, both of which an agent needs to call and interpret results correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry parameter meaning, and it only addresses 'treatment' implicitly ('for a treatment'). The 'city' parameter is never mentioned, so an agent cannot tell it is an optional geographic filter, whether multiple cities are allowed, or what happens if omitted. Currency and units for the returned prices are likewise unstated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
A specific verb (return) plus resource (price entries) with scope (for a treatment in China). The described entry shape (source, year, verification status) also disambiguates it from get_hospital and get_guide. It doesn't explicitly name a sibling it differs from, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: an agent infers it should call this when it needs pricing data for a treatment. There is no when/when-not statement, no mention of whether to pair it with search_treatments to resolve the treatment argument, and no exclusion of other tools. 'Prices are not quotes' is a helpful interpretation caveat but not routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find conditions and treatments documented on ChinaHealth, with links to sourced pages. Does not give medical advice.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, non-destructive, and closed-world, so safety is covered. The description adds genuine context beyond that: results include links to sourced pages, and the tool is explicitly non-advisory. It says nothing about result ranking, result count, pagination, or how broad a query can be.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with the core capability front-loaded and the disclaimer trailing. Nothing is redundant, though the description is arguably too sparse given the undocumented parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter search with annotations covering the safety profile and no output schema, the description is workable but thin: it omits parameter meaning entirely and gives no hint of result volume or ranking. An agent can call it, but must consult the schema plus guesswork for the city filter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and there are two parameters, yet the description never mentions either 'query' or 'city'. The city filter in particular is undisclosed in prose, so an agent must open the schema to learn that results can be narrowed geographically — the description does not compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource: "Find conditions and treatments documented on ChinaHealth" tells the agent exactly what will be retrieved and from which source. It is distinguishable in subject matter from get_hospital and get_price_ranges, though it never names them, so the differentiation is implicit rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The line "Does not give medical advice" establishes a scope boundary for what the tool will not do, which is useful. However, there is no guidance on when to pick this over the sibling tools (get_guide, get_hospital, get_price_ranges), so routing is left to inference from the title.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_guideget_hospitalget_price_rangessearch_treatmentsSourced, read-only hospital facts for Guangzhou and Shenzhen, with a free inquiry link.
Read-only selected China industry article excerpts, disclosed sources and company identity links.
Read-only sourced Hong Kong insurance facts and referral links. No product recommendations.
Read-only Genko Prior Auth docs, guides, specialty checklists, facts, pricing and fit checks.
Add one secure layer between your agents and this server.
