MCP server that converts PDF documents to structured JSON. Supports invoices, bank statements, contracts. Uses an AI model (OpenAI-compatible LLM) for extraction with pay-per-call pricing via x402 protocol (USDC on Base).
Server has 5 tools with basic descriptions and input schemas, but significant quality gaps. All tools accept file_url (string) and language (string) parameters with descriptions present. However, output schemas are not documented in tool definitions, only internal LLM schemas (INVOICE_SCHEMA, BANK_STATEMENT_SCHEMA) exist but are not exposed to the MCP client. Descriptions are functional but generic (avg ~60 chars), lacking WHEN/WHY guidance. No error handling guidance, no parameter constraints (enums, ranges), no idempotency hints. Tool names follow verb_noun pattern (parse_*, supported_*) which is good, but lack specificity about what 'parse' returns. No tool annotations (readOnlyHint, destructiveHint). The supported_document_types tool has empty input schema but no description visible in source.
Extract transactions from bank statement PDFs
Extract clauses and metadata from contract PDFs
Extract text and tables from any PDF
Extract structured data from invoice PDFs
List available document types (free)
Output schemas not documented in tool definitions. Internal LLM schemas (INVOICE_SCHEMA, BANK_STATEMENT_SCHEMA) exist but are not exposed to MCP clients. LLMs cannot plan downstream operations without knowing what fields to expect.
No error handling guidance. Tools do not document what errors can occur, whether they are retryable, or what the LLM should do next. E.g., what happens if file_url is unreachable, PDF is corrupted, or OCR fails?
Parameter 'language' lacks constraints. Description says 'e.g. eng+ita+spa' but does not specify valid language codes, format rules, or what happens if an invalid code is passed. Should be an enum or regex pattern.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 50 | <=2025-11-25 | v2 |
Descriptions are generic and lack WHEN/WHY guidance. 'Extract structured data from invoice PDFs' does not explain when to use parse_invoice vs parse_generic_document, what confidence threshold is acceptable, or what fields are guaranteed vs optional.
No tool annotations. Tools lack readOnlyHint (all are read-only), destructiveHint (none are destructive), or idempotentHint. This prevents clients from optimizing caching and retry logic.