Loading ToolBench
A Python-based MCP server for diet planning, meal logging, and dietary analysis. Provides tools for managing diet plans, food logs, and dietary preferences.
The CookHero MCP server exhibits significant definition quality gaps across all four tools. While schemas are present and mostly complete, descriptions lack LLM-optimized detail, parameter naming creates ambiguity, and error handling guidance is absent. Tool names are action-verb prefixed (good), but several parameters lack clear type constraints and descriptions. No output schemas are documented. The subagent tool is vaguely described and lacks structured input/output patterns. Most tools rely on enum constraints for safety but fail to provide recovery guidance. This server would require substantial refinement before production deployment.
分析用户的饮食数据。支持以下操作： - daily_summary: 获取某天饮食摘要 - weekly_summary: 获取某周饮食摘要 - deviation: 计划 vs 实际偏差分析 - preferences: 获取饮食偏好 - update_preferences: 更新饮食偏好
记录和管理用户的实际饮食记录。支持以下操作： - log: 手动记录一餐（显式食物列表） - log_from_text: 用自然语言描述并由 AI 解析 - mark_eaten: 将计划餐次标记为已吃并生成记录 - get: 获取指定记录详情 - get_by_date: 获取某天的所有记录 - update: 更新记录内容（食物列表/餐次/日期/备注） - delete: 删除记录 - add_item: 向已有记录追加食物
管理用户的计划餐次（按具体日期存储）。支持以下操作： - add_meal: 按日期添加计划餐次 - update_meal: 更新已有餐次（菜品/备注等） - delete_meal: 删除餐次 - copy_meal: 复制餐次到指定日期 - get_by_week: 获取某周范围内的计划餐次
调用专业子代理来处理任务。 当用户的请求需要子代理的专业能力时，应调用此工具。
Output schemas completely undocumented. Tools return data but LLMs cannot infer structure of results, forcing agents to guess which fields are available for downstream chaining. E.g., diet_analysis.daily_summary returns nutritional data but schema is not declared.
Descriptions lack WHEN/WHY guidance. diet_analysis description lists operations (daily_summary, weekly_summary, etc.) but does not explain when the agent should call this vs. diet_log or diet_plan. LLMs cannot disambiguate tool selection.
subagent_* tool name is wildcard/generic and violates verb_noun convention. 'subagent_*' is vague, does not convey what action occurs. Description '调用专业子代理来处理任务' (call professional sub-agent) is generic and lacks specificity on which sub-agents exist or when to use each.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 49 | - | v1 |
No error recovery guidance. Tools provide input schemas but no documented error scenarios, error classifications (retryable vs. fatal), or next-step recovery hints. E.g., if user_id is invalid, what should the agent do?
Parameter descriptions lack format/constraint detail. 'target_date: 目标日期 YYYY-MM-DD' states format in name but not in description text. 'user_id' is required but no guidance on format (UUID vs. email vs. username). LLMs cannot validate without explicit constraints in descriptions.
diet_log and diet_plan allow both 'disliked_foods' and 'avoided_foods' (redundant), and 'disliked_foods' is marked as compatibility field. Unclear which to use; LLMs will pass both, causing confusion. Should consolidate to one parameter.
No pagination declared. diet_plan.get_by_week returns 'weekly plan' but no limit, offset, or total_count fields are documented. If a week has 100 planned meals, response could explode context window. Missing pagination guidance.
diet_log.items array contains nested objects with partial schema. 'weight_g' is optional (no type constraint), 'unit' is free-form string (should enum: 份/个/碗 per description). LLMs cannot reliably construct items without strict type definitions.