MCP server for OurGroceries.com grocery list management
OurGroceries MCP has clear, action-verb naming and complete input schemas with proper types and descriptions. All 5 tools follow verb_noun convention (get_lists, add_item, remove_item, update_item, toggle_item). Descriptions are present and adequate (range 40 - 90 chars), though some lack context about when to use them or what they return. Parameter descriptions are consistently provided. Critical gap: NO output schemas documented, LLMs cannot predict response structure for chaining. No error handling guidance. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk profiles (READ_ONLY, WRITE, DESTRUCTIVE, REVERSIBLE). Schemas are well-formed with required fields and defaults, but lack examples of actual API responses.
Add a new item to a grocery list. You can optionally add a note.
Get all grocery lists with their items. Returns list names, IDs, and all items with their status.
Remove an item from a grocery list
Mark an item as crossed off or uncrossed
Update an item's details (name, category, note, or star rating)
No output schemas documented. LLMs cannot predict response structure (field names, types, nesting) for downstream tool calls or data extraction. Breaks tool chaining.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk profiles. Agents cannot distinguish safe retries from destructive operations.
No error handling guidance. Responses do not tell LLMs what to do on failure (retry, ask user, abort). Raw API errors will confuse agents.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
remove_item and toggle_item descriptions lack context about consequences. 'Remove an item' does not clarify if this is reversible or permanent. Agents need to know before executing.
No confirmation or dry-run pattern for destructive operations (remove_item). Agents can accidentally delete items without safeguards.