Skip to main content
Glama
HZZY2019

cook-mcp

by HZZY2019
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Hybrid

🍳 HowToCook-MCP Server 🥘 -- 炫一周好饭，拒绝拼好饭

English | 简体中文

本项目 CDN 加速及安全防护由 Tencent EdgeOne 赞助

亚洲最佳 CDN、边缘和安全解决方案 - Tencent EdgeOne

让 AI 助手变身私人大厨，为你的一日三餐出谋划策！

基于Anduin2017/HowToCook打造的 MCP(Model Context Protocol)服务器，让 AI 助手能够为你推荐菜谱、规划膳食，解决"今天吃什么"的世纪难题！

数据来源：Anduin2017/HowToCook ⭐ 没有 star 的同学快去点个星星吧！

🎉 想直接使用当前 MCP？立即体验 https://howtocookmcp.weilei.site/

🎉 同时，我们也提供了 DXT（Desktop Extensions）供大家体验，一键安装到 Claude Desktop

如下：请确保你已经安装了最新版的 Claude Desktop, 当前 MCP 的 DXT 文件已上传代码库，可以自行下载或者 Fork 本仓库自行构建

DXT DXT DXT

本地开发如何打包成 DXT？

1.运行 npm install -g @anthropic-ai/dxt

2.在包含本地 MCP 服务器的文件夹中，运行 dxt init。也就是您 MCP 的根目录，此命令将引导您创建manifest.json

3.运行dxt pack创建 dxt 文件 直接用 npx 调用（无需重开终端）：此命令将引导您创建manifest.json npx -y @anthropic-ai/mcpb init 后续打包： npx -y @anthropic-ai/mcpb pack ---成功 试 npx 版本最快；若成功，再调整 PATH 以便直接用 mcpb 命令。

现在，任何支持 DXT 的应用都可以运行您的本地 MCP 服务器。例如，使用适用于 macOS 和 Windows 的 Claude 打开该文件即可显示安装对话框

具体参阅:anthropics/dxt

📸 效果预览

功能预览1 功能预览2

Related MCP server: cookwith-mcp

🔌 支持的 MCP 客户端

本服务器适用于所有支持 MCP 协议的 AI 助手和客户端，包括但不限于：

  • 🤖 Claude 桌面应用

  • 📝 Cursor

  • 💼 其他支持 MCP 的客户端

✨ 美味功能

该 MCP 服务器提供以下美食工具:

  1. 📚 查询全部菜谱 - 获取所有可用菜谱数据，做菜百科全书 -- 慎用这个--上下文太大

  2. 🔍 根据分类查询菜谱 - 按照分类筛选菜谱，想吃水产？早餐？荤菜？主食？一键搞定！

  3. 📖 查询指定菜谱 - 根据菜谱名称查询特定菜谱的完整详情，包括食材、步骤等

  4. 🧩 智能推荐膳食 - 根据你的忌口、过敏原和用餐人数，为你规划整整一周的美味佳肴

  5. 🎲 不知道吃什么 - 选择困难症福音！根据人数直接推荐今日菜单，再也不用纠结了

🚀 快速上手

📋 先决条件

  • Node.js 16.0.0+ 🟢

  • npm 或 yarn 📦

💻 安装步骤

  1. 克隆美食仓库

git clone https://github.com/HZZY2019/cook-mcp.git
cd cook-mcp

  1. 安装依赖（就像准备食材一样简单！）

npm install

  1. 编译代码（烹饪过程...）

npm run build

🎯 命令行参数

服务器支持以下命令行参数：

  • --transport <stdio|http|sse> - 选择传输方式（默认为 stdio）

  • --port <number> - 使用 http 或 sse 传输时的监听端口（默认为 3000）

示例：使用 http 传输并监听 8080 端口

node build/index.js --transport http --port 8080

🍽️ 开始使用

🔥 启动服务器

npm start

🔧 配置 MCP 客户端

