HowToCook-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 clearly distinct purpose: getAllRecipes retrieves all recipes, getRecipeById fetches a specific recipe, getRecipesByCategory filters by category, recommendMeals creates personalized meal plans, and whatToEat suggests immediate meal combinations. There is no overlap or ambiguity in functionality.
Naming Consistency5/5
All tool names follow a consistent snake_case pattern with the prefix 'mcp_howtocook_' and descriptive verb_noun combinations (e.g., getRecipeById, recommendMeals). The naming is uniform and predictable across all tools.
Tool Count5/5
With 5 tools, the server is well-scoped for a cooking/recipe domain. Each tool serves a specific, valuable function without redundancy, making the count appropriate and manageable for the intended purpose.
Completeness4/5
The toolset covers core operations like retrieval, filtering, and recommendation effectively. However, there are minor gaps in CRUD coverage, such as no tools for creating, updating, or deleting recipes, which could limit full lifecycle management but are not essential for a read-only or recommendation-focused server.
Average 3/5 across 5 of 5 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 6 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 ISC 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?
No annotations are provided, so the description carries full burden. It only states the action without disclosing behavioral traits such as whether this is a read-only operation, potential rate limits, pagination, or what the return format might be. For a tool with no annotations, this is a significant gap in 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 phrase '获取所有菜谱', which is extremely concise and front-loaded with the core action. There is no wasted text, making it efficient for quick understanding.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'all recipes' includes (e.g., format, limits) or behavioral aspects. For a tool with no structured data to rely on, the description should provide more context to be fully helpful.
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 1 parameter with 100% coverage, describing it as '无参数' (no parameter). The description doesn't add meaning beyond the schema, but since the parameter indicates no input is needed, the baseline is high. The description implicitly aligns with this by not mentioning parameters, but it doesn't provide extra context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取所有菜谱' (Get all recipes) states the basic action and resource but lacks specificity. It doesn't distinguish from siblings like 'mcp_howtocook_getRecipesByCategory' or 'mcp_howtocook_getRecipeById' by explaining scope or filtering differences. The purpose is clear but vague regarding what 'all' entails.
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 doesn't mention siblings like 'mcp_howtocook_getRecipesByCategory' for filtered results or 'mcp_howtocook_recommendMeals' for suggestions, leaving the agent to infer usage based on tool names alone.
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 only states what the tool does (query by category) without mentioning any behavioral traits like whether it's read-only, what the output format might be, potential rate limits, error conditions, or authentication needs. For a query tool with zero annotation coverage, this is a significant gap.
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: it starts with the core purpose ('根据分类查询菜谱') followed by the category list. Every sentence earns its place—no redundant or verbose language. It's 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 simplicity (1 parameter, 100% schema coverage) but lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., list of recipes, error handling) or behavioral aspects. For a query tool, this leaves gaps in understanding how to interpret results or handle failures.
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 the available categories, which adds meaning beyond the input schema's enum values. However, with 100% schema description coverage (the schema already documents the 'category' parameter with enum and description), the description doesn't provide additional parameter semantics like examples of usage, edge cases, or format details. The baseline is 3 when schema coverage is high.
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: '根据分类查询菜谱' (query recipes by category). It specifies the verb '查询' (query) and resource '菜谱' (recipes), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'mcp_howtocook_getAllRecipes' or 'mcp_howtocook_getRecipeById', which would require a 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. It lists categories but doesn't mention when to choose this over 'mcp_howtocook_getAllRecipes' (all recipes) or 'mcp_howtocook_getRecipeById' (specific recipe). There's no context about prerequisites, exclusions, or typical use cases, leaving the agent to infer usage.
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 for behavioral disclosure. It mentions creating a weekly meal plan and shopping list, which implies generation/mutation behavior, but doesn't specify whether this creates persistent data, requires authentication, has rate limits, or what the output format looks like. For a tool that appears to generate plans (potentially mutating state), this leaves 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 packs substantial information: it covers the input criteria, the core recommendation function, and the two outputs (meal plan and shopping list). There's zero wasted verbiage, and it's appropriately front-loaded with the main 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?
For a tool with no annotations and no output schema that appears to generate meal plans (potentially a mutation operation), the description is insufficient. It doesn't explain what the output looks like (e.g., format of the meal plan, structure of shopping list), whether the plan is saved or transient, or any error conditions. The completeness is inadequate given the tool's apparent 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?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description mentions the parameters (忌口, 过敏原, 人数) but adds no additional semantic context beyond what's in the schema. The baseline score of 3 is appropriate when the schema does the heavy lifting.
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: '根据用户的忌口、过敏原、人数智能推荐菜谱，创建一周的膳食计划以及大致的购物清单' (Intelligently recommend recipes based on user's dietary restrictions, allergies, and number of people, create a weekly meal plan and approximate shopping list). This specifies the verb (recommend, create) and resources (recipes, meal plan, shopping list). However, it doesn't explicitly distinguish this from sibling tools like 'mcp_howtocook_whatToEat' which might have similar functionality.
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 any prerequisites, constraints, or compare it to sibling tools like 'mcp_howtocook_getAllRecipes' or 'mcp_howtocook_whatToEat'. The agent must infer usage from the purpose alone without explicit direction.
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 tool returns '完整详情' (complete details) including ingredients and steps, which adds some behavioral context. However, it doesn't disclose critical traits like whether this is a read-only operation, error handling for invalid queries, performance expectations, or authentication needs, leaving significant gaps for a tool with no 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. It avoids unnecessary words and directly states what the tool does. However, it could be slightly more structured by separating usage context from behavioral details to improve clarity.
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 no annotations and no output schema, the description is moderately complete for a simple lookup tool. It covers the purpose and parameter basics but lacks details on return format, error conditions, or performance limits. For a tool with one parameter and 100% schema coverage, it's adequate but leaves room for improvement in behavioral transparency.
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%, with the parameter 'query' documented as supporting recipe names or IDs with fuzzy matching. The description adds minimal value beyond the schema by restating that it queries by '菜谱名称或ID' (recipe name or ID) but doesn't provide additional syntax, format examples, or clarification on how fuzzy matching works. Baseline 3 is appropriate given the schema does the heavy lifting.
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: '查询指定菜谱的完整详情' (query for complete recipe details) with specific resources (ingredients, steps). It distinguishes from sibling tools by focusing on individual recipe lookup rather than listing all recipes, filtering by category, or providing recommendations. However, it doesn't explicitly name the sibling tools for differentiation.
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 needing complete details for a specific recipe identified by name or ID, which contrasts with sibling tools for bulk retrieval or recommendations. However, it lacks explicit guidance on when to use this tool versus alternatives like 'getRecipesByCategory' for category-based filtering or explicit exclusion criteria.
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 the tool recommends dish combinations based on people count, but doesn't describe how recommendations are generated (e.g., random, curated, based on preferences), what the output format is, or any constraints like rate limits or authentication needs. For a tool with no annotations, this is a significant gap in 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 concise and front-loaded: a single sentence in Chinese that directly states the tool's function and key parameter. There is no wasted text, and it efficiently communicates the core idea without unnecessary elaboration.
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 moderate complexity (recommendation based on a single parameter), no annotations, and no output schema, the description is minimally adequate. It covers the purpose and parameter intent but lacks details on behavior, output, or differentiation from siblings. This meets the minimum viable threshold but has clear 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 description adds meaningful context beyond the input schema. The schema describes 'peopleCount' as an integer 1-10 for meal count, but the description clarifies it's for '用餐人数' (dining people) and that it '会根据人数推荐合适数量的菜品' (will recommend suitable number of dishes based on people count), explaining the parameter's purpose in the recommendation logic. With 100% schema coverage and 1 parameter, this exceeds the baseline of 3.
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: '根据人数直接推荐适合的菜品组合' (recommend suitable dish combinations based on number of people). It specifies the verb '推荐' (recommend) and the resource '菜品组合' (dish combinations), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'mcp_howtocook_recommendMeals', which appears similar.
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 minimal guidance: it implies usage when '不知道吃什么' (don't know what to eat) and based on '人数' (number of people). However, it offers no explicit when-to-use vs. when-not-to-use instructions, no prerequisites, and no alternatives compared to sibling tools like 'mcp_howtocook_recommendMeals'. This leaves the agent with unclear decision criteria.
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:

[![HowToCook-mcp MCP server](https://glama.ai/mcp/servers/worryzyy/HowToCook-mcp/badges/card.svg)](https://glama.ai/mcp/servers/worryzyy/HowToCook-mcp)

Score Badge

Copy to your README.md:

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

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