Remote MCP integration

Use a compatible MCP client to submit an explicitly selected invoice, retrieve its result, or read finalized account usage.

Not available yet. The MCP endpoint is not enabled. This guide describes the planned integration; the endpoint, account linking and supported clients may change before it launches.

Connect

The planned endpoint is https://api.temlavo.com/mcp, using Streamable HTTP. The implementation targets MCP 2026-07-28 and SDK-provided stateless compatibility for 2025-11-25 and 2025-06-18. No separate SSE endpoint is required.

Interactive clients use the configured OAuth provider and an existing Temlavo account. Granted permissions separately cover document submission, document reading, and usage reading. Server-side custom clients can instead configure their existing Temlavo API key in a secret store and send it as a Bearer header. Never paste a key into chat. OAuth tokens issued for MCP do not authenticate the REST API.

Read usage independently

Code example

get_usage {}
get_usage {"periods_ago":1}
get_usage {"accounting_entity_id":"client-a"}

Empty arguments retrieve the current period. The optional history control is a positive JSON integer selecting a retained closed period, not necessarily a calendar month. Entity attribution adds a count alongside unchanged pooled account totals.

Usage counts finalized processed pages across integrations, excluding pending work. It reports included, used, remaining and overage pages; it is not a bill, payment-status check or capacity reservation. Do not use it as an automatic submission preflight. No invoice upload is needed.

Submit one invoice

Code example

{
  "file": {
    "download_url": "https://files.example/invoice.pdf?signature=REDACTED",
    "file_id": "stable-client-file-reference"
  },
  "idempotency_key": "generate-once-and-retain-for-retries",
  "policy": {
    "required_fields": [
      "/data/invoice/purchase_order_number"
    ],
    "line_items": "review_on_failure"
  }
}

Call submit_invoice with one authorized final HTTPS download URL and a stable opaque file reference. The client generates and retains one submission key for retries. A refreshed signed URL can use the same key and file reference. Once accepted, replay returns the existing document without fetching the old URL. Conflicting options or different bytes cannot replace a bound submission.

This tool creates account state and intentional new submissions can consume allowance or billable usage under the existing account plan. Processing remains asynchronous. A missing required purchase order produces a review finding when a usable result exists.

References are application inputs; MCP does not universally transfer attachments. A client unable to supply authorized direct file access must use its supported upload mechanism or the REST upload flow. URLs are limited to 8,192 characters, file references to 512. Redirects, credentials in URLs, private network addresses, arbitrary source headers, base64 and multipart inputs are rejected.

Retrieve results and recover

Code example

get_invoice_result {"document_id":"doc_0123456789abcdef0123456789abcdef"}
get_invoice_result {"document_id":"doc_0123456789abcdef0123456789abcdef","view":"fields"}
get_invoice_result {"document_id":"doc_0123456789abcdef0123456789abcdef","view":"line_items","offset":0,"limit":25}
get_invoice_result {"document_id":"doc_0123456789abcdef0123456789abcdef","view":"checks","offset":0,"limit":25}

Summary is the default and labels omitted details and findings. Full returns the unchanged REST resource when it fits. For large results, fields plus every line-item and check page reconstruct the stored result through the same MCP authorization. Follow the returned next offset; pages may contain fewer items than requested. The default page size is 25 and maximum is 100.

The application envelope is limited to 64 KiB and the encoded MCP response to 256 KiB. An indivisible oversized value cannot be paginated; full REST retrieval then requires separate ordinary API-key credentials. No public result URL is created.

Pending results include retry guidance. Awaiting upload requires resuming the original submission with the same key; retrieval does not upload or dispatch. A usable result needing review and a stored failed result are normal retrieval outcomes. Completed means no blocking declared finding, not independently verified accuracy or payment approval.

Disconnecting does not delete an invoice, cancel processing already accepted, or cancel a subscription. Existing account entitlements, idempotency expiry and retention rules apply across REST, SDK and MCP.