A
licenseA
qualityB
maintenanceGenerates personalized 7-day meal plans based on user profile and goals, and provides daily calorie catch-up suggestions when intake falls short.
6
1
MIT
a207-meal-plan-mcp
by ayeyouok
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., "@a207-meal-plan-mcpGenerate a 3-day CKD meal plan for a 7-year-old meeting PRNT targets"
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.
a207-meal-plan-mcp（M7 · 食谱生成）
儿童 CKD 食谱生成 MCP（营养师可调）。按 M3 的 PRNT 目标（能量/蛋白/钾/磷/钠）生成多日食谱（3 餐 + 加餐），并给出每项目标的达成率。纯计算、无跨包依赖。
工具清单
工具 | 读写 | 调用方 | 说明 |
| 读 | 营养师 | 按 PRNT 目标生成多日食谱 + 达成率 |
| 读 | 营养师 | 从已生成 plan 重新汇总平均每日营养素（校验） |
Related MCP server: ckd-meal-plan-mcp
输入来源
目标值（能量/蛋白/钾/磷/钠）来自 M3
calc_prnt_targets。食物数据：本包内置
data/foods_ckd.json（CKD 适宜食物子集，约 40 项）。
集成说明（重要）：为满足「零跨包 import」工程纪律，M7 不调用 M5。生产环境应将内置子集替换为调用 M5
lookup_food_nutrients（1752 食物库）实时取数，使食谱养分与 M5 单一事实源一致。本内置子集数值为常见食物成分近似值，仅供离线演示。
回写约定
生成的食谱条目养分须经 M5 计算后，通过 M3 upsert_food_diary 回写 diet_diary_3d，才能被 M3 assess_intake_vs_target 校验（D 约定见 docs/05）。
运行与部署
与其他 4 个 MCP 一致，发 PyPI 后裸 uvx 可用：
python -m build
python -m twine check dist/*
python -m twine upload dist/* # 用同一个 NFYY 凭据
uvx --refresh a207-meal-plan-mcp测试
python tests/test_tools.py已知缺口（非阻断）
生成策略为确定性启发式（主食供 50% 能量、蛋白源供 70% 蛋白、蔬果固定 100g、油脂补能），非多目标优化求解；多样化仅通过每日轮换食物实现。
未做「食物相克 / 口味偏好 / 烹饪方式」约束，后续可由营养师 Skill 叠加。
未内嵌 M5 全量食物库（见上方集成说明）。
Available Tools
2 toolsgenerate_meal_planA
按 PRNT 目标生成多日食谱（3 餐 + 加餐），返回餐次明细、每日汇总与达成率。营养师调用。
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| vegetarian | No | ||
| target_k_mg | Yes | ||
| target_p_mg | Yes | ||
| target_na_mg | Yes | ||
| exclude_foods | No | ||
| target_protein_g | Yes | ||
| target_energy_kcal | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.6/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It does reveal important output details (meal items, daily totals, achievement rates), but it omits any mention of side effects, data persistence, or authorization requirements. There is no contradiction, but the disclosure is only partial.
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 a single, front-loaded sentence that communicates the main purpose, output, and intended audience without any filler. Every phrase carries meaningful information, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Since an output schema exists, the description does not need to enumerate return fields, but it does mention them briefly. However, with 8 parameters and no guidance on how they interrelate or when to set them, the description is only partially complete. It captures the core scenario but leaves parameter handling unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description does not describe any of the 8 parameters. It only loosely alludes to goals via 'PRNT' and to duration via 'multi-day', which does not compensate for the missing parameter semantics. For a tool with 5 required numeric targets and several optional fields, this is inadequate.
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 generates a multi-day meal plan according to PRNT goals, including 3 meals plus snacks, and specifies the output components (meal details, daily summary, achievement rate). This distinguishes it from the sibling tool get_meal_plan_nutrients, which suggests retrieval rather than generation.
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 phrase '营养师调用' indicates the intended user (nutritionists), but there is no explicit guidance on when to use this tool versus alternatives. It implies usage for meal plan generation but lacks exclusions, conditions, or comparisons with get_meal_plan_nutrients.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_meal_plan_nutrientsA
从已生成 plan 重新汇总整体平均每日营养素（校验用）。
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| plan | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4/5.0
Behavior3/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 a read-only recomputation ('重新汇总') and validation intent, which implies no side effects, but it does not disclose potential error handling, behavior on malformed plans, or whether any data is persisted. The basic behavior is clear but not deeply detailed.
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 a single, concise sentence in Chinese that front-loads the action and purpose with no filler or redundant information. Every word contributes meaning.
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 tool's simplicity (one parameter, output schema provided) and the sibling context, the description covers the essential purpose, input, and validation intent. The output schema handles return format, so the description doesn't need to explain it. Minor gaps remain around edge cases, but overall it is sufficiently complete for this 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?
The schema has one 'plan' parameter with zero description coverage. The description compensates by identifying the parameter as the generated plan, but it does not explain the required structure or constraints beyond the schema's object type. Since the plan is likely complex and well-known from the sibling tool, this partial clarification is adequate but not comprehensive.
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 re-aggregates overall average daily nutrients from an already-generated plan for validation purposes. The verb '重新汇总' (re-aggregate) and resource 'plan' are specific, and the mention of '已生成 plan' (already-generated plan) distinguishes it from the sibling tool generate_meal_plan.
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 indicates the tool is meant for use after a plan has been generated, with the explicit intent of validation. This implies when to use it (post-generation) as opposed to generating a new plan, but it does not explicitly state when not to use it or list alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v0.1.0- First observed
generate_meal_plan - First observed
get_meal_plan_nutrients
TDQS
A3.8/5.0
Scored across 2 tools
Disambiguation5/5
The two tools have clearly distinct purposes: one generates a new meal plan, the other aggregates nutrient data from an existing plan. There is no overlap or ambiguity between them.
Naming Consistency5/5
Both tools follow a consistent verb_noun pattern: 'generate_meal_plan' and 'get_meal_plan_nutrients'. The naming style is uniform and predictable.
Tool Count3/5
With only 2 tools, the server feels minimal. While the narrow scope is defensible, it sits at the borderline where 1-2 tools are typically considered thin for a functional domain.
Completeness3/5
The tool surface covers generation and nutrient validation, but lacks update/delete/list operations for meal plans. There are notable gaps in lifecycle management, though the core generation workflow is present.
Maintenance
ActivityMaintained
ResponsivenessSyncing
Related MCP Connectors
Patient, meal plan, prescription, chart and anthropometry management for dietitians.
AI meal plans that fill your Kroger/Instacart cart - pantry-aware lists, all from chat.
Patient, prescription, anthropometry, scheduling, chat and food diary management for dietitians.
Evidence-based plant-based food-as-medicine protocols for 47 chronic conditions. ACLM-aligned.
Related MCP Servers
- AlicenseAqualityBmaintenanceThis MCP server generates individualized meal plans for children with chronic kidney disease (CKD) based on KDIGO 2024/PRNT 2020/KRCP 2025 guidelines, incorporating patient age, CKD stage, allergies, dietary culture, and diet diary analysis. It provides deterministic nutrient computations and tools for meal plan generation, food database lookup, and risk analysis.13MIT
- AlicenseAqualityCmaintenanceProvides deterministic parental guidance for children with chronic kidney disease, including food safety checks, lab report interpretation, and nutrient-aware food substitutions based on authoritative guidelines and the Chinese Food Composition Table.12MIT
- FlicenseAqualityBmaintenanceMCP server for pediatric CKD nutrition and food calculations, enabling energy/protein targets, food nutrient lookup, substitutions, meal summaries, and drug-nutrient interaction checks.8-