TCM MCP Server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a unique purpose: diagnosis, compatibility checking, overview, searching acupoints, formulas, and herbs. There is no overlap or ambiguity.
Naming Consistency4/5
All tools use snake_case with a verb_noun pattern (diagnose_, get_, search_). Minor inconsistency with 'get_formula_compatibility' (adjective instead of noun) but overall consistent.
Tool Count5/5
6 tools is ideal for a specialized TCM server. It covers core functionalities: diagnosis, compatibility, overview, and three search tools, without being too many or too few.
Completeness4/5
The tool set covers key TCM tasks: symptom diagnosis, herb compatibility, and searching for acupoints, formulas, and herbs. Minor gaps like patient case management or treatment planning are absent but acceptable for a general-purpose tool.
Average 4/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 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
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
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.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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 states the tool returns detailed formula information but does not explicitly confirm it is a read-only, non-destructive operation or mention any constraints like rate limits or authentication needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, well-structured, and front-loaded with the purpose. Every sentence adds essential information, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and no output schema, the description thoroughly covers the tool's capabilities and return details. However, it omits mention of pagination or result limits, which are relevant for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description aligns with the schema. The description adds value by illustrating the types of queries (e.g., '小柴胡汤', '头痛', '少阳病') and the expected input flexibility, but the schema already adequately defines the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool searches for classical formulas by various criteria (name, indication, keyword, six-channel classification) and provides concrete examples. It clearly differentiates from sibling tools like search_herbs and search_acupoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives examples of when to use the tool but does not specify when not to use it or mention alternative tools for different search types. With sibling tools like search_herbs, explicit exclusion guidance would help.
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. It describes the tool as a diagnostic/recommendation tool, implying a non-destructive read operation, but it does not disclose any behavioral traits such as whether it modifies data, requires authentication, or has rate limits. Minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first defines purpose, the second gives examples. Every sentence is necessary, front-loaded, and there is no extraneous information. It is highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose and input format. However, with no output schema and no annotations, it lacks details about the output structure (e.g., what fields are returned). This slight gap lowers the score from 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'symptoms' has 100% schema description coverage. The tool description adds value by providing concrete examples of acceptable input formats (e.g., '发热恶寒汗出脉浮缓'), which go beyond the schema's generic description. This helps the agent understand expected input quality.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: based on Ni Haixia's six-channel differentiation system, it determines which meridian disease corresponds to input symptoms and recommends a classical prescription. This verb+resource combination is specific and distinguishes it from sibling tools like search formulas or herbs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides example inputs but does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. Usage is implied by the diagnostic purpose, but explicit guidance is missing.
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 full burden. It discloses the action (checking compatibility) and the specific contraindication types, but does not describe the return format, error handling, or whether it is read-only. The tool appears to be a query tool, but missing behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise—one sentence stating the purpose and a brief input instruction. No unnecessary words, front-loaded with the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is largely complete. It lacks specification of return values, but the essential functionality is clear. Minor gap could be filled with output description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for the 'herbs' parameter. The description adds an example but does not significantly extend the meaning beyond the schema. Baseline of 3 is appropriate given high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks compatibility contraindications between two or more Chinese herbs, specifically mentioning '十八反、十九畏' (eighteen antagonisms, nineteen incompatibilities). It distinguishes from sibling tools like search_herbs or search_formulas by focusing on interaction checking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking herb compatibility, but does not explicitly state when to use this tool versus alternatives (e.g., search_herbs for general herb info). No guidance on prerequisites or when not to use it is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool returns detailed information including nature, flavor, meridian, efficacy, dosage, contraindications, classic pairs, and Ni Haixia annotations. Although no annotations are provided, this level of detail is good for a search tool, though it does not cover all behavioral aspects like error handling 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that effectively communicate purpose, input types, and output contents. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter search tool without an output schema, the description adequately covers input types and output details. It could mention pagination or result limits, but the given information is sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the parameter 'query' with a detailed description, but the tool description adds specific examples and clarifies the output content, adding value beyond the schema. With 100% schema coverage, baseline is 3, but the extra examples and return info justify a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches Chinese herbs by name, efficacy, and meridian, with specific examples (e.g., '桂枝', '解表'). It distinguishes from sibling tools like search_formulas and search_acupoints by focusing solely on herbs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (for searching herbs) but does not explicitly state when to choose this over alternatives or provide 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It describes the content returned but does not explicitly state the tool is read-only or disclose any potential side effects or limitations, though it's implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The main action is front-loaded, and the usage scenario is appended efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists the components returned, which is sufficient for an overview tool. However, it lacks details on output format or confirmation that it is read-only, but given the simplicity, it's adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description adds value by explaining the tool needs no input and what the output covers, exceeding the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves an overall overview of Ni Haixia's TCM system, listing specific components. This distinguishes it from sibling tools like diagnose_six_channel or search_herbs which have narrower scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage scenario: suitable for newcomers wanting an overall architecture. However, it does not explicitly mention when not to use or compare to alternatives, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses what the tool returns (location, needling method, indications, Ni Haixia annotations) and the types of queries supported. Since no annotations are provided, it carries the full burden but does not explicitly state safety or side effects. However, it is a search tool, so the behavior is transparent enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences covering the search types and return fields. It is front-loaded and every sentence provides essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description adequately explains the return fields (location, needling method, indications, annotations). The single parameter is well-described, and the tool's purpose and inputs are fully covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter description in the schema already lists examples, but the tool description adds value by including the four general acupoint rules ('肚腹/面口/头项/腰背') which is not in the schema. This enriches the semantics beyond the structured input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool searches acupoints by name, channel, indications, and special patterns like the four general acupoint rules. It uses specific verbs and resources, and distinguishes from sibling tools like search_formulas and search_herbs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for searching acupoints but does not explicitly state when to use vs alternatives or provide exclusions. No comparison with sibling tools is given.
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:

[![tcm-mcp-server MCP server](https://glama.ai/mcp/servers/liuweihongliuxinyu/tcm-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/liuweihongliuxinyu/tcm-mcp-server)

Score Badge

Copy to your README.md:

[![tcm-mcp-server MCP server](https://glama.ai/mcp/servers/liuweihongliuxinyu/tcm-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/liuweihongliuxinyu/tcm-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/liuweihongliuxinyu/tcm-mcp-server'

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