推荐使用 Cursor 快速体验(两种方式)

  1. 使用 npm 包：请先运行 npm i -g cook-mcp ,否则会出现 Failed to create client

然后在 Cursor 设置中添加 MCP 服务器配置：

{
	"mcpServers": {
		"cook-mcp": {
			"command": "npx",
			"args": ["-y", "cook-mcp"]
		}
	}
}

  1. 如果是克隆仓库本地运行，请使用如下配置

{
	"mcpServers": {
		"cook-mcp": {
			"command": "node",
			"args": ["youpath\\cook-mcp\\build\\index.js"]
		}
	}
}

其他 MCP 客户端

对于其他支持 MCP 协议的客户端，请参考各自的文档进行配置，通常需要指定：

  • 服务器名称: howtocook-mcp

  • 命令: npx -y howtocook-mcp

  1. 重启客户端，让美食魔法生效 ✨

🧙‍♂️ 菜单魔法使用指南

以下是在各种 MCP 客户端中使用的示例提示语：

1. 📚 查询全部菜谱

无需参数，直接召唤美食全书！

请使用howtocook的MCP服务查询所有菜谱

2. 🔍 根据分类查询菜谱

请使用howtocook的MCP服务查询水产类的菜谱

参数:

  • category: 菜谱分类（水产、早餐、荤菜、主食等）

3. 🧩 智能推荐一周菜谱

请使用howtocook的MCP服务为3人推荐一周菜谱，我们家不吃香菜，对虾过敏

参数:

  • allergies: 过敏原列表，如 ["大蒜", "虾"]

  • avoidItems: 忌口食材，如 ["葱", "姜"]

  • peopleCount: 用餐人数 (1-10)

4. 🎲 今天吃什么？

请使用howtocook的MCP服务为4人晚餐推荐菜单

参数:

  • peopleCount: 用餐人数 (1-10)

📝 小贴士

  • 该包已发布至 npm，可直接通过npm install -g howtocook-mcp全局安装

  • 本服务兼容所有支持 MCP 协议的 AI 助手和应用

  • 首次使用时，AI 可能需要一点时间来熟悉如何使用这些工具（就像烧热锅一样）

🤝 贡献

欢迎 Fork 和 Pull Request，让我们一起完善这个美食助手！

📄 许可

MIT License - 随意使用，就像分享美食配方一样慷慨！

🍴 美食即将开始，胃口准备好了吗？

Available Tools

5 tools
mcp_cook_getAllRecipesB

获取所有菜谱

ParametersJSON Schema
NameRequiredDescriptionDefault
no_paramNo无参数

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description alone must convey behavioral details. It only states the action and does not disclose return format, pagination, ordering, or potential large response size. This leaves the tool's behavior underspecified.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler. It is appropriately concise for a simple tool, achieving maximum efficiency.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple, but with no output schema and no annotations, the description should clarify what is returned (e.g., an array of recipes). It does not, leaving the return value implicit. The minimal description is adequate for a basic list action but lacks completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has one parameter 'no_param' described as '无参数' (no parameter), covering 100% of the schema. The description adds no parameter information, but with full schema coverage, the baseline 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 '获取所有菜谱' (Get all recipes) clearly states the tool's action and resource, and the 'all' scope distinguishes it from siblings like getRecipesByCategory and getRecipeById. However, it does not explicitly contrast with alternatives, so it is not a perfect 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 does not mention that it is suitable for retrieving every recipe without filters, nor does it point to siblings for filtered or single-recipe needs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_cook_getRecipeByIdA

根据菜谱名称或ID查询指定菜谱的完整详情，包括食材、步骤等

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYes菜谱名称或ID，支持模糊匹配菜谱名称

TDQS

