Static source inference · medium confidence · evidence: Streamable HTTP
Current-spec patterns detected
Summary
Cloud Kitchen MCP Server has 4 tools with basic schema definitions and descriptions. All tools have names starting with action verbs (Get, Add), which is positive. However, the server has significant gaps in parameter descriptions, output schema documentation, and error handling. Tool descriptions are present but minimal (10-80 chars), falling below the production baseline of 194 chars. Parameter descriptions are sparse or missing entirely. No visible error handling patterns, recovery guidance, or output schema documentation. The server uses Spring AI's ToolCallbacks abstraction, which obscures the actual tool registration code, we cannot verify the full schema implementation from the provided source. This caps the per-tool scores at a conservative level due to the inference limitation.
Tools (4)
AddNewItemwritesource verified65/100
Add a new item to the inventory. If the item already exists, an exception is thrown.
GetAllItemsread onlysource verified60/100
Retrieve a list of all items available in the inventory.
Tool descriptions are too brief (10 - 80 chars) and lack context about when to use each tool and what the LLM should do with the result. Baseline production tools average 194 chars and explain WHAT the tool does, WHEN to use it, and WHAT it returns.
Output schemas are not documented in the source code. The provided schema definitions show input parameters for tools, but there is no evidence of documented return types, field names, or structure. LLMs cannot plan downstream calls or extract data without knowing what fields to expect.
No error handling or recovery guidance visible in tool definitions or implementation. Tools provide no error messages guiding the LLM on what to do next (retry, ask user, try alternative tool). This violates the recovery-guide pattern and leaves agents stranded on failures.
GetAllItems
Recommendations
Expand tool descriptions from 10 - 80 chars to 50 - 200 chars. For each tool, answer: (1) What does it do? (2) When should the LLM use it instead of similar tools? (3) What does it return? Example: 'GetAllItems: Retrieve a complete list of all menu items in the inventory, including name, price, category, and availability status. Use this to show the customer the full menu or validate item existence before ordering. Returns an array of item objects ordered by category.'
Document the output schema for each tool. Specify: (1) return type (object, array, string, etc.); (2) field names and types for each object; (3) example response structure. Example: 'GetItemByName returns: {itemId: long, itemName: string, description: string, price: double, available: boolean, category: string, imageUrl: string}'
Add parameter descriptions for all nested object fields in AddNewItem. For each field ('itemId', 'itemName', 'price', etc.), specify: (1) what it controls; (2) required or optional; (3) valid values or format; (4) any defaults. Example: 'price: The menu item price in USD (decimal, 0.01 - 999.99). Required. Example: 12.50'
Implement error handling with recovery guidance. When AddNewItem fails (e.g. item name already exists), return: '{error: "Item already exists", details: "An item named \"Paneer Tikka\" is already in inventory. Use GetItemByName to fetch it or choose a different name.", retryable: false}' instead of a generic error.
Add pagination to GetAllItems. Define optional 'limit' (default 20, range 1 - 100) and 'offset' (default 0) parameters. Return: {items: [...], total: 150, limit: 20, offset: 0, hasMore: true}. This prevents context overflow when inventory is large.
AddNewItem tool lacks a confirmation or dry-run step. This is a destructive write operation that modifies inventory state. Agents can make mistakes, the tool should support a confirmation pattern or at least return detailed pre-commit validation.
Tool registration uses Spring AI's ToolCallbacks abstraction (itemMcpService.class → ToolCallbacks.from()), which hides the actual schema registration code. Cannot verify that all parameter descriptions, schema constraints, and required fields are present in the registered tool definitions. Per hard scoring rule: if tool definition is inferred rather than directly visible, cap per-tool score at 50. This limits confidence in schema completeness.
AddNewItem 'item' parameter has nested object schema with properties like 'itemId', 'itemName', 'price', etc., but parameter description does not explain what each nested field does, what format 'price' expects, or validation rules. The enum for 'category' is defined but other constraints are unclear.
GetAllItems returns all inventory items with no pagination support. Tool description does not specify result limits, which risks context window overflow if the inventory is large. Production tools cap results at 20-50 and offer pagination parameters.
GetAllItems
Implement a confirmation step or validation phase for AddNewItem before committing to the database. Return a dry-run result with the exact item that will be added, and require the agent to confirm before persistence. This prevents accidental inventory corruption.
Ensure all 4 tools declare any required permissions or scope (e.g. 'read:inventory' for GetAllItems, 'write:inventory' for AddNewItem) in their documentation, even if not enforced at the MCP layer. This enables future least-privilege configuration and audit trails.
Add dependency hints in tool descriptions. Example: 'GetItemByName requires an exact item name. If you only know the category, call GetItemsByCategory first to discover available names.' This guides agent planning and prevents wasted calls.
Validate parameter inputs early and return clear, actionable error messages. For category enum values, ensure the tool rejects invalid categories with: 'Invalid category: \"PIZZA_SLICE\". Must be one of: STARTER, MAIN_COURSE, DESSERT, BEVERAGE, SNACKS, SALAD, SOUP, ADD_ON, PIZZA, BURGER, SANDWICH, PASTA' instead of a 500 error or null response.