Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@TCM MCP Server search for formulas for insomnia"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
倪海厦经方体系 · AI中医知识引擎
通过 MCP (Model Context Protocol) 协议，让 AI 助手获得专业中医知识：草药查询、方剂检索、针灸取穴、六经辨证。
🌿 15味核心经方草药 — 性味归经/功效/经典药对/倪师注解
📜 14首伤寒金匮核心方 — 组成/适应证/六经归属/方歌/禁忌
📍 13个常用穴位 — 定位/针法/主治/四总穴诀
🏥 六经辨证框架 — 输入症状→判定经证→推荐方剂
⚠️ 配伍禁忌检查 — 十八反/十九畏
Related MCP server: HowToCook-MCP Server
pip install -e .或
uv pip install -e .在 settings.json 中添加：
{
"mcpServers": {
"tcm": {
"command": "uv",
"args": ["run", "--directory", "/path/to/tcm-mcp-server", "tcm-mcp"]
}
}
}工具 | 功能 | 示例 |
| 搜索草药 | "桂枝", "解表", "温里", "头痛" |
| 搜索方剂 | "小柴胡汤", "太阳病", "失眠" |
| 搜索穴位 | "足三里", "胃经", "腰痛", "肚腹" |
| 六经辨证 | "发热恶寒汗出脉浮缓" |
| 配伍禁忌检查 | ["附子", "半夏", "甘草"] |
| 知识体系概览 | （无参数） |
tcm://categories/herbs — 草药按功效分类
tcm://categories/formulas — 方剂按功效分类
tcm://meridians — 穴位按经络分类
tcm://six-channels — 六经辨证完整框架
tcm-diagnosis — 辅助中医辨证论治
formula-analysis — 分析方剂组成和配伍规律
基于倪海厦（1954-2012）汉唐中医体系：
《伤寒论》六经辨证
《金匮要略》杂病证治
《神农本草经》药物体系
《针灸大成》经络腧穴
扶阳理论、汉唐处方体系
核心草药/方剂/穴位数据
六经辨证诊断工具
配伍禁忌检查
更多草药和方剂（目标100+味草药，50+首方）
医案数据库（症状→方剂疗效）
舌诊/脉诊辅助描述
Web 界面（面向中医学生的AI学习工具）
MIT
基于倪海厦六经辨证体系，根据输入的症状判断属于哪一经病，推荐对应经方。输入症状如'发热恶寒汗出脉浮缓'或'寒热往来胸胁苦满口苦'。
| Name | Required | Description | Default |
|---|---|---|---|
| symptoms | Yes | 患者的症状描述，可以包含发热、恶寒、汗出、头身疼痛、脉象、饮食、二便等信息。例如：'发热恶寒，汗出，头痛，脉浮缓' |
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.
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.
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.
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.
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.
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.
检查两味或以上的中药是否存在配伍禁忌（如十八反、十九畏）。输入草药名列表。
| Name | Required | Description | Default |
|---|---|---|---|
| herbs | Yes | 需要检查的草药名列表。例如：['附子', '半夏', '川贝'] |
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.
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.
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.
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.
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.
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.
获取倪海厦中医体系的整体概览：三纪体系（天纪/人纪/地纪）、六经辨证框架、扶阳理论核心、常用经方分类、针灸体系。适合刚接触中医想了解整体架构的场景。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
按名称、归经、主治搜索穴位。支持穴位名（'足三里'）、归经（'胃经'）、主治（'头痛'/'失眠'）、四总穴诀（'肚腹/面口/头项/腰背'）。返回定位、针法、主治、倪海厦注解。
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 搜索关键词。可以是：穴位名（足三里/合谷/三阴交）、经络（肺经/胃经/肾经）、症状（头痛/失眠/胃痛/腰痛/痛经）、四总穴诀（肚腹/面口/头项/腰背） |
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.
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.
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.
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.
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.
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.
按名称、适应证、关键词、六经归属搜索经方。支持中文名（'小柴胡汤'）、适应证（'头痛'）、关键词（'少阳病'）。返回方剂详细信息含组成、功效、主治、六经归属、禁忌、方歌、倪海厦注解。
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 搜索关键词。可以是：方名（桂枝汤/四逆汤）、症状（发热/头痛/失眠/便秘）、六经（太阳病/少阳病）、关键词（回阳/解表/少阳） |
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.
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.
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.
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.
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.
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.
按名称、功效、归经搜索中药。支持中文名（如'桂枝'）、拼音（'Gui Zhi'）、功效（'解表'）、主治（'头痛'）。返回草药详细信息含性味、归经、功效、用量、禁忌、经典药对、倪海厦注解。
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 搜索关键词。可以是：草药名（桂枝/附子/麻黄）、拼音（Fu Zi）、功效（解表/温里/补气）、归经（肺经/肝经）、主治（头痛/失眠/咳嗽） |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0diagnose_six_channelget_formula_compatibilityget_tcm_overviewsearch_acupointssearch_formulassearch_herbsScored across 6 tools
Each tool has a unique purpose: diagnosis, compatibility checking, overview, searching acupoints, formulas, and herbs. There is no overlap or ambiguity.
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.
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.
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.
Evidence-based acupuncture protocol matcher – search symptoms, match protocols, browse acupoints.
Singapore HSA licensed TCM products (~12,000), searchable in Chinese characters, pinyin or English
Connect AI clients to biomedical data and tools.
SymMap v2 — Traditional Chinese Medicine association graph from symmap.org
