An MCP server for meal search and nutrition information using hybrid search (BM25 and vector similarity) with cross-encoding reranking
This Food Server has 3 tools with significant quality gaps. Tool naming follows verb_noun convention adequately (get_meal_options, get_image_for_meal, help). However, descriptions lack clarity about when to use tools vs alternatives, parameter descriptions are minimal, and output schemas are completely undocumented. The `help` tool is trivial and adds little value. No error handling guidance, no pagination support despite potentially large result sets, and no input validation described. The get_image_for_meal tool has a hardcoded file path that does not match its parameter (meal_name), creating a discrepancy between interface and implementation. Overall, this reads as a prototype rather than production-grade tooling.
Retrieves the image bytes for a specific meal.
Uses the search engine class to get most relevant meals base on the query. The search is performed using both BM25 and vector similarity with cross-encoding for reranking.
Helper function with available tools.
Output schemas completely undocumented. get_meal_options returns List[str] but no structure, format, or fields are explained. Agents cannot parse results or chain to downstream tools. get_image_for_meal returns bytes with no encoding, size limits, or format guidance.
Parameter descriptions are absent or trivial. 'query' in get_meal_options has no guidance on format, length, examples of valid queries, or what happens with empty/malformed input. No description for intermediate_results and final_results beyond their names.
Tool descriptions lack context about WHEN to use vs alternatives. get_meal_options description explains HOW (BM25, vector similarity, cross-encoding) but not WHEN an agent should call it or what distinguishes it from the commented-out get_meal_options_naive variant.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 7 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 35 | - | v1 |
get_image_for_meal parameter meal_name is ignored; the tool hardcodes 'qwen-image_todo_meal.png'. The interface promises to retrieve an image for ANY meal_name, but implementation returns the same placeholder image regardless. This is a contract violation.
No error handling or recovery guidance. What happens if query is empty? If meal not found? If image file missing? Agents get no actionable error messages or next steps.
No pagination or result limits documented. get_meal_options can return List[str] but with no guidance on max size, pagination support, or offset/limit parameters. Hybrid search with 2 final_results is hardcoded; agents cannot request more.
help tool is trivial and contains outdated information. Its return string mentions 'calorie_limit' and 'protein_goal' parameters that do not exist in the actual get_meal_options signature. This misleads agents about available tools.
No input validation described. Parameters like intermediate_results and final_results accept integers but no min/max bounds are documented. Can an agent pass 0, negative, or 1000000? Undefined behavior.