Soup.net MCP Server (stdio transport). Thin proxy that forwards tool calls to the Soup.net backend HTTP API using the user's API key. The backend is the source of truth for tool behavior.
Static source inference · medium confidence · evidence: structured output
No deprecated protocol patterns detected
Summary
SoupNet MCP server has 4 tools with significant quality gaps. Tool naming is reasonable (verb_noun), but descriptions are extremely brief (8-33 chars, well below the 34-392 char baseline). The check_recipe tool has a large but poorly organized parameter schema with many deprecated/unclear parameters (clusters, max_chars, decided_at, session_id, etc.) that muddy the interface. Parameter descriptions are generic and lack clarity on constraints. No output schemas are documented. Error handling guidance is absent. The server uses STDIO transport, which is a hard cap at 50/100 for protocol readiness and significantly limits usefulness.
Descriptions are critically short (8-33 chars), well below the 34-392 char production baseline. Tool descriptions lack context on WHEN to use each tool, WHAT it returns, and any prerequisites. LLMs cannot properly infer tool selection with such minimal guidance.
check_recipe contains deprecated/unclear parameters (clusters, max_chars, decided_at, session_id, intent, agent_id) that appear leftover from a prior system design. These muddy the interface and force LLMs to reason about legacy fields instead of focusing on core functionality. Parameter descriptions for these fields are also missing or vague ('Deprecated parameter - decision timestamp').
Output schemas are not documented anywhere. Tools return results (implicit from descriptions like 'Get briefing information', 'Recipe lookup'), but LLMs have no visibility into the structure, field names, or types of responses. This forces LLMs to guess what data is available and breaks composition chains.
Recommendations
Expand all tool descriptions to 100-200 characters. Include: (1) What the tool does, (2) When to use it vs. other similar tools, (3) What it returns. Example: 'check_recipe: Validate a recipe against known patterns and supporting evidence. Returns validation result with severity level (ok/warning/error) and correction suggestions. Use before executing an untested recipe.'
Remove deprecated parameters from check_recipe: clusters, max_chars, decided_at, session_id, intent, agent_id, synthesize. If these are used internally, handle them server-side, do not expose them in the tool interface. This reduces parameter noise from 17 to 10.
For check_recipe's 'feedback' parameter, either remove it (if it's telemetry leakage) or rename and document it. If it represents user corrections from prior checks, name it 'prior_corrections' and describe the expected structure: array of {recipe_id, correction_type, applied_change}.
Document output schemas for all 4 tools. For example: check_recipe returns {status: 'ok'|'warning'|'error', corrections: [{suggestion: string, severity: string}], execution_time_ms: number}. Post these in tool descriptions or as a separate schema reference.
Rewrite parameter descriptions to be prescriptive, not circular. Instead of 'Verbosity level for output', use: 'Output verbosity. concise: single-line result; standard: result + metadata; verbose: result + reasoning + metadata.' Similarly, 'filter' in search_recipes should explain: 'Free-form search filter. Matches recipe names, ingredients, tags. Partial text supported (e.g., "chocolate" matches "dark chocolate cake").'
Parameter descriptions are generic or missing. For example, 'supporting_evidence' in check_recipe has description 'Supporting evidence for the check' (circular); 'verbosity' says 'Verbosity level for output' (tautological). No guidance on format, expected content, or when each option (concise/standard/verbose) is appropriate.
check_recipe has a 'feedback' parameter (array of objects with trace_id, search_id, disposition, etc.) that is only described as 'Ride-along feedback about prior checks', no guidance on structure, when to populate it, or what impact it has on the recipe check. This appears to be an internal telemetry parameter leaking into the tool interface.
No error handling guidance. Tools return no documented error responses, recovery paths, or examples of what happens when a recipe is invalid, search returns no matches, or API authentication fails. LLMs have no recovery strategy.
check_recipe accepts a 'file' parameter (multimodal embedding: images, video, audio, PDF) but this is buried in the schema with minimal description ('Optional file to attach as reference evidence'). No guidance on file format constraints, size limits, or what happens if an unsupported type is passed.
search_recipes has a 'filter' parameter described only as 'Search filter criteria' (generic). No guidance on syntax, what fields are filterable, or whether it accepts free-form text, JSON, or a DSL. LLMs must guess.
search_recipes
Add error handling guidance. For each tool, document common failure modes: 'If no recipes match the filter, the tool returns an empty result set. Try broadening the filter or use get_recipes to list all available IDs.' For check_recipe: 'If the recipe format is invalid, returns {status: "error", message: "Invalid recipe syntax"}. Correct the syntax and retry.'
Clarify the 'file' parameter in check_recipe. Document: 'Optional multimodal evidence (images, video, audio, PDF ≤6 pages, ≤50 MB). Used to provide context for recipe validation (e.g., screenshot of ingredients). Multimodal embeddings enhance check quality.'
For search_recipes, add pagination guidance. If large result sets are possible, document: 'Results are limited to 50 matches. Use offset/limit parameters (if available) for pagination, or refine the filter.'
Add examples for optional parameters. For response_format in check_recipe, clarify: 'markdown: result as markdown text; structured: JSON object with fields (status, corrections, metadata). Use structured for downstream tool chaining.'
Add composition guidance to tool descriptions. E.g., 'After calling search_recipes, pass matched recipe_ids to check_recipe for validation' or 'Call get_recipes first to discover available recipe IDs, then use check_recipe.'
Remove or clarify the 'known_recipes' parameter in check_recipe. Is this a list of recipe IDs? A JSON object? A free-form string? Document format and purpose: 'Optional JSON list of trusted recipe IDs to use as reference patterns during validation. Improves accuracy for domain-specific recipes.'
Validate and document constraint on check_recipe's 'recipe' parameter: Is it a recipe ID or the full recipe text? If both, split into recipe_id (for lookup) and recipe_text (for inline validation).