Loading ToolBench
Multi-server MCP system that provides recipe recommendations via Facebook Messenger/WhatsApp by combining a vector database search and creative recipe customization suggestions
The RecipesMessengerAuto MCP server has severe definition quality issues across both tools. Tool naming follows the verb_noun pattern (creative_search, get_recipe) which is correct, but parameter and output documentation is almost entirely absent. The 'creative_search' tool has a description but 'get_recipe' relies on a docstring in the implementation rather than explicit schema registration. Most critically, neither tool documents input/output schemas with proper type information or structured responses. Parameter descriptions exist but are minimal. There is no error handling guidance, no pagination support despite potential for large result sets, and responses are plain strings rather than structured objects. The tools lack the basic structured output patterns expected in production-grade agent tools.
Search for creative ingredient advices and recipe customizations of a predefined recipe.
Search for recipes at a vector database containing hundreds of recepies. The search is made by similarity search, so make sure to use relevant keywords for a good match.
No structured output schemas documented. Both tools return plain string responses instead of typed objects with fields. This forces LLMs to parse unstructured text and prevents composition of tools (downstream tools cannot reliably extract typed data).
get_recipe lacks proper tool registration. Description is embedded in a Python docstring (not exposed in schema). The tool definition is inferred from FastMCP decorator but no explicit MCP schema with input/output type definitions is visible.
No pagination or result limiting for get_recipe. Tool returns '\n\n'.join([res.page_content for res in results]) with no limit on result count. A vector DB search could return hundreds of recipes, exhausting context window and degrading LLM reasoning.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 42 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
No parameter type information exposed in input schemas. 'query' parameter is typed as string in Python but FastMCP schema does not enforce constraints, patterns, or length limits. No guidance on expected query format or quality hints.
No error handling guidance or recovery paths. If the vector DB returns no results, or if the LLM service (Ollama) is unavailable, tools fail silently or return empty strings. No differentiation between retryable errors and user-fixable errors.
Tool descriptions are under 100 characters and lack context on when to use them. 'creative_search' says it searches for 'creative ingredient advices' but does not explain what context it requires (e.g. a recipe name from get_recipe). No dependency hints between tools.
No idempotence guarantees. creative_search calls an LLM each time with identical input, potentially returning different responses. get_recipe may also return different ranking depending on vector DB state. Agents retry on ambiguous failures, non-idempotent behavior risks duplicate/conflicting advice to users.