A4/5.0
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 of behavioral disclosure. It discloses that the operation is a query (read) and that the response includes ingredients and steps, which gives some sense of the return content. However, it does not mention potential multi-result behavior from fuzzy name matching, error conditions, or lack of explicit read-only confirmation. While not misleading, it adds only modest context beyond the basic action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that front-loads the essential purpose (query by name/ID for complete details) and specifies the returned content. Every word contributes value, and there is no redundancy or extraneous information.

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's simplicity (one parameter, no nested objects, no output schema), the description adequately conveys the operation and the nature of the returned information ('完整详情' plus ingredients and steps). It does not describe edge cases like multiple matches or not-found behavior, which would be valuable for full completeness, but for a straightforward lookup tool, this level of detail is largely sufficient. A slightly richer statement about possible multiple results from fuzzy matching would have earned a 5.

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 already describes the 'query' parameter as accepting a recipe name or ID with fuzzy name matching, which provides 100% coverage. The description merely repeats this information ('根据菜谱名称或ID') without adding new meaning, syntax details, or usage nuances. Therefore, baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action (查询/query) on a specific resource (specified recipe by name or ID) and enumerates the content of the returned details (食材、步骤等). This distinguishes it from sibling tools like getAllRecipes or getRecipesByCategory, which are list or category-based, not detail lookups.

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 phrasing '根据菜谱名称或ID查询指定菜谱的完整详情' clearly indicates this tool is intended for retrieving a single recipe's complete details by name or ID, which is a distinct use case from listing all recipes or browsing by category. Although it does not explicitly name alternatives, the context of a targeted lookup is evident and no exclusions are implied. This meets the 'clear context, no exclusions' criterion, but stops short of explicitly naming sibling alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_cook_getRecipesByCategoryA

根据分类查询菜谱，可选分类有: 水产, 早餐, 调料, 甜品, 饮品, 荤菜, 半成品加工, 汤, 主食, 素菜

ParametersJSON Schema
NameRequiredDescriptionDefault
categoryYes菜谱分类名称，如水产、早餐、荤菜、主食等

TDQS

A3.8/5.0
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 of behavioral transparency. It accurately describes a read-only query ('查询') and enumerates valid categories, but does not disclose any additional behavior such as return format, pagination, or safety guarantees. It is not misleading, but it is minimal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, front-loaded with the action, and lists the categories compactly. Every word earns its place with no redundancy or noise.

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 one-parameter tool with 100% schema coverage, the description provides enough context to form a valid request, including all allowed values. It lacks explicit return-format information, but the simple nature of the query tool makes this acceptable. Sibling tools are not referenced, slightly reducing completeness.

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 a description and enum for the single 'category' parameter. The description repeats the enum values exactly, adding no semantic information beyond what the schema already provides. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description '根据分类查询菜谱' clearly states the action (query) and resource (recipes) with a specific scope (category). It also enumerates all 10 valid categories, which distinguishes this tool from siblings like getRecipeById (by ID) and getAllRecipes (no filter).

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 lists valid categories but does not explicitly state when to use this tool versus alternatives such as getAllRecipes or recommendMeals. Usage is implied by the category filter, but no exclusions or alternative guidance is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_cook_recommendMealsA

根据用户的忌口、过敏原、人数智能推荐菜谱，创建一周的膳食计划以及大致的购物清单

ParametersJSON Schema
NameRequiredDescriptionDefault
allergiesNo过敏原列表，如["大蒜", "虾"]
avoidItemsNo忌口食材列表，如["葱", "姜"]
peopleCountYes用餐人数，1-10之间的整数

TDQS

A3.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses the main behaviors (recommend, create plan, create shopping list) but does not mention limitations such as what happens if no recipes match, whether it filters by category, or the exact output structure. This is adequate but has gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, compact sentence that front-loads the main action and includes the key outputs. No unnecessary words or repetition.

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 output schema and no annotations, the description should explain what the agent can expect. It mentions creating a weekly plan and a rough shopping list, but lacks detail on the return format, failure modes, or exact recipe selection logic. This is a moderate gap for a complex 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 description coverage is 100%, so the schema already documents all three parameters. The description restates the concepts (忌口, 过敏原, 人数) but adds no new semantic detail about how they influence the result. Baseline 3 is appropriate.

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 with specific verbs: it recommends recipes based on user constraints (忌口, 过敏原, 人数) and creates a weekly meal plan with a rough shopping list. This distinguishes it from sibling tools that simply retrieve recipes by ID or category.

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 a clear use case: when the user has dietary restrictions/allergies and needs a weekly plan. It does not explicitly contrast with sibling tools or state when not to use, but the context is clear enough for an agent to select it appropriately.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_cook_whatToEatA

