Loading ToolBench
A local digital receipt platform MCP server that connects to bank accounts via Plaid, processes receipt images through OCR, and matches receipts to transactions. Privacy-first with all data staying local on the user's machine.
Vero MCP has 21 well-named tools with consistent verb_noun patterns (connect_, get_, create_, add_, remove_, match_, etc.). All tools have descriptions (avg ~120 chars, within baseline 34-392 range). Input schemas are present and mostly complete with type definitions and enums. However, output schemas are NOT documented, responses are JSON-serialized but the structure is not declared in tool definitions. Parameter descriptions are adequate but some lack format/constraint details. Error handling returns generic error strings without recovery guidance. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk classifications in the spec.
Assigns a label to a transaction or receipt.
Adds a note to a transaction or receipt.
Scans a directory for receipt files (jpg, png, gif, webp, heic, pdf) and processes each one through OCR and auto-matching. Returns a summary of succeeded and failed receipts.
Confirms an auto-suggested receipt-to-transaction match. Use when the system suggested a match and the user agrees it's correct.
Creates a Plaid Link session and returns a URL for the user to connect their bank account in a browser. After the user completes the flow, the account is automatically linked.
Creates a new label for organizing transactions and receipts.
Output schemas not documented. Tools return JSON-serialized objects (via json.Marshal) but the response structure is not declared in tool definitions. LLMs cannot plan downstream calls or extract fields without seeing the schema.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Tools are classified with Risk levels (READ_ONLY, WRITE, DESTRUCTIVE, REVERSIBLE) in the spec but not exposed via MCP tool annotations. Agents cannot infer safety/idempotency from the protocol.
Error handling lacks recovery guidance. Handlers return generic error strings (e.g., 'failed to list labels: %v') without actionable next steps. LLMs cannot self-correct or know whether to retry, ask the user, or abort.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | <=2025-11-25 | v2 |
Deletes a note by its ID.
Disconnects a bank account. Note: this removes the entire institution connection, so all accounts under the same institution will be disconnected. Only call this once per institution.
Returns the user's connected bank accounts with balances and account details.
Gets all notes for a transaction or receipt.
Returns line items for a receipt.
Returns the user's receipts with optional filters. Includes match status, OCR-extracted data, and linked transaction info.
Syncs latest transactions from Plaid and returns them. Supports filtering by search text, date range, amount range, category, matched/unmatched status, and pending status.
Returns a consolidated snapshot of the user's identity and current integration state, including bank connection status and profile info. Use this to understand what the user has set up before suggesting actions.
Creates a receipt upload session and returns a URL for the user to upload a receipt in their browser (image formats jpg, png, gif, webp, heic, or PDF). Before showing the URL, explain to the user that you cannot process files directly and they need to upload it through the provided link. After showing the URL, immediately call wait_for_receipt_upload with the returned session_id to get the OCR and matching results.
Lists all labels created by the user.
Manually matches a receipt to a specific transaction. Use this when automatic matching didn't find the right transaction or when the user wants to link a specific receipt to a specific transaction.
Rejects an auto-suggested receipt-to-transaction match. Use when the system suggested a match but the user says it's wrong. The rejection is permanent — that receipt is never suggested against that transaction again.
Removes a label from a transaction or receipt.
Removes an existing association between a receipt and a transaction.
Waits for a receipt image upload to complete. Call this after ingest_receipt_image once the user has been given the upload URL. Blocks until the user uploads the image or the session times out (5 minutes).
Parameter descriptions lack format/constraint details. E.g., 'date_from' and 'date_to' say 'YYYY-MM-DD' but do not specify if they are required, what happens if invalid, or if they are inclusive/exclusive. 'amount_min' and 'amount_max' lack numeric bounds.
wait_for_receipt_upload blocks for up to 5 minutes. No timeout parameter or guidance on handling hung sessions. Agents may stall indefinitely if the user does not complete the upload flow.