Meal Planner MCP

by illinigirl

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: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose: adding recipes (single, bulk, CSV import), listing/getting recipes, planning (plan_week, swap_meal, remove_meal), generating shopping lists, exporting, and logging cooked meals. No two tools overlap in function.
Naming Consistency5/5
All tool names use a consistent snake_case verb_noun pattern (e.g., add_recipe, export_plan, record_cooked). The verbs are meaningful and predictably describe the action. No naming convention violations.
Tool Count5/5
14 tools cover the full meal planning workflow without being excessive. Each tool serves a specific need, from recipe management to weekly planning and shopping list generation.
Completeness3/5
Core planning operations are present, but there are gaps: no tool to update or delete user-added recipes (only add and read). This is a notable missing feature for a recipe library, though the planning cycle itself is complete.
Average 3.8/5 across 14 of 14 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 17 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

Behavior1/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 does not state what happens when no plan exists (e.g., returns null or throws error), nor any side effects. The description is too minimal to provide meaningful transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using only one short phrase. It is front-loaded with the key information. While it could include more detail, it earns its place by being directly informative for a simple retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no complexities (0 params, no output schema, no annotations), the description lacks completeness. It does not explain the return value's structure or content (e.g., meal plan details), nor potential edge cases. A user cannot fully understand what to expect.
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?
There are zero parameters, and schema coverage is 100% trivially. The description does not need to add parameter details. It provides adequate context that the tool requires no inputs.
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 'The currently saved plan, if any' clearly indicates that the tool retrieves a saved plan, and the name 'get_current_plan' reinforces this. It is specific enough to distinguish from sibling tools like 'plan_week' or 'export_plan', though it does not explicitly differentiate.
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, nor any prerequisites or context. For example, it does not clarify if a plan must exist or if this tool should be used before generating a shopping list.
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?
The description discloses that ingredients are parsed into structured amounts for shopping-list math, and that setting 'course' affects planning. Since no annotations are provided, the description carries the full burden, but it does not mention whether the operation is safe, reversible, or has any side effects beyond saving. This is adequate for a simple creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at about four lines, with the main purpose front-loaded. Every sentence adds value, though 'the everyday way to seed it' is slightly informal but acceptable. No unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters and no output schema, the description should hint at the return value or success confirmation. It only says 'Save one recipe to your library' without mentioning what the agent should expect after invocation. Error conditions are also absent.
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?
With 0% schema description coverage, the description must compensate. It explains two critical parameters: 'ingredients' (format and parsing) and 'course' (influence on planning). It also mentions 'servings' default. However, other parameters like 'tags', 'cuisine', 'directions', and 'total_time_min' receive no explanation.
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 clearly states the tool's verb and resource: 'Save one recipe to your library'. It distinguishes from siblings by implying this is for adding a single recipe ('the everyday way to seed it'), while a sibling named 'add_recipes' likely handles bulk addition. However, it does not explicitly contrast with alternatives.
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 says 'No file or special format needed: paste or describe a recipe', suggesting it is for simple, manual input. But it provides no explicit guidance on when to use this tool versus siblings like 'add_recipes' (which may handle bulk imports). No when-not scenarios are mentioned.
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?
No annotations provided, so description must disclose all behavioral traits. Only states it returns 'full detail' including ingredients, but does not mention any side effects, authentication requirements, rate limits, or what 'full detail' entails beyond ingredients. Minimal behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 9 words is highly concise. Front-loaded with key action and scope. However, it is too brief and could benefit from additional structure or details without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and minimal annotations, description should provide more details about return value structure or behavior. Merely stating 'full detail' and 'ingredient list' is insufficient for an agent to fully understand the output. Lacks completeness for a simple retrieval tool.
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 has one required string parameter 'recipe_id' with 0% description coverage. Description does not explain the parameter, its format, or how to obtain it. The tool name implies the parameter is a recipe identifier, but no explicit semantics added.
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 the tool retrieves full detail for one recipe, including ingredient list. Verb 'get' and resource 'recipe' are specific. Distinguishes from siblings like 'list_recipes' (which returns multiple) and 'suggest_recipes' (which suggests based on criteria).
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?
No explicit when-to-use or when-not-to-use guidance. Implicitly, it is for retrieving details of a single recipe, as opposed to listing or suggesting. However, no alternatives mentioned, and no context on when to choose this over other recipe-related 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?
No annotations are provided, so the description must fully disclose behavioral traits. It states that the date remains as an unplanned slot after clearing, which is helpful. However, it does not mention if the operation is reversible, if it requires specific permissions, or what happens if the date does not exist in the plan.
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 two sentences, front-loaded with the core action, and contains no superfluous information. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is incomplete for a tool with a single required parameter that likely expects a specific date format. It also does not clarify behavior for invalid or missing dates, leaving the agent uncertain about edge cases.
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 only parameter 'date' lacks any format or example in the description. With 0% schema description coverage, the description should have specified the expected date format (e.g., ISO 8601) to ensure correct usage. This is a significant 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's function: clearing one day's meal from the current plan, leaving it unplanned. The verb 'clear' and resource 'one day of the current plan' are specific, and it distinguishes from siblings like 'swap_meal' or 'add_recipe' which modify or add rather than remove.
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 provides context hints ('eating out, skipping') suggesting when to use, but does not explicitly contrast with alternatives like 'swap_meal' or specify when not to use. The scenarios are implied rather than stated as guidance.
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 does not mention that the tool is read-only, nor does it describe any side effects, pagination, ordering, or rate limits. The description only states the basic function, missing critical 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 extremely concise: two sentences plus a parameter list. No unnecessary words, and the key information is front-loaded. Every sentence earns its place.
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 the tool has no output schema, the description should ideally mention what is returned (e.g., list of recipe IDs or full objects). This is missing. However, with only two optional params and a simple purpose, the description covers the essential usage adequately.
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?
Schema description coverage is 0%, so the description must add meaning. It clearly describes both parameters: 'tag' as an optional filter (with examples) and 'max_time' as max total time in minutes. This adds significant clarity beyond the bare schema properties.
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 explicitly states the tool lists recipes from the library (bundled seed + imported/added), clearly distinguishing it from siblings like get_recipe (single recipe) or add_recipe (adding). The verb 'list' is specific and the scope is well-defined.
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 for listing and filtering recipes via optional parameters, but it does not explicitly state when to use this tool over alternatives like suggest_recipes or get_current_plan. No 'when not to use' or alternative recommendations are provided, leaving the agent to infer context from sibling names.
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. It adds context about cross-session memory and avoid-repeats but does not disclose idempotency, side effects on other data, or whether it overwrites previous logs.
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?
Two concise sentences with no wasted words. The second sentence adds valuable context about cross-session capability.
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 logging tool with 2 params and no output schema, the description covers purpose and behavioral context. Could mention return value but acceptable.
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%. The description mentions 'defaults to today' for on_date but does not explain recipe_id. The schema default is null, not today, which may be misleading. Minimal addition beyond 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?
Description clearly states the action (log cooking), the resource (recipe), and default behavior (today). It also distinguishes by mentioning cross-session memory and avoid-repeats, differentiating it from sibling tools.
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 after cooking a recipe but lacks explicit guidance on when not to use or alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Explains key behaviors: saves as current plan, reuses leftovers, avoids recently-cooked recipes, optimizes overlap and diversity. Does not mention overwriting behavior but implies it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear paragraphs, front-loads main purpose. Detailed but not verbose. Could be slightly more concise but effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has 9 parameters, no output schema, no annotations. Description leaves many parameters unexplained (7/9). No mention of return value or success behavior.
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 coverage is 0%. Only main_course_only and diversity_weight are explained in detail. Other 7 parameters (days, max_time, start_date, exclude_tags, include_tags, household_size, avoid_recent_days) are not described.
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?
Clearly states 'Build and save a meal plan' with specific optimization goals (ingredient overlap, leftovers). Distinguishes from sibling tools like swap_meal, remove_meal, generate_shopping_list, export_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?
Explicitly describes when to use (build and save a meal plan) and mentions alternatives for tweaking (swap_meal, remove_meal) or re-calling. Lacks explicit 'when not to use' but context is clear.
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, so description carries full burden. It discloses the action (recategorize) and a key constraint (seed recipes read-only). However, it doesn't describe error behavior or side effects beyond the scope.
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?
Two concise sentences with no wasted words. Main action is front-loaded, and additional context follows efficiently.
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 mutation with no output schema, the description covers the primary use and constraints. Missing return value info but acceptable given tool simplicity.
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 coverage is 0%, but description does not elaborate on individual parameters. 'recipe_id' and 'course' are mentioned only in context, lacking specific format, allowed values, or examples.
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 uses specific verb 'Recategorize' and resource 'recipe's course', with a concrete use case ('curation for imports that came in uncategorized'). Clearly distinguishes from sibling tools like import_recipes or list_recipes.
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?
Explicitly states when to use: for own or imported recipes that need categorization. Also specifies constraint: seed recipes are read-only. Could mention alternatives but overall clear.
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 full burden. It discloses that the tool accesses the user's private library and filters results, but does not detail rate limits, authentication, or what happens on empty results. Adequate but could be more explicit.
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?
Two efficient sentences with no wasted words. Front-loaded with the core purpose immediately, followed by qualifications. Every sentence 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?
Given the tool has 4 optional parameters, no output schema, and no annotations, the description provides good context about source (user's library) and filtering. Could mention behavior on no matches or return format, but overall sufficient for a suggestion 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?
Schema coverage is 0% (no descriptions). The description mentions filtering by time/tags/ingredients, which maps to the parameters, but does not specify formats (e.g., units for max_time, tag format). Minimal added value beyond the parameter names.
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 verb 'suggest' and resource 'recipes from YOUR library', and distinguishes it from base Claude's inability to see the library. It also frames it as the grounding step before planning a week, providing strong purpose clarity.
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?
It explicitly guides use as the grounding step before deciding a week and notes it returns recipes from the user's library (contrasting with base Claude). While it doesn't explicitly state when not to use or name alternatives, the context is sufficient for appropriate selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that writing occurs to a known location under MEAL_PLANNER_DATA_DIR, not the process cwd, and that content is always returned. This is good transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a bullet for format, front-loads the main action, and is mostly concise. A minor reduction for slight verbosity but still effective.
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 tool with two optional parameters and no output schema, the description covers side effects (file writing), default behavior, and return value. It lacks edge cases or error handling, but is sufficient for this simple export tool.
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?
Schema coverage is 0%, but the description adds meaning: it explains the 'format' parameter values ('markdown' vs 'text') and their effects, and clarifies that 'path' is optional with default behavior. It compensates well for the lack of schema descriptions.
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 writes the current plan and shopping list and returns rendered content inline. This distinguishes it from siblings like 'get_current_plan' and 'generate_shopping_list'.
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 explains the format parameter and default path behavior, implying when to use the tool. However, it does not explicitly mention when not to use it or provide alternatives, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the output is deterministic and not LLM-generated, and that leftover nights add nothing. However, it does not mention potential error states (e.g., no current plan) or output format, and no annotations are provided.
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 two sentences long, front-loaded with the core purpose, and every sentence adds value without 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?
The description covers the tool's core functionality and behavioral traits adequately for a parameterless tool. It does not explain prerequisites like having a plan, but that is implied by 'current plan' and sibling tool context.
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?
There are no parameters, and schema coverage is 100%. The baseline for zero parameters is 4, and the description does not need to add parameter info.
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 that the tool generates a consolidated shopping list for the current plan, merging and scaling ingredients across cook days. It distinguishes itself from sibling tools that deal with recipes, planning, or exporting.
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 planning is done, but lacks explicit when-to-use or when-not-to-use guidance or alternatives. The context suggests it is used when a shopping list is needed, which is reasonably clear.
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 exist, so the description carries the full burden. It discloses that the tool 'clears any leftover marking on that day', indicating a side effect beyond a simple swap. However, it does not mention authentication, rate limits, or whether previous recipes are replaced permanently.
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 two sentences with zero wasted words. The core purpose is front-loaded, and the usage guideline is appended efficiently. Every sentence 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?
For a simple two-parameter mutation tool with no output schema or annotations, the description provides adequate context: purpose, side effect, and usage flow. It mentions clearing markings and references a sibling tool. Minor gap: no explanation of 'leftover marking' or return value, but overall sufficient.
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?
With 0% schema description coverage, the description must compensate. The example implies date is a day (e.g., 'Tuesday') and recipe_id selects a specific recipe, adding meaning beyond bare schema titles. However, it does not specify expected formats (e.g., ISO date) or that recipe_id might require prior existence.
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 replaces a meal on a specific day with a specific recipe, using a concrete example ('put tacos on Tuesday instead'). It distinguishes from siblings like suggest_recipes by explicitly calling it a 'literal per-day override' and contrasting it with the recommendation flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: use it to replace a day with a specific recipe, and if the goal is to make a day quicker, call suggest_recipes first. This clear when-to and when-not advice helps the agent decide correctly.
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 must convey behavioral traits. It explains the two parameters and their usage but does not disclose side effects (e.g., whether it overwrites existing recipes, handles duplicates, or any destructive behavior). The description is moderately transparent but lacks details on the overall operation's impact.
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 concise with four sentences, front-loading the purpose and then detailing parameter usage. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two optional parameters and no output schema, the description adequately covers usage and parameter semantics. However, it does not mention what happens after import (e.g., error handling, return values), leaving some context incomplete for a comprehensive understanding.
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?
With 0% schema description coverage, the description fully compensates by explaining the two parameters: csv_path for reading a server file, csv_content for pasting CSV text from a remote client. This adds critical meaning beyond the schema's type definitions.
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 it imports many recipes from a Plan to Eat CSV export, specifying it as an optional bulk shortcut. It distinguishes itself from the sibling add_recipe by noting that most users seed with add_recipe instead, making the purpose specific and distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: it contrasts with add_recipe for single entries and advises using add_recipe instead for most users. It also explains the two methods of providing CSV data (server file vs. direct content), giving clear context for each scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses item skipping for missing title/ingredients, de-duplication, single state write, and return structure. No annotations present, so description carries full burden.
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?
Efficiently structured with purpose, flow, and details; each sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensively covers purpose, usage, item format, error handling, and return value despite no output schema or annotations.
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?
Adds detailed field descriptions (title, ingredients, optional fields) and behavior (parsing, de-duplication) beyond the minimal schema, which has 0% coverage.
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?
Clearly states 'Bulk-add many recipes in one call' with specific use case (building a starter library) and distinguishes from sibling tools like add_recipe and import_recipes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes when to use (no Plan to Eat export) and the intended flow (generate, review, save), with explicit exclusions and alternative tool mention.
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:

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

Score Badge

Copy to your README.md:

[![meal-planner-mcp MCP server](https://glama.ai/mcp/servers/illinigirl/meal-planner-mcp/badges/score.svg)](https://glama.ai/mcp/servers/illinigirl/meal-planner-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/illinigirl/meal-planner-mcp'

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