ckd-meal-plan-mcp

by rpint

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
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.
Naming Consistency4/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3.7/5 across 13 of 13 tools scored. Lowest: 3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters1/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's 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.
Usage Guidelines2/5
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.
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. 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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
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 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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's 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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
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 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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline 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.
Purpose5/5
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.
Usage Guidelines3/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![ckd-meal-plan-mcp MCP server](https://glama.ai/mcp/servers/rpint/ckd-meal-plan-mcp/badges/card.svg)](https://glama.ai/mcp/servers/rpint/ckd-meal-plan-mcp)

Score Badge

Copy to your README.md:

[![ckd-meal-plan-mcp MCP server](https://glama.ai/mcp/servers/rpint/ckd-meal-plan-mcp/badges/score.svg)](https://glama.ai/mcp/servers/rpint/ckd-meal-plan-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/rpint/ckd-meal-plan-mcp'

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