Loading ToolBench
MCP server for the Meticulous home espresso machine — recipe generation, shot history, and machine control for Claude Code
The server exposes a single tool, `update_profile`, with a clear verb-noun naming convention and a comprehensive description. However, the tool definition relies on inline parameter inference from source code rather than explicit schema registration visible in the MCP tool setup, and the input schema uses a generic 'object' type for the 'updates' parameter without detailed field constraints. The server demonstrates solid engineering practices (UUID validation, profile merging, image preservation) but lacks structured output schema documentation and error recovery guidance expected at higher tiers.
Update an existing profile in place by ID. Fetches the current profile, merges your changes on top, and saves back — preserving the profile image and avoiding duplicates. Pass only the fields you want to change in `updates`; everything else is kept from the existing profile.
Input schema for 'updates' parameter uses generic 'object' type without field-level constraints or documentation. LLMs cannot know which profile fields are writable, mutable, or forbidden (e.g., 'id' is always preserved per description but not explicitly forbidden in schema).
No output schema documented. Tool description does not specify what the API returns after a successful profile update (e.g., does it return the updated profile? A confirmation? Just a status code?). LLMs cannot plan downstream operations without knowing the response structure.
Error handling lacks recovery guidance. No documented errors, retryable conditions, or actionable next steps for LLMs when validation fails (e.g., invalid profile_id, malformed updates). Code validates profiles but error responses are not visible in tool definition.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Parameter 'updates' description includes example JSON ('e.g. { "temperature": 91 }') which may cause LLMs to reuse those literal values rather than adapt to user intent.
Specification of immutable fields buried in 'updates' parameter description ('The profile id and display.image are always preserved'). A machine-readable constraint (e.g., forbidden fields in schema, or separate immutable_fields list) would be clearer for LLMs and tooling.