Loading ToolBench
A local MCP server that manages personal pantry data (inventory, preferences, meal plans, shopping lists) with security-by-architecture: local SQLite storage, input validation, parameterized SQL, audit logging, and narrow tool surface.
PantryVault has solid naming conventions (verb_noun pattern) and comprehensive input validation. All 11 tools have descriptions and schemas. However, descriptions are inconsistent in depth, some lack context on WHEN to use them or WHY they matter. Parameter descriptions are present but generic (e.g., 'Item name (1-80 chars...)' repeats across tools). Output schemas are not documented, callers must infer structure from code. Error handling is basic (ValueError messages) with no recovery guidance. No tool annotations (readOnlyHint, destructiveHint) despite clear risk levels. Audit logging is a security plus, but the tool surface could be more composable.
Add an item to the pantry, or increase its quantity if it already exists. Units: g, kg, ml, l, piece, pack, can, jar, bottle.
Reduce the quantity of a pantry item (e.g. after cooking). Removes the item entirely when the quantity reaches zero.
Retrieve the audit log of all tool invocations (tool name and timestamp only, no arguments or sensitive data).
Retrieve the most recently saved meal plan.
Retrieve the most recently saved shopping list.
Get the user's stored preferences: allergies, diet, dislikes, weekly budget (EUR), household size, preferred stores.
Output schemas not documented. Tools like list_pantry, get_preferences, get_latest_meal_plan return JSON but callers must infer structure from code. LLMs cannot plan downstream calls without knowing response fields.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Tools have clear risk levels (READ_ONLY, WRITE, DESTRUCTIVE) but these are not exposed in the MCP schema, preventing clients from rendering warnings or enforcing safety policies.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 51 | 2026-07-28+ | v2 |
List every item currently in the pantry with quantity and unit.
Delete an item from the pantry completely (e.g. expired food).
Save a weekly meal plan with week label and plan JSON mapping days to meals and ingredients.
Save a shopping list with items, quantities, units, and optional store grouping.
Store or update one preference. Allowed keys: allergies, diet, dislikes, budget_eur, household_size, stores.
Descriptions lack WHEN/WHY context. E.g., 'Get the user's stored preferences' does not explain when to call it vs set_preference, or what to do with the result. Descriptions should guide LLM selection and downstream reasoning.
Error handling is minimal. ValueError messages like 'Invalid item name (1-80 chars...)' are actionable but do not guide recovery. No distinction between retryable vs user-fixable errors. Destructive tools (remove_pantry_item) lack confirmation or dry-run support.
JSON string parameters (plan_json, list_json) are error-prone. Agents must construct valid JSON strings, risking syntax errors. Consider accepting structured objects (arrays/dicts) instead, letting the framework serialize.