不知道吃什么？根据人数直接推荐适合的菜品组合

ParametersJSON Schema
NameRequiredDescriptionDefault
peopleCountYes用餐人数，1-10之间的整数，会根据人数推荐合适数量的菜品

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the transparency burden. It discloses that the tool performs a recommendation based on people count and returns dish combinations, but it does not mention side effects, limitations, or output structure. This is adequate but not detailed.

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 wastes no words and leads with the user need. It is perfectly sized for the simplicity of the tool.

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 one well-documented parameter and no annotations or output schema, the description covers the core purpose and expected output at a high level. It could specify the return structure or mention that it only uses peopleCount, but overall it is reasonably complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already fully describes the 'peopleCount' parameter, including range and behavioral effect, so the description adds no additional parameter-level meaning. Baseline 3 applies due to 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 recommends suitable dish combinations based on the number of diners, which is a specific verb+resource+condition. However, it does not explicitly differentiate itself from the sibling tool 'recommendMeals', so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The opening question '不知道吃什么？' and the condition '根据人数' provide a clear context for when to use this tool. It does not mention exclusions or alternative sibling tools, but the use case is well implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 5 tool updatesv0.1.0
    • First observedmcp_cook_getAllRecipes
    • First observedmcp_cook_getRecipeById
    • First observedmcp_cook_getRecipesByCategory
    • First observedmcp_cook_recommendMeals
    • First observedmcp_cook_whatToEat
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0
Disambiguation4/5

Most tools have clear distinct purposes: listing, filtering by category, detailed lookup, and two recommendation tools. The two recommendation tools (recommendMeals and whatToEat) overlap in intent, but their descriptions clarify that one is a simple combo picker and the other is a comprehensive planner with dietary constraints, so an agent can usually tell them apart.

Naming Consistency3/5

All tools share a consistent 'mcp_cook_' prefix and use camelCase, but the action verbs are not uniform: 'getAll', 'getRecipes', 'recommend', 'whatToEat', and 'getRecipeById' mix verb-noun patterns and one non-verb phrase. Minor inconsistencies like 'Recipes' plural vs 'Recipe' singular further reduce naming consistency.

Tool Count5/5

With 5 tools, the server is well-scoped for a recipe lookup and meal recommendation service. It is neither too sparse nor bloated, and each tool contributes a distinct capability for the domain.

Completeness4/5

The tool surface covers listing all recipes, filtering by category, retrieving full details, and two levels of meal recommendations, which addresses the core workflow of finding and choosing recipes. A minor gap is the lack of a dedicated tool to list available categories, though they are enumerated in the getRecipesByCategory description.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • HowToCook-MCP Server

    worryzyy
    A
    license
    A
    quality
    D
    maintenance
    An MCP server that transforms AI assistants into personal chefs by providing recipe recommendations and meal planning features based on the HowToCook repository.
    5
    5,676
    766
    ISC

  • @mealmastery/mcp-server

    MealMasteryAI
    A
    license
    Not graded
    quality
    F
    maintenance
    MCP server for MealMastery AI meal planning that enables users to manage meal plans, recipes, and grocery lists through natural language conversation with AI agents like Claude.
    90
    MIT

  • mealplan-mcp

    evcraddock
    A
    license
    B
    quality
    D
    maintenance
    MCP server for meal planning and grocery list generation, enabling recipe storage, meal plan creation, and automated grocery lists with ignored ingredients.
    8
    2
    MIT

Latest Blog Posts

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/HZZY2019/Cook-MCP'

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