This server provides specialized nutrition and food calculation tools for managing pediatric Chronic Kidney Disease (CKD). Capabilities include:
Food Nutrient Lookup: Query energy, protein, potassium, phosphorus, sodium per 100g and portion, with cooking adjustments and alerts for high levels.
Food Substitution: Recommend alternative foods from same category with constraints (e.g., low potassium, low phosphorus).
Household Measure Conversion: Convert between grams and household measures (bowl, palm, spoon) with nutrient content.
Dietary Intake Summary: Aggregate multi-day intake, compare against targets, and provide achievement rates and recommendations.
Phosphorus-to-Protein Ratio: Calculate mg phosphorus per gram protein to select low-phosphorus protein sources.
Peritoneal Dialysis Glucose Absorption: Estimate glucose absorbed from PD and its caloric contribution.
Drug-Nutrient Interaction Check: Alert on interactions between CKD medications (binders, vitamin D, diuretics, steroids, iron) and nutrients.
Nutrition Target Calculation (where available): Compute daily energy and protein targets for children with CKD according to PRNT 2020, adjusting for dialysis and edema.
Click on "Install 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-nutrition-calc-mcp Calculate daily energy and protein targets for a 4-year-old CKD patient, 16 kg."
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）营养与食物计算 MCP 包，供 CKDNutri 项目的医生、营养师、家长三类智能体共用（M5 营养/食物计算器）。
依据：PRNT 2020（儿童 CKD 能量与蛋白 SDI）、Schofield 方程、腹膜透析葡萄糖吸收折算。
注意：本包不提供目标计算（原
calc_nutrition_target已去重，目标计算统一由 M3calc_prnt_targets作为唯一权威引擎）。本包定位为纯食物层（查养分/份量换算/替换/磷蛋白比/腹透葡萄糖/药食交互）。
能量：kcal；蛋白/钾/磷/钠：g 或 mg（食物成分表以 mg/100g 计）；血电解质：mmol/L
体重：kg；身高：cm；年龄：岁（内部按月龄插值）
Related MCP server: usda-fdc-mcp
工具 | 说明 |
| 食物营养素查询，支持份量（碗/个/掌心/克）与烹饪降钾降磷处理，返回高钾/高磷/高钠警示 |
| 食物替换：低钾 / 低磷 / 低钠 / 低蛋白 / 等能量，优先同类食物候选 |
| 克 ↔ 家庭量具双向换算，附家长可感知锚点（鸡蛋/掌心瘦肉/牛奶/瓷勺油/碗饭） |
| 多日饮食汇总，对比目标给出能量/蛋白达成率与钾磷钠来源排序及建议 |
| 磷蛋白比（mg P/g 蛋白）计算，辅助低磷食物优选 |
| 腹膜透析葡萄糖吸收量（按留腹时长 × 转运特性），折算 kcal |
| 药物-营养素交互提示（磷结合剂、活性维 D、利尿剂、激素、铁剂等） |
a207-nutrition-calc-mcp/
├── pyproject.toml
├── README.md
├── src/a207_nutrition_calc_mcp/
│ ├── __init__.py
│ ├── core.py # 7 工具门面（纯逻辑，无 MCP/pydantic 依赖）
│ ├── server.py # FastMCP >=2 服务定义（8 个 @mcp.tool）
│ ├── models.py # pydantic v2 入参模型（extra=forbid）
│ ├── constants.py # 参考表与阈值
│ ├── targets.py # 腹透葡萄糖吸收折算（目标计算已收归 M3）
│ ├── fooddb.py # 食物数据访问与分级
│ ├── measures.py # 家庭量具解析
│ ├── foods.py # 查询/替换/换算/磷蛋白比
│ ├── diary.py # 饮食汇总
│ ├── pharma.py # 药物-营养素交互
│ └── data/food_data.csv
└── tests/test_tools.py不依赖、不 import 任何其它 a207-* 包（纯计算，无写权限）
结果可解释：返回 guideline 引用与规则依据
仅正向/边界/超时分支齐全，错误以 {"ok": false, "error": ...} 形式返回
# 编译（server.py/models.py 依赖 fastmcp/pydantic，仅做语法校验）
python -m py_compile src/a207_nutrition_calc_mcp/*.py
# 纯标准库自测（core 逻辑不依赖 fastmcp/pydantic，可独立运行）
python tests/test_tools.py返回非零退出码表示存在失败用例。
pip install -e .
python -m a207_nutrition_calc_mcp.server
# 或
fastmcp dev src/a207_nutrition_calc_mcp/server.py
# 或（已注册 console script 后）
uvx --from . a207-nutrition-calc-mcp按 PRNT 2020 计算儿童 CKD 每日能量与蛋白质目标（含透析加成与水肿体重校正）。
| Name | Required | Description | Default |
|---|---|---|---|
| age | Yes | ||
| sex | No | M | |
| dialysis | No | none | |
| is_edema | No | ||
| ckd_stage | Yes | ||
| height_cm | Yes | ||
| weight_kg | Yes | ||
| growth_status | No | normal | |
| pd_glucose_kcal_per_day | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It does add useful context about dialysis add-on and edema weight correction, which indicates how parameters affect the calculation. However, it does not state whether the tool is read-only, deterministic, or how it handles invalid inputs, leaving some behavioral traits 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, front-loaded sentence that efficiently captures the target population, standard, and key adjustments. No redundant words; 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?
Despite the output schema covering return values, the tool has 9 parameters with zero documentation in the schema. A one-sentence description cannot adequately guide an agent on how to correctly set parameters like growth_status or pd_glucose_kcal_per_day. It is underspecified 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?
Schema description coverage is 0% for 9 parameters. The description only implies that dialysis and edema-related parameters are relevant, but gives no guidance on units, allowed values, or the role of growth_status and pd_glucose_kcal_per_day. This is insufficient compensation for completely undocumented parameters.
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 it calculates daily energy and protein targets for children with CKD per PRNT 2020, and explicitly mentions dialysis add-on and edema body weight corrections. This is a specific verb+resource combination that distinguishes it from sibling tools like calc_pnpr or calc_pd_glucose_absorption.
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 clear context: use for pediatric CKD patients requiring PRNT 2020-based nutrition targets. However, it does not explicitly state when not to use it or mention alternative tools, so it stops short of full exclusionary guidance.
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 |
|---|---|---|---|
| weight_kg | No | ||
| dwell_hours | Yes | ||
| transport_type | No | average | |
| exchanges_per_day | No | ||
| dialysate_glucose_g | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 does note the key behavior that the result is to be subtracted from the dietary energy goal, but it fails to disclose how inputs like transport_type or exchanges_per_day affect the calculation, any assumptions, or what the output represents beyond the deduction.
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 redundant wording, making it highly concise. However, its brevity comes at the cost of clarity for a tool with multiple parameters and defaults, so it is not ideal but still avoids fluff.
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 five parameters, two required, and no annotations, a one-line description is insufficient. It provides a clue about its role (deducting from dietary energy) but does not explain the workflow, parameter dependencies, or how it integrates with sibling tools, leaving significant gaps for an agent attempting to invoke it correctly.
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 0% description coverage for parameters, yet the description does not mention any parameter names or explain how they influence the result. It only references the overall concept of glucose absorption, leaving all five parameters completely unexplained.
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 estimates peritoneal dialysis glucose absorption and the associated extra energy, explicitly noting it should be deducted from the dietary energy target. This specific verb-resource pairing distinguishes it from sibling tools like calc_nutrition_target, which focuses on overall nutrition goals.
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 its use when calculating dietary energy targets for patients on peritoneal dialysis, since the estimated energy must be deducted. However, it does not explicitly state when to use this tool over alternatives or provide exclusions, leaving the usage guidance implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
计算磷蛋白比（mg 磷 / g 蛋白），用于限磷时挑选蛋白来源。
| Name | Required | Description | Default |
|---|---|---|---|
| food | No | ||
| grams | No | ||
| protein_g | No | ||
| phosphorus_mg | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains the output calculation but does not disclose how inputs are handled—e.g., what happens if 'food' vs. 'protein_g'/'phosphorus_mg' is given, whether it looks up nutrients, or how missing values are treated. This is a significant transparency gap for a tool with multiple optional parameters.
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 immediately states the calculation and its purpose. Every word earns its place; there is no redundancy or filler.
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 4 parameters, no annotations, and no schema descriptions, the description is insufficiently complete. It does not explain how the parameters interact, what 'food' expects, or the behavior when only some parameters are provided. Although an output schema exists, the input ambiguity remains unresolved, making this a minimally viable but gap-filled 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 description coverage is 0%, so the description must compensate for explaining parameters. While the formula implies protein_g and phosphorus_mg are numerator/denominator, it does not explain the roles of 'food' and 'grams', units, or defaults. The description adds minimal value over the bare schema, leaving the agent guessing about how to invoke the tool correctly.
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 calculates a phosphorus-protein ratio with the formula 'mg 磷 / g 蛋白' and specifies a use case ('用于限磷时挑选蛋白来源'). This is a specific verb+resource+scope, and the tool's purpose is distinct from siblings like lookup_food_nutrients or calc_nutrition_target. However, it does not explicitly differentiate itself from alternatives, so it stops short of a 5.
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 clear context for when to use the tool ('when restricting phosphorus to choose protein sources'). It does not mention alternative tools or when not to use it, so it lacks the 'when-not' guidance required for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查询药物与营养素的交互提示（磷结合剂、钾结合剂、活性维D、激素等）。
| Name | Required | Description | Default |
|---|---|---|---|
| drug | Yes | ||
| nutrient | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 query purpose and examples, but does not disclose output format, error handling, input constraints, or whether it is a read-only operation. The 'query' verb implies read-only, but this is not confirmed.
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 efficiently communicates the core purpose with no redundancy. Every word contributes to meaning.
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 gives a clear basic purpose and examples, but lacks usage guidance and parameter semantics. The presence of an output schema may cover return values, but the description is minimal for a tool with no annotations and no parameter descriptions, leaving gaps for correct 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?
Schema description coverage is 0%, so the description must compensate. It references 'drug' and 'nutrient' but does not clarify that 'drug' is required, 'nutrient' is optional (with default null), or acceptable value formats. The examples of drug categories provide some context but are insufficient for full parameter understanding.
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 action ('查询' / query) and resource ('药物与营养素的交互提示' / drug-nutrient interaction alerts), with specific examples of drug categories (phosphate binders, potassium binders, activated vitamin D, hormones). This distinguishes it from sibling nutrition/food 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 explicit guidance on when to use this tool versus alternatives. Although sibling tools are all nutrition/food-related, the description does not state exclusions, prerequisites, or scenarios where this tool should be preferred.
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 |
|---|---|---|---|
| food | Yes | ||
| grams | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only mentions the conversion and nutrient attachment, but does not disclose whether the conversion is approximate, requires a known food database, or imposes input constraints. This is a minimal behavioral 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 a single sentence with no fluff, front-loading the conversion purpose before mentioning the nutrient attachment. It is appropriately 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?
The description is minimal; the output schema likely covers return format, but the description lacks input prerequisites, usage context, and any caveats about approximations. For a simple 2-param tool, this is incomplete.
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%, so the description must compensate. It mentions grams ('克重') and the resulting portion, but does not define what 'food' should be or any constraints on the grams value. Parameter meanings are only partially conveyed.
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 converts gram weights to household measures (half bowl, palm, spoon) and attaches nutrient information for that portion. This specific verb-resource pairing distinguishes it from sibling tools like lookup_food_nutrients or sum_diet_intake.
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 conversion to household measures is needed, but it does not explicitly state when to use this over alternatives or mention any exclusions. No sibling tools are referenced, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查询食物每 100 g 与指定份量的能量/蛋白/钾/磷/钠，并给出高钾高磷警示。
| Name | Required | Description | Default |
|---|---|---|---|
| food | Yes | ||
| cooking | No | ||
| portion | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 warning behavior (high potassium/phosphate alerts) and the dual portion scope, but does not mention error handling, validation, or explicitly confirm read-only nature. Some behavioral context is provided, but it is not comprehensive.
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 efficiently conveys the tool's purpose and unique warning feature. Every word serves a purpose, with no redundant or filler content.
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 exists, so return value details are covered. However, the description lacks clarification for the 'cooking' parameter and provides no usage guidance relative to siblings. For a tool with moderate complexity and no annotations, the description is adequate 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 description coverage is 0%, so the description must compensate. It clarifies the 'portion' parameter by mentioning '指定份量' (specified portion), but the 'cooking' parameter is entirely unexplained, and no value formats or examples are given. This partial coverage is insufficient for full parameter understanding.
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 lookup action ('查询') targeting food nutrients (energy, protein, potassium, phosphorus, sodium) per 100g and specified portion, with an additional warning output. This distinguishes it from sibling tools that focus on calculations, substitutions, conversions, or interactions.
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 its use for retrieving nutrient information with high K/P warnings, but it does not explicitly state when to prefer this tool over alternatives. No exclusions or comparative guidance is provided, leaving the agent to infer based on the tool's name and sibling names.
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 |
|---|---|---|---|
| food | Yes | ||
| top_n | No | ||
| constraint | No | 低钾 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the core behavior (recommend replacements) but does not explicitly mention read-only nature, output format, ranking logic, or any limitations. It adds some context beyond the name but remains basic.
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, well-structured sentence in Chinese that packs the essential elements: constraint types, comparison scope, and action. No fluff or repetition, every part 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?
The description is concise yet sufficient for a simple 3-parameter tool. An output schema exists, so return values are covered elsewhere. It provides enough context for the main purpose and the constraint parameter, though it omits details about top_n and edge cases. Given the tool's simplicity, completeness is above minimum.
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%, so the description must compensate. It explains the 'constraint' parameter by listing example constraints (low potassium, low phosphorus, etc.) and clarifies 'food' is a similar-category item. However, 'top_n' is not explained, leaving its meaning (number of recommendations) implicit from its name and default. Partial compensation only.
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 recommends replacement options (替换方案) among similar foods (同类食物) under specific dietary constraints (低钾/低磷/低钠/低蛋白/等能量). This is a specific verb+resource+scope. It distinguishes from sibling tools that calculate targets or look up nutrients, as it focuses on substitutions.
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 user needs a food substitute under a health constraint, but it does not explicitly state when to prefer this tool over alternatives or provide exclusions. It lacks direct comparison with sibling tools like lookup_food_nutrients or calc_nutrition_target, so guidance is only implicit.
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 |
|---|---|---|---|
| diary | Yes | ||
| target | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It clearly states what the tool computes (aggregates nutrients, compares to targets, provides achievement rates and suggestions) but does not mention whether it is read-only, how missing data is handled, or any limitations. This is adequate but leaves 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, compact sentence that conveys the essential purpose and outputs without redundancy. Every phrase contributes valuable information.
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's moderate complexity and the presence of an output schema, the description sufficiently covers the main behavior: summarizing multiple days, comparing to target, and giving actionable results. However, it lacks explicit input format details and usage context, so it is not fully complete for an agent needing to construct a correct request.
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 0% description coverage, and the description only implicitly maps 'diary' to the multi-day diet diary and 'target' to the target object. It adds meaning by listing the nutrients involved, but does not explain the structure of diary items or target fields, which are needed for actual invocation.
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: aggregating energy/protein/potassium/phosphorus/sodium from a multi-day diet diary and comparing against targets to produce achievement rates and action suggestions. It uses a specific verb ('汇总' / summarize) and resource ('多日饮食日记' / multi-day diet diary), and is clearly distinguished from sibling tools like lookup_food_nutrients or calc_nutrition_target.
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 when to use the tool: when you have a multi-day diet diary and need a summary of key nutrients with target comparison. It does not explicitly mention alternatives or exclusions, but the context is clear enough for an agent to select it over lookup or substitution tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool serves a distinct purpose: target calculation, food lookup, substitution, measure conversion, intake summation, phosphorus ratio, dialysis glucose absorption, and drug interaction checking. There is no overlap or ambiguity between tool functions.
All tool names follow a consistent snake_case verb_noun pattern (e.g., calc_nutrition_target, lookup_food_nutrients, substitute_food). The verbs are descriptive and uniform, making the toolset predictable and easy to navigate.
With 8 tools, the server is well-scoped for its domain of pediatric CKD nutrition. Each tool adds meaningful functionality without redundancy, covering the essential calculators and data lookups needed for clinical and dietary management.
The toolset covers the full workflow: setting nutrition targets, looking up and substituting foods, converting measurements, summing intake against targets, and addressing special considerations like PD glucose absorption and drug interactions. No obvious gaps exist for the stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP tools for Malawian food search, clinical nutrition calculators, and RAG-backed guidance.
MCP server for US nursing facility search and ownership lookup (NursingHomeDatabase).
MCP server exposing supplements database used by iNutriPlan.com
Unlock the power of food transparency with our Open Food Facts MCP server. Easily look up any food
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ayeyouok/a207-nutrition-calc-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
