Use Invoance From Claude: Anchor a Document, Check a Copy, Keep the Proof

One URL, and Claude can write records

Until now, using Invoance meant code: an SDK or a direct API call, a key kept somewhere safe, a developer in the loop. Most of the people who need a signed record of what they sent are not developers, and the developers now spend much of their day in a chat window.

So Invoance is now an MCP server at https://mcp.invoance.com/mcp. MCP, the Model Context Protocol, is the open standard Claude uses to call outside tools. Add the server as a connector, sign in once in your browser, and Claude gains ten tools: record an event, anchor a document, keep a signed record of a model's answer, fetch and list records, check content against a record, and, if your access includes the audit scopes, search a customer organization's audit log. Every record a tool returns carries a public proof link anyone can open.

Nothing about the records changes. A document anchored from a Claude chat is the same record the API writes: the SHA-256 of the file, signed with your organization's Ed25519 key, in the same append-only ledger, checkable with the same public key. The chat is only a new way in.

• MCP server Every client, every tool and its inputs, sign-in, keys and usage.

Add it to claude.ai or Claude Desktop

In claude.ai or Claude Desktop, open Customize, then Connectors. Click + Add, then Add custom connector. Name it Invoance, paste the server URL, click Continue, keep sign-in on and click Add.

Claude sends you to app.invoance.com. Sign in with your passkey, your password or your Microsoft account, or create an account if you have none, and approve the connector for your organization. Back in Claude, turn Invoance on from the + menu under Connectors in any chat.

On Team and Enterprise plans an owner adds the connector once in Organization settings, Connectors (Add, Custom, Web). Each member then clicks Connect and signs in as themselves, so records carry the right actor.

https://mcp.invoance.com/mcp

What the approval actually grants

The consent page is specific on purpose. It names the client asking (Claude), the organization the connection will write to, and the access it asks for: read and write by default, with audit:read added only when a client asks for it. Only an owner or admin of the organization can approve. Other members see the request and cannot complete it, which is the same rule as creating an API key in the dashboard.

When you approve, Invoance creates an API key that belongs to that connection. It is kept out of the API keys list so nobody copies it into a script by mistake, and it carries the scopes you approved and nothing more. Claude never sees that key. It holds an access token that lasts an hour and a refresh token that lasts thirty days, and renews them without asking you. Usage through the connection counts against your plan exactly as API calls do, on every plan including Developer.

Connecting Claude again replaces its earlier connection. Disconnecting is one click in Settings, API Tokens, Connected apps, and the connector's next call is refused.

Try it: anchor a capital call notice before it goes out

Claude in a browser cannot read the bytes of a PDF on your disk, so it cannot compute the file's SHA-256 on its own. The anchor_document tool is built around that limit. Ask Claude to anchor a file and it calls the tool without a hash. The tool returns a one-time link on app.invoance.com, valid for fifteen minutes, and Claude passes it to you. You drop the file on that page. Your browser hashes it, only the hash is sent, and the record is written with the file name as its reference. The file itself is never uploaded.

Claude then has the record: its ID, the time it was signed and its proof link. Say "put the proof link in the covering email" and it will. Any investor who receives the notice can drop their copy on that link and see match or no match, with no account.

If the link expires before you use it, ask again. Nothing was recorded, so nothing is lost.

Check a copy, and record what happened

Checking a copy is the more common need. Someone forwards a document and asks whether it is the version you sent. Ask Claude. The check_document tool returns the record's public proof page; whoever holds the copy drops it there and sees match or no match, with nothing uploaded. If Claude already knows which record is meant, the page opens on that record. Otherwise it opens the general verify page, which finds the record from the file's hash.

Events are simpler still. "Record that we sent the Q3 board pack to the investors today" becomes a log_event call with a short dotted event type and a small JSON payload, and comes back with a proof link. Claude is good at turning a sentence into a sensible event_type and payload. Read what it proposes before it writes, because the record is signed exactly as sent. Keep secrets and personal data out of payloads unless you have a reason to record them.

{
  "event_type": "board_pack.sent",
  "payload": {
    "period": "2026-Q3",
    "recipients": "investors",
    "channel": "email",
    "document_ref": "harbourline-q3-board-pack.pdf"
  }
}

Keep a signed record of Claude's own answer

When Claude drafts something you will act on (a reading of a policy, a customer reply, a summary that goes to the board), ask it to keep a record of the answer. "Record your answer above as an attestation, with the model you used." Claude calls attest_ai_output with the prompt, its output and the model name (provider anthropic). Invoance hashes the input and the output separately, stores the model fields and the time, and signs all of it with your organization's key.

Anyone holding the answer text can check it later against the record on the public proof page, or offline with your published public key. What the record proves is what the model said at that time, as Claude submitted it. It is not Invoance watching the chat, and it does not vouch for the answer being right. It settles the later argument about what the assistant actually told you.

• AI attestation: what it is and why it matters The record type behind attest_ai_output.

Claude Code: your agent can hash the file itself

Claude Code has file access, so it skips the link. It computes the SHA-256 of the file and passes document_hash to anchor_document, or hash to verify_record, and the record is written at once. Add the server from your terminal, then run /mcp inside Claude Code, pick invoance and sign in in the browser. Without an interactive session, claude mcp login invoance runs the same sign-in from the shell.

In CI or on a machine with no browser, use an API key instead of the sign-in. Create one in the dashboard and pass it as a Bearer header; the key's scopes decide which tools the agent sees.

If you would rather not type any of this, paste one sentence into the agent: "Use curl to read https://www.invoance.com/api/docs/developers/mcp and connect the Invoance MCP server to this agent, then call the whoami tool to check the connection." The Markdown version of the docs page carries instructions for the agent, and it will not report the connection as working until whoami answers.

# sign in through the browser
claude mcp add --transport http invoance https://mcp.invoance.com/mcp

# or, with no browser, an API key from the dashboard
claude mcp add --transport http invoance https://mcp.invoance.com/mcp \
  --header "Authorization: Bearer $INVOANCE_API_KEY"

Prompts that work, and what Claude sees

"Anchor this contract before I send it to the buyer" calls anchor_document. "Is this PDF the closing statement we sent on 14 October?" calls check_document. "Record that we sent the Q3 board pack to the investors today" calls log_event. "Keep a record of your answer above, with the model you used" calls attest_ai_output. "What did we record last week?" calls list_records. "Which organization is this connected to?" calls whoami.

Claude only sees the tools its access allows: a read-only connection never shows the write tools. Each call runs the matching /v1 API route as the caller, so validation, scopes and limits are the API's own. A refused call returns the API's own message (Rate limited, Not allowed), so Claude can tell you why instead of guessing.

Every record comes back with a proof_url. That link is what you hand to anyone who asks. It needs no account, no Invoance session and no trust in the chat where the record was made.

• Verification Every way to check a record: API, public page and offline.
• Verify a record with any Ed25519 library The offline check, in Node and Python.