Loading ToolBench
MCP server for ReceiptConverter — parse any receipt or invoice into structured JSON with one tool call
ReceiptConverter MCP exposes two tools with basic definitions but significant quality gaps. Tool naming is adequate (verb-noun convention), but parameter descriptions are sparse, input schemas lack required field validation, and output structure is not formally documented. The convert_receipt tool accepts either url or file_path but does not enforce this constraint in the schema (no oneOf or required array logic visible). The check_usage tool has an empty inputSchema with no parameters to describe. Error messages in implementation are actionable (e.g., 'Invalid API key', 'Rate limit reached'), but the tool definitions themselves do not document error conditions or recovery paths for the LLM. Output is rich (structured JSON from the API) but the tool definition does not formally declare the output schema, forcing LLMs to infer structure from the summary text.
Check the current API key's remaining conversions for this month, the plan name, and the monthly limit.
Parse a receipt or invoice image/PDF into structured JSON. Returns vendor name, date, total, subtotal, currency, payment method, expense category, individual line items, taxes, and tip. Accepts a public URL or a local file path. Supported formats: JPG, PNG, WEBP, HEIC, TIFF, BMP, PDF (text-based).
convert_receipt: inputSchema does not enforce mutual exclusivity (url XOR file_path) or require at least one. Schema defines both as optional with no constraint. The description says 'Provide either url or file_path' but JSON Schema does not enforce this; LLMs may pass both, neither, or invalid combinations, triggering runtime errors.
convert_receipt: inputSchema lacks type annotations for url and file_path beyond 'string'. No minLength, maxLength, format, or pattern constraints are declared. This invites LLMs to pass malformed URLs, relative paths, or excessively long strings without validation guidance.
Both tools: no output schema documented in the tool definition. convert_receipt returns structured JSON with vendor, date, total, items, etc., but the inputSchema does not declare an outputSchema. LLMs cannot introspect what fields to expect; they rely on reading the summary text in the response, which is inefficient and error-prone for downstream tool composition.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 50 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 42 | - | v1 |
check_usage: inputSchema is an empty object with no properties. The tool takes no parameters, which is correct, but the description does not hint at any prerequisites (e.g., 'Requires valid RECEIPTCONVERTER_API_KEY') or explain what 'remaining conversions' means in context (daily? monthly? rolling?). Description length is 134 chars (within the 10-1024 guideline) but lacks operational detail.
convert_receipt: no error conditions documented in the tool definition. The implementation handles 401 (invalid API key), 429 (rate limit), and file-not-found, returning actionable messages. However, the tool description does not warn the LLM about these failure modes or suggest recovery steps (e.g., 'If you get a rate limit error, check_usage() and wait before retrying').
convert_receipt file_name parameter: description says it is 'used when saving to the ReceiptConverter dashboard' but does not clarify whether it is required, what format is expected, or whether it defaults to the actual filename. An LLM might omit it or pass invalid characters without guidance.