Sigill now speaks MCP: timestamp and seal from inside Claude

There is a gap between what Claude knows and what Claude can do. It can explain what RFC 3161 timestamping is. It can write you a curl call to Sigill's /tsa/stamp. What it could not do, until today, was actually stamp a document in the middle of a conversation.

That gap is now closed.

Sigill's API is available as a remote MCP server. Add one block to your Claude configuration, and Claude can timestamp files, verify TSRs, look up hashes, seal PDFs, and check your quota — directly, without leaving the conversation, using the API key you already have from Settings.

What MCP is and why it matters here

The Model Context Protocol is an open standard that lets AI models call external tools over a defined interface. It is transport-level glue: Claude sends a structured request, the server executes it, and the result lands back in the model's context.

For Sigill, this means the difference between Claude giving you instructions for how to timestamp something and Claude actually doing it. The second is more useful.

Configuration

Add the following to your Claude configuration. In Claude Code, that is ~/.claude.json globally (not ~/.claude/settings.json — that file exists but MCP servers are not read from it). In Claude Desktop, it is claude_desktop_config.json.

{
  "mcpServers": {
    "sigill": {
      "type": "http",
      "url": "https://api.sigill.ai/mcp",
      "headers": {
        "Authorization": "Bearer your-api-key-here"
      }
    }
  }
}

Your API key is under Settings → API Keys. There are two keys per tenant for rotation; either works.

If you prefer the CLI, the following command writes to the right file automatically:

claude mcp add --transport http --scope user sigill https://api.sigill.ai/mcp \
  --header "Authorization: Bearer your-api-key-here"

No local install. No Node.js. No npm package. The server runs on Sigill's infrastructure and Claude calls it over HTTPS. The API key in the header is the same authentication path as any other Sigill API call — the MCP server does not introduce a new credential type or a new auth surface.

What tools are available

Nine tools are available:

Tools that require an API key use the one you supplied in the Authorization header. Tools that do not require authentication — sigill_verify, sigill_inspect, sigill_lookup — work for anyone, with or without a key, consistent with how those endpoints behave on the API directly.

What a conversation looks like

Once the server is configured, Claude has the context it needs to act on document trust questions directly.

> "Can you timestamp this contract and tell me when it was sealed?"

Claude calls sigill_stamp with the base64-encoded file, gets back a transaction ID and generation time, and answers with both — without you writing a single line of code or opening a terminal.

> "Has this document been tampered with since I sent it?"

You supply the original file and the .tsr from the original stamp. Claude calls sigill_verify, computes whether the hashes match, and tells you the result with the TSA name and timestamp from the proof.

> "How many qualified timestamps do I have left this month?"

Claude calls sigill_usage and reads back your plan, your current usage, and your remaining credits. On a free or starter plan, it will also tell you that qualified timestamps use a lifetime trial model rather than a monthly quota, and suggest an upgrade path if you are close to the limit.

> "Seal this PDF with our organisation's certificate."

Claude calls sigill_list_certificates first to find an active certificate ID, then calls sigill_seal with the file and the certificate ID. It returns the sealed PDF as base64. You can write it to disk or pass it along in the same conversation.

Quota and billing

sigill_stamp and sigill_seal enforce your plan's monthly limits the same way the API does. If you hit a limit, the tool returns an error with the same message you would see from a direct API call — "Monthly stamp limit of 50 reached" or similar. Claude sees that as a tool error and surfaces it plainly rather than silently failing.

sigill_usage gives Claude enough information to answer quota questions before a stamp or seal fails. If you ask "can I seal ten more documents this month", Claude can call sigill_usage, read the remaining seal credits, and answer without attempting the operation.

Sealing requires a certificate

sigill_seal requires a certificate ID. The platform certificate is available to all tenants — sigill_list_certificates will include it if active. If your organisation has uploaded and activated its own certificate, that will appear in the list too.

If there are no active certificates, sigill_seal will return an error explaining that. The fix is to create or activate a certificate in the Sigill dashboard, not to retry the tool call.

What is not in this first version

A few things that did not make the initial release:

Streaming. The MCP spec supports server-sent event streams for long-running operations. Sigill's stamp and seal calls are typically fast enough that streaming is not useful yet. If that changes — particularly for large PDFs — SSE support can be added without a client configuration change.

OAuth. The current flow is API key in a header, which is the same credential pattern used across Sigill's API. A proper OAuth 2.0 flow — where Claude requests an access token rather than requiring you to paste a key — is on the roadmap. The configuration block would change; the tools would not.

Restamp and archival chaining. /tsa/restamp — which creates a timestamp over an existing TSR to extend its validity — is not exposed yet. The use case is real (SHA-1 and SHA-256 will eventually need renewal) but the MCP surface for it requires care around which transaction IDs the model can reference.

The authentication model

It is worth being explicit about what the API key in the configuration means.

Every tool call that reaches Sigill arrives with your key in the Authorization header. The server validates the key against your tenant, synthesises a ClaimsPrincipal with your tenant ID, and from that point the request is indistinguishable from any other authenticated API call. Quota enforcement, audit logging, and tenant isolation are all identical.

The key has the same access as any other API key for your tenant — it does not gain elevated permissions because it arrives through MCP. If you want a key that is specific to Claude, generate a second key under Settings → API Keys, note which slot it occupies, and rotate it independently if needed. Each tenant has two key slots for exactly this reason.

The open verification property

sigill_verify, sigill_inspect, sigill_lookup, and sigill_verify_seal require no authentication and can be called by anyone, including Claude instances that have no API key configured. This is deliberate and matches how the underlying API endpoints work.

A timestamp is only useful if anyone can verify it. Requiring a Sigill account to verify a Sigill-stamped document would undermine the trust model. The verification path for these three tools runs entirely on standard RFC 3161 logic — BouncyCastle parses the TSR, the hash is recomputed and compared — and does not touch your tenant data.

API keys are available in Sigill under Settings → API Keys. The MCP server is available on all plans.