Skip to main content
Glama

PaperOffice AI

by ai.paperoffice.mcp
OverviewDiscussionsAdmin

Extraction Invoice

po_extraction_invoice

WRITES DATA. Creates or changes data in the workspace. Extract invoice fields from a document (starts a job). May reach systems outside PaperOffice.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modelNoAI processing tier (flat pricing). Basic=OCR+Vision, Premium=+AI Thinking, Ultra=+AI Reasoning. per/per-Max variants add higher page limits.premium
pofidNoPaperOffice File ID of an existing document in the DMS. Alternative to upload_id/file_url — exactly one file input is required.
file_urlNoDirect URL to download the file from. Alternative to upload_id/pofid — exactly one file input is required.
priorityNoLEGACY queue weight (numeric). Prefer processing_lane (Start-SLA). If processing_lane is set, the lane wins. Do not use as the public SLA product.
upload_idNoUpload ID from po_documents_upload_url_get (preferred file input method). Exactly one file input is required: upload_id, file_url or pofid.
async_onlyNoForce async: same as client_wait=false. Returns job_id immediately; poll GET /job/get/{job_id}.
idp_fieldsNoOPTIONAL: Additional fields as JSON, e.g., {"key":"has_stamp","description":"Is there a stamp?"}
client_waitNoConnection hold: true (default) = API holds this HTTP request while the job runs, up to the dynamic pipeline timeout (priority, pages, pipeline type; minimum about 20s, infrastructure cap about 295s). Returns the finished result when ready, or HTTP 202 with job_id and poll_url if the hold is exceeded. false = immediate job_id.
idp_collectionNoIDP template name. Default: invoice (English). For localized versions use the dedicated tools (e.g. the German/DATEV-optimized extraction profile in Document AI). Advanced: append :lang:LOCALE for custom localization e.g. invoice:fr:FRinvoice
processing_laneNoStart-SLA lane (wait-to-start guarantee, not completion). Values: no_sla (fair use ×1), sla_24h (×1.5), sla_12h (×2), sla_6h (×3), sla_1h (×4), instant (×5 interactive start). Prefer this over legacy numeric priority. If omitted: workspace default_processing_lane, else no_sla.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.5/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds 'May reach systems outside PaperOffice' and the 'WRITES DATA' warning, which align with annotations (readOnlyHint=false, openWorldHint=true). However, it does not provide deeper context like the async workflow or job polling, which are covered in the schema. The bar is lowered due to annotations, so the added external-reach note earns a 3.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, with two sentences, and front-loads the 'WRITES DATA' warning before stating the purpose. While the 'WRITES DATA. Creates or changes data in the workspace.' prefix is somewhat generic and redundant with annotations, it is not verbose. The core purpose is efficiently stated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 10 parameters and no output schema, the description is too sparse. It does not explain how the agent should handle the job lifecycle (e.g., when to poll, what the result looks like, or how to interpret job_id vs. immediate result). The schema covers parameters, but the description leaves out critical workflow guidance for a job-based tool, making it incomplete for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description does not add meaning beyond what the schema already provides for parameters. The schema details client_wait, async_only, idp_collection, etc., so the description adds no additional semantic value for parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's action: 'Extract invoice fields from a document (starts a job).' This specifies a specific verb, resource (invoice fields), and the asynchronous nature. It distinguishes itself from siblings like po_documents_text_get by focusing on invoice extraction rather than generic text retrieval.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for extracting invoice fields but does not explicitly mention when to use this tool over alternatives. It lacks exclusions or references to sibling tools. The parameter schema mentions localized alternatives, but that's not in the main description, so the agent gets no explicit guidance on selecting this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All PaperOffice AI toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources