No-wallet, no-spend MCP quickstarts for Ardaro receipt checks and invoice matching. Provides canonical-schema MCP client adapters and framework verification examples.
This server has critical definition gaps. All 4 tools lack parameter descriptions entirely, the rubric requires descriptions for every parameter to score above 0-20 on description. Three tools (get_receipt_example, get_invoice_matching_example, get_invoice_matching_service_status) have empty input schemas with no properties, making them trivial. The match_invoice tool has only one parameter (contract_version) with a description, but no description of what the tool itself does beyond a vague reference to 'payment'. Tool names are verb-prefixed (good), but descriptions are too brief (10-50 chars) and lack WHEN/WHY context. No output schemas are documented. Error handling is absent, no guidance on retryability, user-fixable errors, or recovery paths. This is a minimal fixture/demo server, not production-grade.
Returns a fixed synthetic invoice matching example with no payment required
Returns the current status and pricing information for the invoice matching service
Returns a fixed synthetic receipt analysis example with no payment required
Analyzes and matches invoice data. Requires payment for actual processing beyond the free synthetic example.
All tools lack output schema documentation. LLMs cannot plan downstream calls or extract fields without knowing the response structure.
Three tools (get_receipt_example, get_invoice_matching_example, get_invoice_matching_service_status) have empty input schemas with no properties and no descriptions.
Tool descriptions are too brief (10-50 chars) and lack actionable context. 'Returns a fixed synthetic receipt analysis example' does not explain WHEN to call it or what it returns. Rubric baseline: 194 chars average, 10-1024 char range.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 44 | 2025-06-18+ | v2 |
match_invoice parameter 'contract_version' has a description but the tool itself lacks a clear description of what it does, when to use it, and what it returns. No error guidance for payment failures or invalid contract versions.
No error handling patterns implemented. Tools do not indicate retryability, user-fixable errors, or recovery steps. Agents cannot distinguish between transient failures and permanent errors.