An MCP server that allows agents to propose, manage, and monitor product watches at online stores with user-approved spending limits. Agents can search stores, browse products, and create watches; only humans can authorize spending via passkey.
Capia demonstrates solid tool design with clear, action-oriented naming (propose_watch, confirm_watch, list_stores, etc.) and comprehensive descriptions (avg 180 chars, well above 10-char minimum). All 9 tools have input schemas with typed parameters and descriptions. However, output schemas are not explicitly documented in the visible code, responses are inferred from service layer calls. Parameter descriptions are generally good but lack explicit format constraints (e.g., UUID format for draft_id, variant_id, watch_id). Error handling is present but recovery guidance is minimal. Security model is sound (PAT-based auth, no secrets in params, scope checking), but tool annotations (readOnlyHint, destructiveHint) are absent despite clear risk classifications in the spec.
Browse what a store actually sells. Call with just the store to see a page of its catalog, or add what the user is looking for to narrow it. Read-only — nothing is watched or bought. Use this when the user asks what a store has, instead of telling them you can't look.
Cancel an active watch. The watch stops monitoring and no further purchases will be attempted.
Poll whether the human has approved the spending limit for a watch. Returns the watch status and mandate details if approved.
Create the watch from a draft after the user has chosen a candidate. Returns the approval URL — the HUMAN must open it and approve the spending limit with their passkey; nothing is watched or chargeable until they do.
Find which of Capia's stores sells something, when the user hasn't named a store. Say what they're after in their own words. May answer that none of them sell it — that is a real answer, not a failure, and should be relayed as-is rather than guessed around.
Output schemas not documented in tool definitions. Responses are inferred from service layer (e.g., _watch_summary returns dict with watch_id, item, store, status, etc.), but MCP tool definitions lack explicit return type schemas. LLMs cannot plan downstream operations without knowing response structure.
Tool annotations missing. Risk classifications are documented in spec (WRITE, READ_ONLY, REVERSIBLE) but not exposed as MCP tool annotations (readOnlyHint, destructiveHint, idempotentHint). Agents cannot distinguish safe from risky operations without reading descriptions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | 2026-07-28+ | v2 |
The stores Capia can buy from. Answer questions like 'what can I buy' or 'which stores are supported' with this rather than guessing — Capia is not a fixed catalog, but it is a fixed list of stores.
List all watches for the authenticated user, with their current status and details.
Start a watch from the user's request, passed verbatim. Returns either a clarifying question to relay to the user, a plain answer, or a draft with candidate products for the user to choose from.
Raise the spending limit on an existing watch. Returns an approval URL where the human must confirm the new limit with their passkey.
Parameter format constraints not explicit. UUID parameters (draft_id, watch_id, variant_id) lack format declarations. 'new_limit' in raise_cap lacks numeric range or currency format guidance. Descriptions should state 'UUID format' and 'numeric string in minor units' to prevent LLM hallucination.
Error recovery guidance minimal. AppException is raised with code and message, but tool descriptions do not guide LLMs on recovery (e.g., 'If you see forbidden, check agent token scopes'). Error responses should include actionable next steps.
Pagination not visible for list_stores and list_watches. If these return large result sets, no limit or offset parameters are documented. Tool descriptions should state result limits and pagination strategy to prevent context window exhaustion.