List every channel group in the AcuiQ point catalogue with its acupoint count and page URL — the 14 classical meridians plus the extra-point and auricular groups the catalogue files points under. Descriptions and five-element associations are returned where recorded, which is currently for almost none of them.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, covering the tool's read-only and deterministic nature. The description adds valuable context beyond annotations: it specifies the output components (acupoint count, page URL, descriptions, five-element associations) and honestly notes that those fields are 'currently for almost none of them', setting accurate expectations about data sparsity. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, tightly packed. The first sentence front-loads the action, the exact scope, and the primary outputs. The second sentence adds a single caveat about data availability. Every clause earns its place with no filler or repetition.
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 zero-parameter, no-output-schema listing tool, the description fully covers what the agent needs to know: what is listed, the specific groups, the fields returned, and the current data completeness caveat. There is no missing information that would prevent correct invocation or interpretation.
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?
Since the tool has zero parameters, the schema trivially covers 100% and there is no need for parameter-level documentation. The baseline for zero-param tools is 4, and the description does not attempt to invent parameter info. It adds no parameter semantics, but none are required.
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 states a clear verb ('List') and specific resource ('every channel group in the AcuiQ point catalogue'), and enumerates the exact groups included (14 classical meridians plus extra-point and auricular). This distinguishes it from the sibling tools, which concern checkout, individual points, symptoms, and search — none of which overlap with listing all meridian groups.
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 does not provide any explicit or implied guidance on when to use this tool versus sibling tools. It does not mention alternatives, nor does it state contexts where this tool is the appropriate choice. The purpose is clear, but the usage context is entirely 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.
