Extract invoices, receipts and contracts into structured JSON. EU-hosted, per-field confidence.
Scored across 5 tools
Each tool has a clearly distinct purpose: account status (check_balance), type detection (classify_document), extraction (extract_document), schema discovery (list_schemas), and removal (delete_document). There is no overlap between classification and extraction since the descriptions explicitly distinguish them as cheap pre-step vs. full structured output.
All five tools follow a strict verb_noun snake_case pattern: check_balance, classify_document, delete_document, extract_document, list_schemas. No deviations or mixed conventions.
Five tools is a tight, well-scoped surface for a document extraction API, with each tool earning its place across the intake, schema, execution, and cleanup steps. Nothing appears redundant or padding the count.
The core lifecycle is covered: inspect quota, discover schemas, classify, extract, and delete. However, there is no way to retrieve or re-fetch a previously extracted result by id, which matters for plans that retain documents, so a minor gap remains.
This API key's plan, remaining credits and usage counters. Run before large batches to avoid running out mid-job.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It usefully scopes the result to the calling API key (not an org or workspace) and enumerates the returned fields, which is real value beyond the empty schema. It never states that the call is read-only/side-effect free, nor anything about auth, rate limits, or cost of calling, which leaves gaps for a no-annotation tool.
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?
Two short sentences with no filler, and the payload (what is returned, then when to call it) is front-loaded. Slight deduction because the opening is a sentence fragment that reads as a caption rather than a statement of purpose.
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 zero-parameter read tool with no output schema, the description supplies what is needed: it lists the returned fields (plan, credits, usage counters) and key scoping. It stops short of stating safety/read-only semantics, but an agent has enough to invoke it correctly.
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?
The tool takes zero parameters, so the schema fully specifies the call and there is nothing for the description to disambiguate. Baseline of 4 applies; the description correctly avoids inventing inputs.
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 names the exact resource it inspects — this API key's plan, remaining credits, and usage counters — so an agent knows precisely what it gets back. It is a noun-phrase fragment rather than a verb+resource statement (the verb lives only in the title), but the intent is unambiguous. Siblings (classify_document, delete_document, extract_document, list_schemas) are unrelated, so no differentiation is required.
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?
"Run before large batches to avoid running out mid-job" is explicit, actionable when-to-use guidance tied to a concrete scenario. It does not name alternatives or exclusions, but none of the sibling tools are plausible substitutes, so the missing routing is not a real gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect the document type (receipt, invoice, contract, lease, …) without extracting fields. Cheap first step when you don't know which schema to use.
| Name | Required | Description | Default |
|---|---|---|---|
| file_name | No | Original file name, e.g. 'invoice.pdf' (helps type detection). | |
| mime_type | No | MIME type if known, e.g. 'application/pdf', 'image/jpeg'. Inferred from file_name otherwise. | |
| file_base64 | Yes | The document bytes, base64-encoded. PDF, image (PNG/JPG/WEBP) or text file. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries the full load, and it does disclose two real traits: no field extraction happens, and the call is cheap (implying a cost gradient vs. extract_document). It omits idempotency, data-handling/auth requirements, and any rate or size limits, which matters for a tool that ingests raw document bytes.
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?
Two tight sentences, front-loaded with the action and its distinguishing constraint, then the usage cue. Nothing is redundant or padded.
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?
There is no output schema, so the description should say what comes back — a single label, a label plus confidence, the set of possible types — and it only offers an open-ended example list with '…'. Combined with zero annotations, the definition is usable but leaves the return contract and failure modes unspecified.
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 100%: file_base64, file_name and mime_type each have their own descriptions, including the detection hint for file_name and the inference fallback for mime_type. The description adds nothing parameter-level, so the baseline 3 applies.
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?
Specific verb ('Detect') plus resource ('document type') with concrete examples (receipt, invoice, contract, lease). The clause 'without extracting fields' explicitly separates it from the sibling extract_document, so an agent can distinguish them without opening either schema.
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?
'Cheap first step when you don't know which schema to use' gives a clear triggering condition and implies the follow-on path (list_schemas / extract_document). It stops short of naming the alternative tool or stating when not to use it, so it is strong but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete one stored document and its extraction data by id, where the plan retains documents. Mervext already discards by default; this is for explicit 'forget it now' requests.
| Name | Required | Description | Default |
|---|---|---|---|
| document_id | Yes | The document id returned by extract_document. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose the key destructive facts: the operation is permanent and removes both the document and its extraction data. It also reveals the conditional 'where the plan retains documents' behavior. It omits auth/scope requirements and what happens if the document was already discarded.
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?
Two tight sentences with the destructive verb and scope front-loaded, and the second sentence earns its place by explaining when the tool is warranted. The trailing clause 'where the plan retains documents' is slightly cryptic and could have been phrased more plainly.
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 one-parameter destructive tool with no annotations and no output schema, the description covers the essentials: permanence, what data is destroyed, and the explicit-request condition. Missing only error/edge behavior and confirmation expectations, which are minor here.
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 coverage is 100% and the single parameter is already documented as 'the document id returned by extract_document'; the description only echoes 'by id'. Baseline 3 applies since the schema does the heavy lifting and the description adds no format or source detail beyond it.
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?
States a specific verb and resource ('Permanently delete one stored document and its extraction data') plus a scoping condition ('where the plan retains documents'), so the agent immediately knows this is an irreversible delete of a document row and its derived extraction. It does not name any sibling tool, but no sibling could be mistaken for a delete, so differentiation is implicit rather than stated.
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 second sentence gives a clear selection rule: default retention already discards, so this tool is only for explicit 'forget it now' requests. That effectively communicates when not to call it, though it names no alternative tool and does not spell out prerequisite permissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send one document (PDF, photo, or text) and receive structured JSON with per-field confidence and source grounding. Use a built-in schema name (see list_schemas, e.g. 'invoice', 'receipt') or pass your own draft-07 JSON Schema as schema_json. Processing runs in the EU on Vertex; documents are not retained. Photos can take a while — allow generous timeouts.
| Name | Required | Description | Default |
|---|---|---|---|
| schema | No | Built-in schema id, e.g. 'invoice' or 'receipt'. Mutually usable with schema_json (schema_json wins). | |
| file_name | No | Original file name, e.g. 'invoice.pdf' (helps type detection). | |
| force_ocr | No | Force OCR even when a text layer is detected. Leave off unless the text layer is garbage. | |
| mime_type | No | MIME type if known, e.g. 'application/pdf', 'image/jpeg'. Inferred from file_name otherwise. | |
| file_base64 | Yes | The document bytes, base64-encoded. PDF, image (PNG/JPG/WEBP) or text file. | |
| schema_json | No | Custom JSON Schema (draft-07) as a string, for anything beyond the built-ins. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description must carry behavioral burden. It discloses that processing runs in the EU on Vertex, documents are not retained, and that photos can take a while (timeout guidance). It doesn't mention rate limits, auth needs, or error handling, but the privacy and performance disclosures are valuable and non-obvious.
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?
Three sentences, front-loaded with purpose and output, then schema options, then operational notes. Efficient, though the final sentence about timeouts is slightly tangential but useful. No wasted words.
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 no annotations, no output schema, and 6 parameters, the description covers output structure ('per-field confidence and source grounding'), schema usage, and operational constraints. It's fairly complete, though it could mention what happens on failure or how to handle large files, but overall adequate.
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 coverage is 100%, so all parameters are documented in the schema. The description adds meaning by explaining the relationship between schema and schema_json ('using built-in or custom') and hints at timeout, but doesn't provide additional parameter syntax beyond what the schema already gives. Baseline 3 is appropriate.
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?
States a specific verb+resource ('Send one document... receive structured JSON') and the exact output shape (per-field confidence and source grounding). This distinguishes it from sibling classify_document (which likely returns a label) and list_schemas (which lists schemas). Very clear.
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?
Gives clear context: use for extraction with built-in schema names or custom schema_json. Names list_schemas as related. However, it doesn't explicitly contrast with classify_document (when to classify vs extract), which is a sibling that could be confused.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the built-in document schemas (id + what each one extracts). Pass a schema id to extract_document, or go custom with schema_json.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the return contents (ids and their extraction targets) and that it is a read-style discovery call, but says nothing about whether schemas are static, workspace-scoped, or whether any auth is needed.
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?
Two short sentences, zero filler, with the core purpose front-loaded and the workflow hint following immediately. Every clause earns its place.
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 zero-parameter, no-output-schema listing tool, the description covers both what is returned and how the result is consumed downstream. Only minor gaps (scope of 'built-in', static vs dynamic) remain.
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?
The schema has zero parameters, so the baseline is 4. The mentions of 'schema id' and 'schema_json' refer to other tools' inputs rather than this tool's arguments, so there is nothing further to document.
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?
Specific verb ('List') plus resource ('built-in document schemas') and it even previews the return shape ('id + what each one extracts'). Sibling tools are all document operations, so there is no real ambiguity, though it does not explicitly contrast itself with them.
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 second sentence gives concrete workflow context: use a returned schema id with extract_document, or fall back to schema_json for custom schemas. That is clear usage context, but there is no explicit 'when not to use' or prerequisite statement.
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.
check_balanceclassify_documentdelete_documentextract_documentlist_schemasConvert documents to structured JSON (invoices, receipts, contracts) in 2 seconds
Extract, search and tag any document: invoices, receipts, contracts, templates. OAuth or API key.
Extract structured data from Bills of Lading: parties, ports, containers, incoterms. EU-hosted.
Turn PDFs, scans and photos into a queryable database. Invoices, CVs, receipts, in bulk.
Add one secure layer between your agents and this server.
