OrgLines

Purchase invoices: Create from file

purchase_invoice_create_from_file

A file the person attached in THIS chat is NOT available to you as bytes — never try to base64-encode it yourself (the call hangs and nothing arrives). Instead call this tool with NO file argument: after confirmation it returns a one-time upload link (status 'upload_link', 'url'); give it to the person, they drop the PDF on the page and reading starts by itself. Or, if they sent the file to @OrgLinesBot, pass its 'capture_id' (intake_list_captures). Reads a SUPPLIER's invoice (a bill the company received and must pay — not one it issues) into a review draft: supplier, VAT ID, IBAN, number, dates, totals by VAT rate, lines, reverse charge, each with a confidence, plus the matching supplier organization and possible duplicates. Other ways to name the file: 'document_id' (a personal document already stored), or 'content_base64' + 'filename' ONLY when your client really holds the file's bytes (≤ 2 MB decoded; PDF, JPG, PNG or HEIC). Reading takes about a minute: then purchase_invoice_list / purchase_invoice_get. Nothing is written to the books here — the person checks and confirms the draft on its review page (review_url). Runs propose→confirm. CONFIRMATION: this tool is PROPOSED, never performed directly. You get status='confirmation_required' with an action_id and a plan_token, and the write happens only after confirm_action.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "purchase_invoice_create_from_file"
  }
}

Input Schema

Name	Required	Description
`filename`	No
`capture_id`	No
`document_id`	No
`content_base64`	No	Only when you hold the real bytes; ≤ 2 MB decoded. Otherwise omit every file argument to get an upload link.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Beyond the annotations it discloses the key behavioral traits: nothing is written to the books, a draft is produced for human confirmation on review_url, the call takes about a minute, a 2 MB decoded limit applies, and self-encoding a chat attachment causes a hang. It also explains the propose→confirm protocol with status='confirmation_required', action_id and plan_token. Slight deduction only because the confirmation mechanics are restated rather than compressed.

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?

Front-loaded with the highest-value warning (never self-encode a chat attachment), and nearly every clause carries operational information. It is dense to the point of being sprawling, with long parenthetical chains and mixed capitalization, but little is genuinely removable.

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

Completeness4/5

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

No output schema exists, yet the description describes the return payload (draft fields with confidences, matched supplier organization, duplicates, upload_link/url, review_url) and the confirmation state, so an agent can act end-to-end. The only soft spot is the absence of any explicit statement about what happens on unreadable or unsupported files.

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

Parameters5/5

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

Schema coverage is only 25%, but the description compensates fully: capture_id is sourced from intake_list_captures, document_id means an already-stored personal document, content_base64 requires filename and real client-held bytes under the size and format constraints, and omitting all file arguments is itself the meaningful upload-link path.

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?

States a specific verb and resource ('Reads a SUPPLIER's invoice ... into a review draft') and explicitly disambiguates the domain object — a bill the company received, not one it issues — against the sibling invoice_* family. It also enumerates the extracted fields, so an agent knows exactly what it produces.

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

Usage Guidelines5/5

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

Gives explicit routing: do NOT base64-encode a chat attachment; call with no file argument to get a one-time upload link, or pass capture_id when the file went to the bot, or document_id for a stored personal document, or content_base64+filename only when the client truly holds bytes. It also names the follow-up tools (purchase_invoice_list / purchase_invoice_get) and the confirm_action hand-off.

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

All OrgLines tools Inspect

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

Need Help?