Checks UBL invoices against purchase details and recalculates totals. $0.05 USDC per call on Base.
Scored across 1 tool
There is only one tool, so an agent cannot confuse it with another. Its purpose is clearly described as a paid UBL invoice preflight check.
The single tool name 'invoice_preflight' is descriptive, lowercase, and consistently styled. With one tool there are no naming conflicts or mixed conventions.
One tool feels thin and provides no supporting operations or alternatives. It fits a narrowly scoped checker, but the surface is minimal.
The tool covers the core preflight validation and returns evidence, amount checks, and review statuses. However, it only supports UBL XML, defers PDF/OCR support, and explicitly excludes payment or bookkeeping actions, leaving notable gaps for broader invoice workflows.
Paid invoice check ($0.065 USDC on Base): UBL XML, public HTTPS PDF/image URL, or base64 PDF/PNG/JPEG. Returns evidence, amount checks and match/discrepancy/needs_review. No payment or bookkeeping action is taken.
| Name | Required | Description | Default |
|---|---|---|---|
| expected | No | ||
| mime_type | No | ||
| document_url | No | ||
| document_xml | No | ||
| document_base64 | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It reveals that the operation costs $0.065 USDC on Base, that it returns evidence and status labels, and that it takes no payment or bookkeeping action. This effectively communicates the non-mutating nature and the fee without contradicting any structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The key cost and input facts are front-loaded, output behavior follows, and the important 'no payment or bookkeeping action' clarification is included at the end. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a nested expected object, five parameters, no output schema, and no annotations, the description is missing meaningful detail about how to supply expected amounts and how the document input modes relate to mime_type. It covers fee, inputs, and outcomes well, but is not fully complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does map document formats to the likely document_xml, document_url, and document_base64 parameters, but it says nothing about the nested 'expected' object with fields like tax, total, subtotal, currency, supplier_name, and purchase_order, which are central to the 'amount checks' behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly names the operation ('Paid invoice check'), the resource (invoice), and immediately specifies the accepted input forms and expected outputs. It also states what the tool does not do, removing ambiguity about its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for invocation: it is a paid preflight validation step with a fee, identifies accepted document formats, and explicitly excludes payment or bookkeeping actions. It does not name alternatives, but no siblings exist, and the usage context is otherwise explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
invoice_preflight4 fields changedInput schema / properties / document_base64Added value: +{
+ "maxLength": 13500000,
+ "minLength": 4,
+ "type": "string"
+}Input schema / properties / document_urlAdded value: +{
+ "format": "uri",
+ "maxLength": 2048,
+ "type": "string"
+}Input schema / properties / mime_typeAdded value: +{
+ "enum": [
+ "application/pdf",
+ "image/png",
+ "image/jpeg"
+ ],
+ "type": "string"
+}Input schema / requiredRemoved value: -[
- "document_xml"
-]invoice_preflightChecks certificates of insurance (ACORD 25) against your requirements. Pay per call, x402 USDC.
Validate, generate & convert EU e-invoices (UBL, CII, XRechnung, Factur-X) — EN 16931 pre-validated.
Serbia SEF eFaktura invoices for AI agents: build UBL 2.1 SRB-CIUS, upload to SEF, query, cancel.
Repair malformed JSON, DNS lookup, extract URLs, base64, case, hash, time. Pay per call USDC Base.
Add one secure layer between your agents and this server.