HelloFresh MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a distinct purpose with clear boundaries: get_* tools retrieve specific data types, modify_* tools change settings, and action tools like select_meals, skip_week, and rate_recipe handle discrete operations. No overlap exists that would cause agent confusion.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern: get_delivery_schedule, get_menu, get_past_orders, get_preferences, get_recipe_details, get_subscription, modify_delivery, modify_subscription, rate_recipe, select_meals, skip_week, update_preferences. The verbs (get, modify, rate, select, skip, update) logically match the actions.
Tool Count5/5
12 tools is well-scoped for a HelloFresh server, covering core user workflows like viewing menus, managing deliveries, updating preferences, and rating recipes. Each tool earns its place without redundancy or bloat.
Completeness5/5
The toolset provides complete CRUD/lifecycle coverage for the HelloFresh domain: retrieval (get_*), updates (modify_*, update_preferences), actions (select_meals, skip_week, rate_recipe), and subscription management. No obvious gaps exist for typical user interactions.
Average 3.3/5 across 12 of 12 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 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 provided, the description carries the full burden of behavioral disclosure. It mentions 'Change the delivery date,' implying a mutation, but fails to disclose critical traits such as required permissions, whether changes are reversible, rate limits, or error conditions. This is inadequate for a mutation tool with zero annotation coverage.
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, direct sentence that front-loads the core action and resource without any wasted words. It is appropriately sized for the tool's complexity, making it efficient and easy to parse.
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's mutation nature, lack of annotations, and no output schema, the description is incomplete. It does not address behavioral aspects like side effects, return values, or error handling, which are crucial for an agent to use the tool correctly. This gap makes it insufficient for the context.
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 100%, so the schema already documents both parameters ('week_id' and 'new_date') with descriptions. The description adds no additional meaning beyond what the schema provides, such as format details or constraints. Baseline 3 is appropriate when the schema handles parameter documentation effectively.
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 action ('Change') and resource ('delivery date for an upcoming week's box'), making the purpose immediately understandable. However, it does not explicitly differentiate from sibling tools like 'skip_week' or 'modify_subscription', which might involve similar concepts, so it falls short of a perfect score.
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. For example, it does not specify if this is for rescheduling versus skipping deliveries, or how it differs from 'modify_subscription' or 'skip_week' among the siblings. This lack of context leaves the agent without clear usage instructions.
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 full burden but only states the action without disclosing behavioral traits such as permission requirements, whether changes are immediate or scheduled, impact on billing, or error conditions. It mentions 'your subscription' implying user context but doesn't clarify authentication needs or side effects.
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 front-loads the purpose without unnecessary words. Every part earns its place by specifying the action, resource, and key parameters concisely.
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's complexity (mutation with 3 parameters) and lack of annotations and output schema, the description is incomplete. It doesn't cover behavioral aspects like success/failure responses, side effects, or usage context, leaving significant gaps for an AI agent to understand the tool fully.
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 100%, so the schema fully documents parameters with descriptions, constraints, and enums. The description adds no additional meaning beyond implying these are the modifiable aspects, aligning with the schema but not compensating for any gaps (none exist).
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 action ('Change') and the resource ('your HelloFresh subscription plan'), specifying what aspects can be modified (size and frequency). It distinguishes from siblings like 'get_subscription' (read-only) and 'modify_delivery' (different resource), though it doesn't explicitly name these 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?
No explicit guidance on when to use this tool versus alternatives like 'modify_delivery' or 'update_preferences' is provided. The description implies usage for subscription changes but lacks context on prerequisites, exclusions, or comparative scenarios with sibling tools.
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 full burden but offers minimal behavioral insight. It states the tool allows selection of multiple recipes, but doesn't disclose if this is a write operation (likely, given 'Choose'), what permissions are required, whether selections are final or editable, error conditions (e.g., invalid recipe_id), or side effects (e.g., updating a delivery schedule). This leaves significant gaps for a mutation tool.
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 appropriately sized and front-loaded in a single, efficient sentence. It conveys the core purpose without waste, and every word earns its place by specifying the action ('Choose'), target ('specific meals'), context ('upcoming delivery week'), and method ('select multiple recipes by their IDs').
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's complexity as a mutation tool with no annotations and no output schema, the description is incomplete. It lacks critical context such as behavioral traits (e.g., whether it's idempotent, requires authentication), error handling, or what happens post-selection (e.g., confirmation, delivery updates). For a tool that modifies delivery meals, this leaves the agent under-informed.
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 100%, so the schema fully documents parameters (week_id, meals with recipe_id and servings). The description adds no additional meaning beyond implying 'meals' refers to recipes by IDs, which is already covered. With high schema coverage, the baseline is 3, and the description doesn't compensate or add value.
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 purpose with a specific verb ('Choose') and resource ('specific meals for an upcoming delivery week'), and mentions selecting multiple recipes by IDs. It distinguishes from read-only siblings like get_menu or get_recipe_details by implying a selection action, though it doesn't explicitly differentiate from modify_delivery or skip_week which also affect deliveries.
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. It doesn't mention prerequisites (e.g., needing a valid week_id from get_delivery_schedule), exclusions (e.g., cannot use after cutoff time), or compare to siblings like modify_delivery (which might adjust existing selections) or skip_week (which avoids delivery entirely). Usage is implied but not explicit.
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 are provided, so the description carries the full burden. It mentions 'Update' which implies a mutation, but doesn't disclose behavioral traits such as whether changes are reversible, if specific permissions are required, what happens to existing preferences not mentioned, or any rate limits. This is a significant gap for a mutation tool with zero annotation coverage.
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 front-loads the key action and resource, with specific examples that earn their place by clarifying scope. There is no wasted text or redundancy.
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 that this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral aspects like side effects, error handling, or response format, which are crucial for safe and effective use. The high schema coverage doesn't compensate for these gaps in context.
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 description lists examples of what can be updated (vegetarian mode, allergen avoidance, preferred cuisines), which aligns with some parameters in the schema. However, with 100% schema description coverage, the schema already fully documents all 5 parameters. The description adds minimal value beyond the schema, so a baseline score of 3 is appropriate.
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 action ('Update') and resource ('dietary and cuisine preferences on HelloFresh'), with specific examples like vegetarian mode and allergen avoidance. However, it doesn't explicitly distinguish this tool from sibling tools like 'modify_subscription' or 'modify_delivery', which might also involve preference changes in a broader context.
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. For instance, it doesn't clarify if this should be used instead of 'modify_subscription' for preference updates, or if there are prerequisites like having an active subscription. The context is implied but not explicit.
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 are provided, so the description carries the full burden of behavioral disclosure. While it implies a read-only operation ('View'), it lacks details on permissions, rate limits, error handling, or response format. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
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 front-loads the key purpose and details without unnecessary words. Every part of the sentence contributes directly to understanding the tool's function, making it appropriately sized 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?
Given the tool's low complexity (one optional parameter) and high schema coverage, the description is adequate but incomplete. It lacks output details (no output schema provided) and behavioral context (no annotations), which are important for a tool that retrieves historical data. This results in a minimal viable description with clear gaps.
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 description coverage is 100%, with the parameter 'limit' fully documented in the input schema (including type, description, default, and constraints). The description does not add any parameter-specific information beyond what the schema provides, so it meets the baseline score of 3 for high schema coverage.
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 purpose with specific verbs ('View') and resources ('HelloFresh order history'), and it details what information is included ('delivery dates, meals received, and order status'). However, it does not explicitly differentiate this tool from its siblings (e.g., 'get_delivery_schedule' or 'get_subscription'), which would be needed for a score of 5.
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. For example, it does not specify if this is for historical data only or how it differs from 'get_delivery_schedule' or 'get_subscription'. Without such context, users may struggle to choose the right tool among siblings.
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 are provided, so the description carries the full burden of behavioral disclosure. It states this is a read operation ('Get'), but doesn't cover critical aspects like authentication needs, rate limits, error handling, or response format (e.g., JSON structure). For a tool with no annotation coverage, this leaves significant gaps in understanding how it behaves beyond basic functionality.
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 front-loads the core action ('Get full recipe information') and lists key data points without redundancy. Every element (ingredients, instructions, etc.) adds value by specifying what information is included, making it appropriately sized and well-structured for quick comprehension.
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's low complexity (1 parameter, no nested objects) and high schema coverage, the description is adequate for basic understanding. However, with no annotations and no output schema, it fails to address behavioral aspects like response format or error conditions. This makes it minimally viable but incomplete for reliable agent use without additional context.
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 input schema has 100% description coverage, with 'recipe_id' clearly documented as 'The unique recipe identifier'. The description adds no additional parameter details beyond implying it retrieves data for a recipe, which aligns with the schema. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't enhance parameter understanding but doesn't detract either.
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 purpose with specific verbs ('Get full recipe information') and resources ('recipe'), listing the types of information retrieved (ingredients, instructions, nutrition, etc.). It distinguishes itself from siblings like 'get_menu' or 'rate_recipe' by focusing on detailed recipe data rather than menus or ratings. However, it doesn't explicitly differentiate from all siblings (e.g., 'select_meals' might also involve recipe details), keeping it from a perfect score.
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. It doesn't mention prerequisites (e.g., needing a recipe_id), exclusions (e.g., not for modifying recipes), or comparisons to siblings like 'get_menu' (which might list recipes) or 'rate_recipe' (which involves feedback). Usage is implied only by the tool name and description, lacking explicit context for selection.
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, the description carries the full burden of behavioral disclosure. It states the action ('skip') and outcomes (no delivery/charge), but lacks details on permissions, reversibility, side effects, or confirmation processes. This is a mutation tool with significant behavioral 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, efficient sentence that front-loads the purpose and outcomes with zero wasted words. It is appropriately sized for a tool with one parameter and clear intent.
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's complexity (mutation with one parameter), no annotations, and no output schema, the description is minimally adequate. It covers the basic action and result but lacks details on behavioral traits, error handling, or integration with sibling tools, leaving gaps for an agent.
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 100%, so the schema fully documents the 'week_id' parameter. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints, meeting the baseline for high 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?
The description clearly states the specific action ('skip a delivery week') and the resource affected ('delivery week'), with explicit outcomes ('won't receive or be charged for that week's box'). It distinguishes from siblings like 'modify_delivery' or 'modify_subscription' by focusing on skipping rather than general modifications.
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 such as 'modify_delivery' or 'modify_subscription', which might offer overlapping functionality. The description implies usage for skipping weeks but lacks explicit context, prerequisites, or exclusions.
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 are provided, so the description carries full burden. It states it's a read operation ('View'), which is clear, but lacks details on behavioral traits like permissions needed, rate limits, pagination, or error handling. The description doesn't contradict annotations, but it's minimal for a tool with no annotation support.
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 front-loads the key action ('View all upcoming deliveries') and adds necessary details (what's included). Every word earns its place with no waste 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?
Given the tool has no parameters, no annotations, and no output schema, the description is adequate as a basic read operation but lacks completeness. It doesn't explain the return format, potential errors, or how it integrates with sibling tools like 'modify_delivery', leaving gaps for an AI agent.
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 tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description appropriately focuses on the tool's function without redundant parameter info, meeting the baseline for zero-param tools.
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 purpose with a specific verb ('View') and resource ('upcoming deliveries'), including what information is returned (dates, selected meals, delivery status). It distinguishes from siblings like 'get_past_orders' (past vs upcoming) and 'modify_delivery' (read vs write), though not explicitly named.
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 viewing upcoming deliveries, suggesting when to use it (for upcoming info) versus alternatives like 'get_past_orders' (for past info). However, it lacks explicit guidance on when not to use it or direct comparisons to siblings, leaving some context to inference.
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 indicates this is a read operation ('Get'), but doesn't specify authentication needs, rate limits, error conditions, or the return format. The description is minimal and lacks details on how the data is structured or any constraints.
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, well-structured sentence that efficiently communicates the tool's purpose and scope. It front-loads the key action ('Get your current dietary preferences') and lists specific data fields without redundancy, making it highly concise and easy to parse.
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's simplicity (0 parameters, no annotations, no output schema), the description is adequate but minimal. It covers the basic purpose and data fields, but for a tool with no structured behavioral hints, it could benefit from more context on authentication, return format, or error handling to be fully complete.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately adds no parameter details, focusing instead on the data retrieved. This meets the baseline for tools with no parameters, as it doesn't introduce unnecessary complexity.
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 purpose with a specific verb ('Get') and resource ('your current dietary preferences'), listing the specific data fields retrieved (vegetarian settings, allergens, cuisine types, family-friendly options). It distinguishes from siblings like 'update_preferences' (modification) and 'get_menu' (different resource), though it doesn't explicitly name 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 context by specifying 'your current dietary preferences,' suggesting it's for retrieving user-specific settings rather than general data. However, it lacks explicit guidance on when to use this versus alternatives like 'get_menu' or 'get_past_orders,' and doesn't mention prerequisites or exclusions.
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 are provided, so the description carries the full burden. It mentions the rating scale and optional comment but lacks details on permissions, whether ratings are editable, rate limits, or what happens upon submission. This is a mutation tool with incomplete behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and includes key details (scale, optional review) without any wasted words, making it easy to parse quickly.
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?
For a mutation tool with no annotations and no output schema, the description is insufficient. It does not cover behavioral aspects like authentication needs, error handling, or response format, leaving gaps in understanding how the tool operates in practice.
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 100%, so the schema fully documents parameters like recipe_id, rating, and comment. The description adds minimal value by implying the rating is for cooked recipes but does not provide additional semantics beyond the schema's technical details.
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 specific action ('Rate a HelloFresh recipe you've cooked') and the resource ('recipe'), distinguishing it from sibling tools like get_recipe_details or modify_subscription by focusing on user feedback rather than retrieval or configuration.
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 context ('you've cooked') but does not explicitly state when to use this tool versus alternatives like get_recipe_details for information or update_preferences for broader settings. No exclusions or prerequisites are mentioned.
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 carries the full burden. It implies a read-only operation ('Get') but doesn't disclose behavioral traits like authentication needs, rate limits, or response format. It adds some context about week offsets but lacks details on what 'available recipes/meals' entails (e.g., pagination, data structure).
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 appropriately sized with two sentences that are front-loaded (main purpose first, optional parameter second). Every sentence earns its place by conveying essential information without waste, 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?
Given the tool's low complexity (1 optional parameter, no output schema, no annotations), the description is adequate but has gaps. It explains the purpose and parameter usage but doesn't cover behavioral aspects like response format or error handling, which could be useful for an agent despite the simplicity.
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 100%, so the schema already documents the week_offset parameter thoroughly. The description adds minimal value by mentioning 'optionally specify a week offset to see future menus,' which aligns with but doesn't expand beyond the schema's details. Baseline 3 is appropriate as the schema does the heavy lifting.
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 ('Get') and resource ('current week's available recipes/meals from HelloFresh'), making the purpose specific. It distinguishes from siblings like get_delivery_schedule or get_past_orders by focusing on menu/meal availability rather than delivery logistics or order history.
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 provides clear context for when to use this tool (to see available recipes/meals) and includes an optional parameter for future weeks. However, it doesn't explicitly state when NOT to use it or name alternatives among siblings (e.g., get_recipe_details for specific recipes), missing full differentiation.
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 carries full burden. It indicates a read-only operation ('View') and specifies the scope of data returned, but doesn't disclose behavioral traits like authentication requirements, rate limits, error conditions, or whether it requires an active subscription. It adds useful context about what data is included but lacks operational details.
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, well-structured sentence that efficiently conveys the tool's purpose and key data points without unnecessary words. It's front-loaded with the core action and resource, and every element (meals per week, servings, price, next delivery) adds specific value.
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's simplicity (0 parameters, no annotations, no output schema), the description adequately covers the basic purpose and data scope. However, for a tool that likely requires authentication and returns structured subscription data, the lack of output format details or behavioral context leaves some gaps in completeness.
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 tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the lack of inputs. The description doesn't need to compensate for parameter gaps, and it appropriately doesn't mention parameters since none exist. A baseline of 4 is appropriate for zero-parameter tools.
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 ('View') and specific resource ('your current HelloFresh subscription plan details'), listing concrete attributes like meals per week, servings, price, and next delivery. It distinguishes from siblings by focusing on subscription details rather than delivery schedules, menus, orders, or modifications.
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 context by specifying 'current' subscription details, suggesting it's for checking active plan information. However, it doesn't explicitly state when to use this versus alternatives like 'modify_subscription' or 'get_delivery_schedule', nor does it provide exclusion criteria or prerequisites.
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:

[![mcp-hellofresh MCP server](https://glama.ai/mcp/servers/markswendsen-code/mcp-hellofresh/badges/card.svg)](https://glama.ai/mcp/servers/markswendsen-code/mcp-hellofresh)

Score Badge

Copy to your README.md:

[![mcp-hellofresh MCP server](https://glama.ai/mcp/servers/markswendsen-code/mcp-hellofresh/badges/score.svg)](https://glama.ai/mcp/servers/markswendsen-code/mcp-hellofresh)

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/markswendsen-code/mcp-hellofresh'

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