Kamy

Record one LLM call — prompt, output, provider, model, tokens, latency — into Kamy Trace, a signed retention ledger. Each record is hashed and signed at write time, so it can be produced later without the 'you could have edited this' objection. Reach for it when model calls need a reviewable history: regulated workflows, customer-facing generations, anything you may have to explain months later. Set status 'flagged' with status_detail on calls a human should revisit. Returns { id, content_sha256, signature, recorded_at, verify_url }. Requires a Kamy API key with the trace:record scope; each call consumes monthly Trace quota.

Write up to 100 Kamy Trace records in one call. Reach for this over trace_record whenever you have more than a couple of buffered LLM calls to persist — it is one auth, one quota check and one round trip instead of N. Each element takes exactly the shape trace_record takes. The whole batch is counted against the monthly Trace quota up front, so a batch that would cross the plan cap is rejected in full with 402 and nothing is stored; split it or upgrade rather than retrying. Returns { records: [{ id, content_sha256, signature, recorded_at, verify_url }] } in input order. Requires a Kamy API key with the `trace:record` scope; without a key, returns dashboard setup instructions.

Query this account's Kamy Trace records, newest first, filtered by feature, status, provider, tag, or time window. Returns record metadata — model, tokens, latency, status, content hash, recorded_at — plus next_cursor for paging; it does not return the stored prompt and output bodies. Use it to answer questions like 'how many flagged calls last week?' or to locate a specific record's id before opening it in the dashboard. Read-only. Requires a Kamy API key with the trace:read scope.

Edit an existing custom template's DRAFT — name, html, css, schema, tags, visibility — addressed by UUID or slug. Only the fields you pass are changed. Crucially, this does not change what renders once the template has been published even once: while published_version is set, render_pdf serves that frozen snapshot and your edits stay invisible until publish_template moves the pointer, so an edit that appears to do nothing usually needs a publish. System templates, and templates belonging to another account, return 403. Requires a Kamy API key with the `templates:write` scope; without a key, returns dashboard setup instructions.

Store an image, font or PDF in the account's asset bucket and get back a `kamy://asset/<id>` reference you can drop anywhere inside a render_pdf / render_html data payload — Kamy swaps it for a fresh signed URL at render time. That reference is the point of this tool: it is how a logo, signature image or custom font gets into a template without hosting it yourself. Pass contentBase64 and this server performs the upload for you, returning { id, assetRef, bytes, uploaded: true }. Omit contentBase64 for files too big to pass through a tool call and you get the raw slot instead — { uploadUrl, uploadMethod, uploadHeaders, expiresAt, uploaded: false } — then PUT the bytes yourself within 15 minutes. Inline uploads are capped at 5 MB here; the API itself allows 100 MB via that URL. Only the listed MIME types are accepted. Requires a Kamy API key with the `uploads:write` scope; without a key, returns dashboard setup instructions.

Dry-run a render payload against a template's schema WITHOUT producing a PDF or using quota. Returns per-field self-healing errors (expected type, value received, allowed values, an example) so you can fix the data before render_pdf. Requires a Kamy API key.

Ask Kamy whether a SHA-256 digest has an attestation on record — the tool that actually returns a verdict. Takes a digest, not a file: if what you hold is a PDF, run verify_pdf_signature over the bytes first and pass the sha256 it gives you. A match returns { verified: true, artifact_type, recorded_at, signature, public_key }. A false result means no attestation exists for those exact bytes, which happens both when content was altered after attestation and when it was simply never attested; it does not by itself identify tampering or a culprit. Public surface — like the extract_document verify URL, no API key is required, so a recipient can confirm an artifact independently of whoever sent it.

Detect when an MCP server changes its tool manifest after you adopted it — the 'rug pull' case, where a server you already trusted silently rewrites a tool's description or input schema. Pass server_url and Kamy fetches that third-party server's manifest itself, or pass manifest when you already hold it (local or private servers). Returns status 'new' (first fingerprint for this account — nothing to compare against yet), 'unchanged', or 'mutated', plus a per-tool changes list with previous and current hashes. 'unchanged' means only that it matches what Kamy recorded previously; it is not a judgement that the server is trustworthy, and a first-ever 'new' result establishes a baseline rather than clearing anything. Requires a Kamy API key.

Turn PDF bytes you are holding into their SHA-256 digest and the matching kamy.dev/verify/{sha256} page URL. Purely local: the MCP Worker hashes the base64 in memory, makes no Kamy API call, stores nothing and forwards nothing, so it works with no key and never leaves a trace. Note it returns no verdict — it does not tell you whether the document is genuine, signed, or on record anywhere. It is the first half of a check: take the sha256 it returns and pass it to verify_attestation for the actual yes/no, or hand a person the verify_url to open. Use this whenever you have the file itself; use verify_attestation directly when someone has already given you a digest.