This server provides a comprehensive toolkit for individualized meal planning and nutritional management of children with chronic kidney disease (CKD), based on KDIGO 2024 and PRNT 2020 guidelines.
Patient Management: List simulated pediatric patients and retrieve full profiles (age, weight, CKD stage, dialysis type, allergies, dietary culture) and lab results (potassium, phosphorus, albumin, etc.).
Diet Diary & Analysis: Record food entries for specific days or meals, view diet diaries, and analyze them for nutritional risks (e.g., excess potassium/sodium/phosphorus, protein imbalance, hidden allergens).
Nutrition Targets: Compute personalized daily targets for energy, protein, sodium, potassium, phosphorus, calcium, and fluid based on patient profile and latest labs.
Meal Plan Generation: Generate deterministic, five-meal daily plans with gram-accurate food weights, meal times, alternative options, cooking tips (e.g., soaking/blanching to reduce potassium), and variant seeds for multi-day rotation; plans are auto-saved.
Meal Plan Management: Manually save meal plans as JSON, list previously saved plans with dates, energy, and protein summaries.
Food Database: Search the Chinese Food Composition Table with renal-friendly classifications for potassium, phosphorus, sodium, and purines; retrieve detailed nutrient profiles; find equivalent food substitutes.
Educational Resources: Access knowledge cards on specific CKD nutrition topics, such as potassium restriction, phosphorus control, and low-protein starches.
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., "@ckd-meal-plan-mcp Generate a meal plan for patient 3 with low potassium"
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.
面向儿童慢性肾脏病（CKD 1–5 期及透析）的确定性个体化食谱生成服务。 结合患儿年龄、CKD 分期、透析状态、食物过敏、地方饮食文化与 3 天饮食日记， 输出符合 KDIGO 2024 / PRNT 2020 / KRCP 2025 营养目标的可执行一日五餐食谱 （含克重、餐次、量具换算、替代方案与烹饪去钾/去磷要点）。
团队：南方医科大学南方医院 NFYY038 团队 ｜ 复赛交付物
严格参考权威依据：能量按 IOM/DRI 2005 EER 方程估算；蛋白按 PRNT 2020 取区间上限促生长、下限为不可破安全底线；钾/磷/钠分层参照 KRCP 2025。
确定性计算，零模型幻觉：所有克重、能量、钠钾磷换算均由代码层硬规则完成，模型不参与任何算术（与 NFYY038 风险预警 Agent 的硬规则范式一致）。
覆盖全场景：15 名模拟患儿覆盖 CKD G1–G5D 全分期、非透析/腹透/血透/HDF 四种透析、10 类过敏原、10 种地方饮食文化。
个体化约束：限钾/限磷时剔除危险食材（高钾主食/水果/蛋白、高磷蛋白源），优先低钾低磷品种，并用焯水/浸泡/水煮弃汤等烹饪折减。
零蛋白能量模块：用粉丝/米粉/藕粉/凉粉等近乎零蛋白淀粉补足能量，避免靠谷物堆热量而冲爆低蛋白上限。
可轮换多日食谱：传入不同 variant 即可得到不同食材搭配，便于编排连续多日食谱。
饮食日记分析：对比 KDIGO 目标识别高钾水果、老火汤、加工食品钠磷超标、蛋白不足/过量、隐藏过敏原。
Related MCP server: a207-his-mcp
工具 | 作用 |
| 列出全部模拟患儿 |
| 患儿完整档案 |
| 化验记录 |
| 最近 N 天饮食日记 |
| 记录某一天某一餐的一种食物，写入 SQLite（可反复追加） |
| 一次性记录某一天整日饮食（JSON 批量），写入 SQLite |
| 饮食日记营养风险分析（含新记录的当日数据） |
| KDIGO 2024 个体化营养目标 |
| 生成一日五餐食谱（自动落库） |
| 手动保存食谱 JSON |
| 已保存食谱列表 |
| 《中国食物成分表》检索 + 肾友分级 |
| 单食物完整营养素与分级 |
| 同类等效替代 |
| 儿童 CKD 营养知识卡片 |
记录链路：
record_diet_entry/record_diet_day→ 写入diet_diary表 →get_diet_diary可随时读回、analyze_diet_diary重新分析（与历史种子日记合并统计）。
Python 3.10+ · FastMCP 2.x/3.x · stdio 传输
uvx 经由 pyproject.toml 的 console_scripts 入口直接拉起
内置 SQLite 存储（患者档案、化验、日记、已生成食谱）
# 方式一：从源码
pip install -e .
python -m nfyy_ckd_meal_plan.server # stdio 模式
# 方式二：uvx（发布到 PyPI 后）
uvx nfyy-ckd-meal-plan-mcp
# 自定义 SQLite 路径（默认 ~/.nfyy-ckd-meal-plan/meal_plan.db）
export NFYY_MEAL_DB=/path/to/meal_plan.db首次运行会自动用内置的 15 名模拟患儿数据播种 SQLite。
服务以 stdio 暴露，任何兼容 MCP 的客户端（Claude Desktop、魔搭社区、自建 Agent） 只需配置启动命令：
{
"mcpServers": {
"nfyy-ckd-meal-plan": {
"command": "uvx",
"args": ["nfyy-ckd-meal-plan-mcp"]
}
}
}CKD儿童能量与蛋白质营养管理_KRCP2025知识库.md —— 营养目标、分级阈值、临床铁律
中国食物成分表.xlsx —— 1752 条食物 × 35 项营养素（已转为 data/food_data.csv）
15 名患儿为虚构演示数据，仅用于复赛功能验证，不构成任何真实诊疗建议。
先定蛋白源，再用零蛋白能量补热；能量缺口不靠加肉补。
加餐近零蛋白，只承担能量与愉悦感。
限钾不等于不吃菜：先选低钾品种，再改刀→浸泡→焯水弃汤。
限磷优先砍无机磷（加工食品磷酸盐添加剂吸收率≈100%）。
蛋白下限是绝对安全底线，任何情况不可突破。
详见 docs/deploy.md：GitHub（代码）→ PyPI（可安装包）→ 魔搭社区（登记为可调用的 MCP 服务）。
本服务为营养管理辅助决策工具，所有输出不构成医疗建议。蛋白质/钾/磷/钠的最终处方上限 须由儿科肾脏专科医师或注册营养师核定；磷结合剂、钾结合剂、透析处方调整不得依据本服务自行变更。
分析患儿最近 N 天饮食日记：识别高钾水果、老火汤、加工食品钠磷超标、蛋白不足/过量、隐藏过敏原。
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| patient_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description itself must convey behavioral traits. It does list specific analysis categories and suggests an assessment of dietary risks, but it does not disclose whether this is a read-only operation, whether it fetches data from elsewhere, or how findings are returned. This leaves some ambiguity but is not misleading.
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 one efficient, front-loaded sentence with a clear action and a colon-delimited list of specific analysis outcomes. There is no filler, and every phrase adds value.
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 tool has only two simple parameters, an output schema exists, and the action is clearly stated with a concrete list of dietary risk factors, the description is largely complete. The main shortfall is not stating data-source prerequisites, but this is a minor gap relative to the tool's complexity.
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 has no descriptions for its two parameters, and the description's coverage is 0%. However, '最近 N 天' partially clarifies the 'days' parameter, and '患儿' implies patient_id. It does not explicitly define defaults, ranges, or the relationship between 'N' and the schema, so compensation is partial.
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 action ('analyze') and resource ('diet diary'), and enriches it with a clear list of target findings: high-potassium fruits, old fire soup, processed food sodium/phosphorus excess, protein imbalance, and hidden allergens. This clearly distinguishes it from sibling retrieval tools like get_diet_diary or compute_nutrition_targets.
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 the tool is for clinical diet review and risk identification, but it does not explicitly state when to prefer it over alternatives such as get_diet_diary or generate_meal_plan, nor does it mention exclusions, prerequisites, or context like needing labs. The intended use is inferable but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
根据患儿档案 + 最新化验，输出 KDIGO 2024 / PRNT 2020 个体化营养目标（能量/蛋白/钠/钾/磷/钙/液体）。
| Name | Required | Description | Default |
|---|---|---|---|
| patient_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool uses patient profile and latest labs and follows specific guidelines, which is useful. However, it does not state whether the operation is read-only or if there are side effects, nor does it mention behavior on missing data. The 'compute' naming implies pure calculation, but explicit safety details are absent.
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, compact sentence that packs in the input basis, guideline names, and output nutrients. It is front-loaded with the core purpose and contains no wasteful words 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?
The tool is simple (one parameter) and has an output schema provided, so the description does not need to explain return values. It clearly states the necessary inputs (profile + labs) and outputs (nutrition targets). The only minor omission is handling of missing lab data, but given the output schema exists, this is not critical for an agent to decide invocation.
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 only one parameter, patient_id, and the description indirectly references it by mentioning the patient profile. The schema has no description coverage, so the description must compensate. While patient_id is semantically obvious from the field name, the description does not explicitly state that it is the identifier used to fetch the profile and labs, leaving a slight 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 uses a specific verb ('output') and resource ('individualized nutrition goals') and clearly lists the nutrient categories, distinguishing it from sibling tools like generate_meal_plan or get_labs. It also names the guideline versions (KDIGO 2024 / PRNT 2020), making its purpose unmistakable.
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 implicitly gives context by stating it uses the patient profile and latest labs, making it clear when this tool is appropriate (after those data are available). It does not explicitly name alternatives or exclusions, but the context is sufficient for typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
生成一日五餐可执行食谱（含克重/餐次/替代方案），并自动写入 SQLite。
| Name | Required | Description | Default |
|---|---|---|---|
| variant | No | 轮换种子（0/1/2… 不同数字得不同搭配，便于排多日食谱） | |
| plan_date | No | 计划日期（留空取今天） | |
| patient_id | Yes | 患儿 ID（如 P004） | |
| exclude_foods | No | 逗号分隔的需剔除食物（患儿/家长指定不吃） |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the side effect of auto-writing to SQLite, which is important, but does not mention overwrite behavior, prerequisites, or other potential impacts. It adds some context but not comprehensive transparency.
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 sentence that front-loads the main action and includes key output details and the persistence side effect. Every word contributes value, with no waste.
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 output schema exists and the schema covers all parameters, the description adequately covers the core operation and the key side effect (SQLite write). It does not explain conflict handling or whether it requires existing patient data, but these are minor gaps given the available structured metadata.
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 all parameters having descriptions, so the baseline is 3. The description adds no parameter-specific details beyond what the schema already provides.
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 the tool generates a one-day five-meal executable meal plan with grams, meal times, and alternatives, and automatically writes to SQLite. This is a specific verb+resource+scope, and the auto-write detail distinguishes it from sibling save_meal_plan.
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 (generating a meal plan with details and persisting it) but does not explicitly mention when to use this tool versus alternatives like save_meal_plan or compute_nutrition_targets. No exclusions are stated, but the context is clear enough.
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 |
|---|---|---|---|
| limit | No | ||
| food_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral transparency. It does disclose the conversion methodology (equal protein/equal energy), which is useful and beyond what the schema shows. However, it does not mention other behavioral aspects such as handling of unknown foods, limit behavior, or whether the operation is read-only. The description is not misleading, but it has gaps.
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, concise sentence that front-loads the main purpose and includes a useful detail about conversion rules. There is no redundant information or filler, making it highly efficient.
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 relatively simple tool with an output schema, the description covers the core purpose and conversion logic. However, given the 0% parameter coverage and lack of explicit usage guidance, the description is not fully complete. It leaves some important aspects to be inferred or discovered from the schema.
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 compensate for undocumented parameters. It implicitly refers to the food name through '某食物' but does not explicitly identify the parameter 'food_name' or explain the 'limit' parameter. The limit parameter is completely unaddressed, leaving the agent to guess its meaning from the schema.
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 function: it provides equivalent substitutions for a given food, with specific conversion rules (equal protein for protein sources, equal energy for staples/oils). The verb '给出' (give) and the resource '某食物的同类等效替代' make the purpose specific, and it distinguishes itself from sibling tools like search_food or get_food_profile by focusing on alternatives.
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 the tool is for finding substitutions but does not explicitly state when to use it over alternatives or any exclusions. There is no mention of prerequisites or contrasting with sibling tools like search_food. The usage context is only implied by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取患儿最近 N 天饮食日记（餐次/食物/克重/烹饪方式）。
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| patient_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | 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 discloses the diary content and the time window, which is useful, but it does not mention side effects, permissions, error behavior, or that it is a read-only operation. For a simple fetch tool, the disclosure is adequate but not rich.
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, efficient sentence that is front-loaded with the verb and contains no filler or redundant information. Every word earns its place.
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?
With only two parameters and an output schema present, the description covers the purpose and output content sufficiently. It does not explain error handling or prerequisites, but for a simple retrieval tool, it is reasonably complete at this length.
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 compensate. It connects 'N天' to the `days` parameter and '患儿' to `patient_id`, and explains the diary content. However, it does not explain defaults, allowed values, or the exact role of `patient_id` beyond identifying the child, so compensation is partial.
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 (获取/retrieve), the resource (diet diary), and the scope (recent N days), and enumerates the content categories (meals/food/grams/cooking method). This distinguishes it from sibling tools like analyze_diet_diary, which analyzes rather than retrieves.
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 clearly implies when to use the tool—when the raw recent diet diary is needed—and its scope is obvious from the verb and resource. However, it does not explicitly mention alternative tools for analysis or explain when not to use it, so it lacks formal exclusions but still provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查询某食物的完整营养素与肾友分级（含每 100g 能量/蛋白/钾/磷/钠/钙）。
| Name | Required | Description | Default |
|---|---|---|---|
| food_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It states what is queried and returned (nutrients and classification) but does not mention error handling, exact-match behavior, or any side effects. As a read-only query, this is adequate but not rich in behavioral context.
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, concise sentence that front-loads the primary purpose and includes a list of included nutrients. Every word is informative, with no fluff or 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?
An output schema is present, so return values do not need explanation. The description covers the tool's core function sufficiently for invocation. However, it does not clarify how this tool relates to food-related siblings (search_food, get_alternatives), which would enhance contextual completeness. Given the simple single-parameter nature, it is mostly complete.
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 provides no description for food_name (0% coverage). The description's reference to '某食物' (a certain food) gives semantic meaning to the parameter, indicating it identifies the food to query. However, it does not specify name format, exact match, or case sensitivity, so it only partially compensates 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 clearly states the tool queries complete nutrient data and kidney patient classification for a specific food, listing the specific nutrients included. This verb+resource combination distinguishes it from siblings like search_food (searching for foods) and get_alternatives (finding alternatives).
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 detailed nutrient and kidney classification data for a food is needed, but it does not explicitly contrast with sibling tools or state when not to use it. There are no exclusions or alternative recommendations, leaving the agent to infer from the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取患儿化验记录（含血钾/血磷/白蛋白/BUN/尿量等）。
| Name | Required | Description | Default |
|---|---|---|---|
| patient_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not state that the tool is read-only, whether it returns all records or only the latest, or what happens if the patient_id is invalid. The description is limited to a raw statement of functionality, omitting important behavioral traits.
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, concise sentence that fully states the tool's purpose and key data contents. It is front-loaded with the essential information and contains no redundant or vague phrasing, making it efficient and well-structured.
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 provides the core function and sample content, which is adequate for a simple retrieval tool with an output schema. However, it lacks context about when to use it, the meaning of patient_id, and any constraints or prerequisites, leaving it minimally viable but not fully complete.
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 provides no description for patient_id, and the tool description also fails to explain what the parameter represents or how to obtain it. Since schema description coverage is 0%, the description must compensate but does not, leaving the agent with only the parameter name to infer meaning.
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 function: retrieving a child patient's laboratory records, and names specific contents (blood potassium, phosphorus, albumin, BUN, urine output). This distinguishes it from sibling tools like get_diet_diary and get_patient_profile, which serve different data domains.
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?
No guidance is provided on when to use this tool versus alternatives. It does not mention contexts such as reviewing a patient's lab results or the need for a valid patient_id. The description simply states what it does without any usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取某患儿完整档案：年龄/体重/CKD 分期/透析/过敏原/地方饮食文化/3 天日记概况。
| Name | Required | Description | Default |
|---|---|---|---|
| patient_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description relies on the verb '获取' to convey a read operation. It discloses the profile's contents but does not address potential nuances like auth requirements, data freshness, or error behavior. Since an output schema exists, return formatting is likely covered elsewhere.
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 entire description is a single, compact sentence with an enumerated list, front-loading the key action ('get complete profile') and using no filler 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?
For a single-parameter read tool with an output schema, the description sufficiently outlines the profile's scope. However, it lacks any note on access restrictions or relationship to other tools, leaving some contextual gaps that annotations might otherwise fill.
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%, and the description only loosely references '某患儿' without elaborating on the patient_id format or requirements. Although the parameter name is self-explanatory, the description provides minimal added semantic value beyond the schema.
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 fetches a complete patient profile and explicitly enumerates the contained data (age, weight, CKD stage, dialysis, allergens, dietary culture, 3-day diary overview), distinguishing it from sibling tools like get_diet_diary or get_labs.
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 use when a holistic patient view is needed, but provides no explicit guidance on when to choose this over sibling tools or any exclusions. It does not mention prerequisites or alternative conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
返回儿童 CKD 营养管理知识卡片（主题可选：限钾/限磷/限钠/蛋白/能量/液体/嘌呤/低蛋白淀粉）。
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the return action without mentioning side effects, error handling, or the fact that the content is general education rather than personalized advice. This is a significant gap for a tool lacking structured 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 a single, front-loaded sentence that states the action and resource, followed by a parenthetical list of valid topics. It is concise and omits any unnecessary 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?
For a simple retrieval tool with an output schema, the description adequately covers the tool's purpose and the only parameter's valid values. However, it does not explicitly mention that the content is educational rather than patient-specific, which could affect an agent's decision-making alongside sibling tools. Overall, it is fairly complete for its simplicity.
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 defines 'topic' as a plain string with no enum, but the description compensates fully by explicitly listing the acceptable topic values. This gives complete semantic meaning beyond the schema, making it clear exactly what input is expected.
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 returns pediatric CKD nutrition management knowledge cards, with a specific verb and resource. The list of selectable topics (限钾/限磷/限钠/蛋白/能量/液体/嘌呤/低蛋白淀粉) further defines its scope and distinguishes it from sibling tools that handle patient-specific data.
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 use for retrieving educational nutrition cards and lists the topic options, but provides no explicit guidance on when to use this versus alternatives like compute_nutrition_targets or search_food. There are no exclusions or alternative suggestions, so usage context is only inferred.
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 |
|---|---|---|---|
| patient_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | 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. The word '列出' naturally implies a read-only operation, but the description does not explicitly state that it does not modify data, nor does it mention permissions or any side effects. It is adequate but minimal for a list operation.
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, front-loaded sentence with no extraneous words. It conveys the verb, resource, and scope efficiently, earning a high score for conciseness.
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 an output schema exists, return details are covered. The description is sufficient for a simple list operation but lacks usage context, such as when to choose this over sibling tools or any implicit filtering behavior. It is minimally complete for the tool's complexity.
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?
With schema description coverage at 0%, the description must compensate. It indirectly references the child patient via '某患儿', but does not explicitly define patient_id's format, constraints, or that it must be an existing patient. This adds marginal value over the schema's bare string type.
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 uses the specific verb '列出' (list) with the resource '已保存的食谱记录' (saved meal plan records) and specifies attributes (日期/能量/蛋白). This clearly distinguishes it from sibling tools like save_meal_plan or generate_meal_plan, though it does not explicitly name an alternative.
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 no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It only states the action, leaving the agent to infer usage from the tool name and parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
列出全部模拟患儿（ID / 姓名 / 年龄 / CKD 分期 / 透析方式 / 饮食模式）。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It states the tool lists 'simulated' patients and enumerates output fields, but it does not explicitly state that the operation is read-only or has no side effects. For a simple list operation, this is minimally adequate, but it omits potential behavioral details such as ordering, pagination, or data source. The term '模拟' adds important context about the data being synthetic, which is helpful.
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, concise sentence that front-loads the action ('List all simulated pediatric patients') and immediately lists the specific output fields. Every word earns its place, with no filler or repetition. It is perfectly sized for the tool's simplicity.
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 tool has no parameters and an output schema exists, the description covers the essential purpose and the return fields. It does not need to detail return values because the output schema provides that structure. It is complete enough for an agent to invoke the tool and interpret the result, though it could benefit from a brief alternative-reference for siblings.
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 per rubric is 4. The description correctly adds no parameter details, and the output field list is not directly related to parameter semantics. Since there are no parameters to explain, the description does not need to compensate for missing schema info, and it does not introduce any confusion.
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 a specific action: '列出全部模拟患儿' (list all simulated pediatric patients), enumerating the exact fields returned (ID, name, age, CKD stage, dialysis modality, diet pattern). This distinguishes it from sibling tools like get_patient_profile (which fetches a single patient) and list_meal_plans (which lists meal plans), leaving no ambiguity about its purpose.
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 use for retrieving a comprehensive list of all patients, but it provides no explicit guidance on when to use this tool versus alternatives. For example, it does not say 'for a single patient's details, use get_patient_profile' or mention any limitations (e.g., no filtering). The usage context is clear from the verb and scope, but without explicit cross-references, the agent may not know when to choose this over sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
把已生成的食谱 JSON 字符串写入 SQLite（plan_json 来自 generate_meal_plan 的原始输出）。
| Name | Required | Description | Default |
|---|---|---|---|
| plan_json | Yes | ||
| patient_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that this is a persistent write operation to SQLite and specifies the expected input format, but it does not explain side effects (e.g., overwriting an existing plan for a patient), required permissions, or error behavior. This is moderate disclosure but lacks depth.
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 sentence that conveys the purpose, the destination, and the data source with no extraneous information. Highly concise and front-loaded.
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 two-parameter write tool with an output schema, the description covers the essential flow (what gets written and where). However, it omits behavior on conflicts (e.g., duplicate patient_id), which is relevant for a persistence operation. The description is adequate but not fully complete.
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 compensate. It explains plan_json as the original output of generate_meal_plan, which adds essential meaning. However, patient_id is left undocumented beyond its name, leaving the agent to infer its role. Partial compensation, not complete.
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: writing a meal plan JSON string to SQLite. It identifies the specific source of the plan_json (raw output from generate_meal_plan), which distinguishes it from siblings like generate_meal_plan (which creates) and list_meal_plans (which reads).
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 after calling generate_meal_plan by specifying that plan_json comes from its raw output. This provides clear context for when to use the tool, but it does not explicitly mention alternatives or exclusions (e.g., 'use list_meal_plans to retrieve saved plans').
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 |
|---|---|---|---|
| top_k | No | ||
| keyword | Yes | ||
| category | No |
| Name | Required | Description |
|---|---|---|
| result | 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 discloses the key output (kidney patient ratings), but does not describe search behavior such as matching rules, result limits, or how optional parameters affect results. It is not misleading, but significant behavioral details remain unspecified.
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 that front-loads the verb and resource. Every word contributes meaning, with no filler or 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?
The description adequately explains the core purpose and output, and an output schema exists to document return values. However, it lacks explanation of the optional parameters and usage context, which is especially important given the absence of schema descriptions. It is minimally viable but has clear gaps.
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 descriptions are 0% covered, and the description only clarifies the 'keyword' parameter through '按名称关键词检索'. The 'top_k' and 'category' parameters are left unexplained, giving the agent no insight into their meaning or effect.
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?
Description clearly states it searches foods by name keyword in the Chinese Food Composition Table and returns kidney patient ratings (potassium/phosphorus/sodium/purine). The verb '检索' (search) plus specific resource and output makes the purpose unambiguous and distinguishes it from other food-related tools.
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?
No guidance is provided on when to use this tool versus alternatives like get_food_profile or get_alternatives. The description only states what it does, not the context or conditions under which it should be chosen over sibling tools.
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.
v1.0.0analyze_diet_diarycompute_nutrition_targetsgenerate_meal_planget_alternativesget_diet_diaryget_food_profileget_labsget_patient_profileknowledge_cardlist_meal_planslist_patientssave_meal_plansearch_foodScored across 13 tools
Most tools have clearly distinct purposes: fetching diary data, analyzing it, generating plans, and managing food data are well separated. However, generate_meal_plan already writes to SQLite while save_meal_plan also writes the same generated plan, creating potential ambiguity about when to use each.
The vast majority of tools follow a consistent verb_noun pattern (e.g., get_patient_profile, search_food, list_meal_plans). The lone exception is knowledge_card, which is a noun without a verb, breaking the pattern slightly.
With 13 tools, the set is well-scoped for a specialized CKD meal-planning domain. Each tool addresses a specific need from patient data retrieval to meal plan generation and food lookup, without excessive fragmentation or bloat.
The server covers the core workflow: patient profiles, lab values, diary analysis, nutrition targets, meal plan generation/saving/listing, and food database queries. Minor gaps include lack of a tool to retrieve the full details of a saved meal plan (list only gives summaries) and no update/delete operations for plans.
Unlock the power of food transparency with our Open Food Facts MCP server. Easily look up any food
MCP server exposing supplements database used by iNutriPlan.com
MCP server for US nursing facility search and ownership lookup (NursingHomeDatabase).
MCP tools for Malawian food search, clinical nutrition calculators, and RAG-backed guidance.
