Loading ToolBench
MCP server for Mealie API (stdio, npx).
This STDIO-only MCP server for Mealie exposes 2 read-only recipe tools with moderately good naming and descriptions, but has significant gaps in parameter documentation, output schema visibility, and error handling guidance. Tool names follow verb_noun convention (search_recipes, get_recipe_by_id), which is correct. Descriptions are present and reasonably detailed (111 and 39 characters respectively), meeting the 10-1024 baseline. However, parameter descriptions are inconsistent, search_recipes documents most params well, but get_recipe_by_id has no visible parameter descriptions in the schema. Output schemas are declared (searchRecipesOutput, getRecipeOutput) but not visible in the provided source, preventing validation of return type documentation. Input validation occurs via AJV, but error messages lack recovery guidance (e.g., 'Invalid payload' with no hint about what was wrong or which field failed). The tools are read-only and stateless, reducing composition risk, but the response shaping logic (mapping Mealie API fields to normalized output) is buried in handler code rather than documented in the output schema.
Fetch a full recipe by ID (or slug).
Search Mealie recipes by text query, with optional tags and pagination.
get_recipe_by_id has no visible parameter descriptions in input schema; LLMs cannot distinguish between id and slug or understand why both are provided and when to use each.
Output schemas (searchRecipesOutput, getRecipeOutput) are imported but not visible in source code; cannot verify whether return types are documented or whether responses include all IDs needed for chaining (e.g., slug for URL construction).
Error messages lack recovery guidance. AJV validation errors return 'Invalid payload' with field paths but no hint about valid values or next steps. Mealie HTTP errors are wrapped in generic 'MEALIE_HTTP_ERROR' with only the message, LLM has no way to know if the error is retryable, user-fixable, or fatal.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 46 | 2024-11-05+ | v1 |
search_recipes accepts both 'limit' (legacy) and 'perPage' with fallback logic in handler; this hidden fallback is not documented in the parameter description, forcing LLMs to guess which parameter to use or discovering the behavior empirically.
Response shaping logic (mapping Mealie API fields like 'name', 'title', 'recipeIngredient', 'tags', 'recipeCategory' to normalized output) is implemented in handler code but not documented. LLM has no way to predict what field names the tool returns, risking downstream tool failures or hallucinated field names.
get_recipe_by_id uses oneOf constraint in schema to enforce mutual exclusivity between 'id' and 'slug', but the handler accepts either via 'const key = id || slug', creating ambiguity about which was used. No description clarifies when to pass which.