Resolve one acupoint by code ("LI4", "li04"), English name ("Junction Valley"), Chinese name ("合谷") or pinyin ("Hegu", "hé gǔ") and return its location, cautions, meridian, the points most often selected alongside it in the corpus, its page URL and markdown twin. For the full protocol table, fetch the markdown twin.
| Name | Required | Description | Default |
|---|---|---|---|
| point | Yes | Code, English name, Chinese name or pinyin (e.g. "LI4", "Hegu", "合谷") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and the description adds valuable behavioral details: it returns co-occurring points, page URL, and markdown twin, and directs to the markdown twin for the full protocol table. This goes beyond the annotations and sets clear expectations for what the tool does and does not return.
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?
The description is a single dense sentence followed by a short directive, front-loaded with the main purpose. Every clause contributes useful information (identifier formats, return fields, limitation), with no fluff. It's slightly packed but efficient, earning a 4 rather than a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully outlines what the tool returns (location, cautions, meridian, co-selected points, page URL, markdown twin) and explicitly notes what it does not return (full protocol table). Given the tool's single parameter and lack of an output schema, this is complete information for an agent to call it 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?
The schema already provides a description covering 100% of the parameter, including examples like "LI4", "Hegu", and "合谷". The description repeats these examples and adds the accented form "hé gǔ", but this does not substantively enhance meaning beyond what the schema already conveys. Baseline 3 is appropriate given full schema coverage.
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 clearly states the action 'Resolve' and the target resource 'one acupoint', and lists multiple accepted identifier formats (code, English name, Chinese name, pinyin). It distinguishes itself from sibling tools like get_meridians and search_* by specifying it's a single-point lookup with a specific output set, so an agent can immediately tell it apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a specific acupoint identifier is known, and it provides an alternative route (fetch the markdown twin) for the full protocol table. However, it doesn't explicitly name sibling tools or state when not to use this tool versus alternatives, so context is clear but exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct action: checkout, meridian listing, point resolution, symptom detail, protocol search, and symptom resolution. There is no overlap; even search_protocols and search_symptoms are clearly separated by input and purpose.
All tool names follow a consistent verb_noun pattern using snake_case: create_checkout, get_meridians, get_point, get_symptom_detail, search_protocols, search_symptoms. No mixing of conventions or vague verbs.
With 6 tools, the set is well-scoped for the server's purpose. Each tool covers a necessary function (purchase, catalogue browsing, point lookup, symptom lookup, protocol search, symptom resolution) without redundancy or bloat.
Core workflows are covered: resolve symptoms, search protocols, get point details, list meridians, and checkout. Minor gaps exist—no direct listing of all points or all symptoms beyond popular=true—but agents can work around by using search_symptoms and get_point with known codes.
