Kamy

List Kamy's public system PDF templates. No authentication required.

無需輸入參數。

Fetch the JSON Schema (exact data shape) and a copy-pasteable sample payload for a Kamy system template by slug. Call this before render_pdf so you fill the right fields with the right types instead of guessing. No authentication required.

Create a new custom PDF template owned by this account: a name, a unique slug, a Handlebars/HTML body, and optional CSS and JSON Schema. The slug is what render_pdf then takes as `template`. Custom templates are a paid feature — on the Free plan this returns 403 FORBIDDEN before anything is created. The slug must be unique within the account and must not collide with a built-in system slug (invoice, receipt, quote, …); both cases come back 422, and the fix for an already-taken slug is update_template rather than a retry. A brand-new template has no published version, so it renders straight from what you supply here — publish_template only becomes necessary once you start cutting versions. Requires a Kamy API key with the `templates:write` scope; without a key, returns dashboard setup instructions.

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.

Make a template version live for rendering. Called with no `version`, it snapshots the current draft into a new version and points published_version at it — this is how you ship an edit made with update_template. Called with an existing `version`, it republishes that earlier snapshot and leaves the draft alone. Reach for rollback_template instead when you are reverting a bad release: only that tool offers the concurrency fence and the option to restore the draft as well. Takes a template UUID or slug, same as every other /v1/templates route. Returns { templateId, publishedVersion, publishedVersionId, latestVersion, publishedAt }. Requires a Kamy API key with the `templates:write` scope; without a key, returns dashboard setup instructions.

Revert a template after a bad release: repoints published_version at the version you name, so every subsequent render immediately serves that snapshot again. Prefer this over publish_template's `version` argument whenever you are reverting, because only this tool takes expectedPublishedVersion — an optimistic fence that rejects with 409 VERSION_CONFLICT if someone moved the pointer since you read it — and only this tool can restore the working draft too. restoreDraft: true overwrites the draft html/css/schema with that version's content, auto-snapshotting the existing draft into a fresh version first so unsaved work is recoverable; it defaults to false. Destructive: it changes what production renders, and there is no undo beyond rolling forward again. Takes a template UUID or slug. Requires a Kamy API key with the `templates:write` scope; without a key, returns dashboard setup instructions.

List a template's immutable version snapshots, newest first, as { id, version, createdAt }. This is where the version number that publish_template and rollback_template take comes from. Bodies are deliberately not included — call get_template_version when you need one snapshot's html, css and schema. Works on system and public templates as well as your own, by UUID or slug. Read-only and spends no quota. Requires a Kamy API key with the `templates:read` scope; without a key, returns dashboard setup instructions.

Fetch one template version snapshot in full — html, css, schema, createdBy, createdAt — exactly as it was frozen when that version was cut. Use list_template_versions first to find the number. Use this to inspect what a released version actually contained, or to recover content a later draft edit overwrote; it changes nothing on its own, so pair it with rollback_template when you want that version live again. Takes a template UUID or slug. Read-only and spends no quota. Requires a Kamy API key with the `templates:read` scope; without a key, returns dashboard setup instructions.

Render a PDF from a Kamy template and data, and wait for it. This is the default document tool: it blocks until the file exists and hands back { id, url, bytes, durationMs, templateId, createdAt } in one call, where url is a signed download link valid for one hour and id is the render id every later tool takes. Reach for render_async instead when waiting is not acceptable, and render_batch when several documents are wanted at once. Call get_template_schema first if you are unsure what fields the template expects. Counts one render against the monthly quota — get_account tells you what is left before this fails with 402. Requires a Kamy API key with the `render` scope; without a key, returns dashboard setup instructions.

Render an editable Word (.docx) document from a Kamy template and data. Takes the same { template, data } payload as render_pdf but produces a different container — reach for it when the recipient has to EDIT the document (legal redlines, Word-based intake, corporate templates) rather than receive a fixed artifact. Only five slugs have a Word implementation — invoice, receipt, quote, contract, agreement — and any other template is rejected with a validation error; use render_pdf for those. Returns { id, url, bytes, durationMs, format: 'docx' }, where url is a signed download link valid for one hour and id is a normal render id. Counts one render against the monthly quota. Requires a Kamy API key with the `render` scope; without a key, returns dashboard setup instructions.

Build a PowerPoint (.pptx) deck from a slide spec: an ordered array of slides, each tagged with one of five fixed layouts (title, bullets, two-column, table, quote). This is NOT a template renderer like render_pdf / render_docx — there is no template slug and no free-form layout, so content has to be shaped into those five. It also converts nothing; use convert_document to turn a file you already have into a PDF. Returns a stored render { id, url, bytes, durationMs, format } where url is a signed download link valid for one hour; the deck is a .pptx, so feed the id to convert_document if the next step needs a PDF (merge_pdfs, split_pdf and the signature tools take PDFs only). Counts one render against the monthly quota. Requires a Kamy API key with the `render` scope; without a key, returns dashboard setup instructions.

Build an Excel (.xlsx) workbook from a sheet spec: columns with keys, row objects keyed to those columns, optional Excel number formats and a formula-aware total row (bare 'SUM' / 'AVG' / 'COUNT' / 'MIN' / 'MAX' expands into a real formula over the column's data range). Choose this over render_pdf when the recipient will sort, filter or recompute the numbers, and over render_docx when the content is tabular rather than prose. Returns a stored render { id, url, bytes, durationMs, format } where url is a signed download link valid for one hour; the workbook is a .xlsx, so feed the id to convert_document if the next step needs a PDF. Header rows are always bold on a tinted fill — there is no flag for it. Counts one render against the monthly quota. Requires a Kamy API key with the `render` scope; without a key, returns dashboard setup instructions.

Compile a Kamy template — or raw Handlebars source you pass inline — against a data payload and get the rendered HTML string back. No browser runs, no PDF is produced and no file is stored, so this is the tool for piping a template into a transactional email provider, or for inspecting the markup before committing to render_pdf. Use render_pdf instead whenever the output has to be a paginated, printable artifact. Supply exactly one of template or html. Returns { format: 'html', html, bytes }. Paid-tier system templates are refused on the free plan. Counts one render against the monthly quota, since the compile step is the shared cost. Requires a Kamy API key with the `render` scope; without a key, returns dashboard setup instructions.

Convert a file you already hold — .docx, .xlsx or .csv — into a PDF, preserving its existing content. Pass the bytes base64-encoded together with the original filename, which is what the API uses to detect the input type. This is the inbound direction: it consumes an existing document, whereas render_docx / render_xlsx / render_pptx GENERATE new documents from structured data, and render_pdf builds one from a template. Returns a stored render { id, url, bytes, durationMs, name } whose id can be fed straight into merge_pdfs, split_pdf, edit_pdf, create_signature_request or create_envelope. Counts one render against the monthly quota. Files over 10 MB are refused by this tool because the bytes travel through the tool call. Requires a Kamy API key with the `render` scope; without a key, returns dashboard setup instructions.

Concatenate 2–20 existing renders into a single new PDF, in exactly the order the ids are given. Both the inputs and the output are Kamy render ids, so this is the composition step after several render_pdf / convert_document / edit_pdf calls — it cannot merge arbitrary URLs or raw bytes, and every id must belong to this account and point at a completed render or the whole call fails. The source renders are left untouched. Returns a new render { id, url, bytes, durationMs }. Billed as one additional render. Requires a Kamy API key with the `render` scope; without a key, returns dashboard setup instructions.

Extract page ranges from one existing render into separate new PDFs — the inverse of merge_pdfs. Each range you pass produces its own render, returned in the same order, so one call can both halve a contract and peel off single pages. Omit a range's `to` to run to the end of the document; a range starting past the last page fails the entire call. The source render is left untouched. Returns { renders: [...], count }, each entry a normal render object usable with merge_pdfs, edit_pdf or the signature tools. Requires a Kamy API key with the `render` scope; without a key, returns dashboard setup instructions.

Modify an existing PDF: fill AcroForm fields by name, stamp text at absolute coordinates, or paint opaque boxes over regions. Operations apply in the order given, to either a render you own (renderId) or a PDF Kamy downloads from a public URL (pdfUrl) — supply exactly one. Use this when a document already exists and needs values or marks; use render_pdf when the document should be generated from a template instead. Nothing is overwritten: the source is untouched and the result is a NEW render whose id feeds directly into create_signature_request, create_envelope, merge_pdfs or split_pdf. Coordinates are PDF points with the origin at the BOTTOM-left. AcroForm values are flattened by default so they cannot be edited after signing. 'cover' paints an opaque rectangle over the region — it hides content visually but does NOT delete the underlying bytes, and the response carries a COVER_VISUAL_ONLY warning for every cover op. Anyone can still copy the text out from under the box. It is NOT redaction: never use it to hide secrets or personal data in a document you are about to hand out, and do not describe the result as redacted. There is no redaction operation — 'op: redact' is rejected with REDACTION_NOT_SUPPORTED. To remove sensitive data, regenerate the document without it. Returns { id, url, bytes, durationMs, name, warnings } — always read warnings, since out-of-range pages and unmatched field names are reported there rather than failing the call. Requires a Kamy API key with the `render` 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.

Look up a stored asset by its upload id: filename, contentType, sizeBytes, status, its `kamy://asset/<id>` reference, and a freshly signed downloadUrl valid for one hour once the bytes exist. Its main use is confirming an out-of-band transfer landed — upload_file returns uploaded:false when the file was too large to pass inline and you PUT it yourself — because this read reconciles a still-'pending' row against storage and flips it to 'uploaded' the first time it sees the object. Also the way to mint a fresh download link after an earlier signed URL expired. Read-only and spends no quota. Requires a Kamy API key with the `uploads:read` 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.

Extract structured data from a PDF (invoice, receipt, contract, ID document, or any form). Returns the parsed JSON plus a public verify URL that proves the extraction matches the source. Use this when an agent needs to read an inbound document and act on it.

Ask Kamy Brain a question about Kamy usage, templates, plans, or errors. Sends the question to Kamy's public assistant endpoint and returns a paragraph answer.

Send a previously rendered PDF to a signer for e-signature when a Kamy API key is configured. Without a key, returns dashboard setup instructions.

Send a single PDF to 2–10 signers as one envelope. This is the multi-signer counterpart to create_signature_request, which handles exactly one signer — the API rejects an envelope with fewer than two recipients, so pick the tool by signer count. routing 'parallel' (default) emails everyone at once and each signs independently; routing 'sequential' emails only the lowest-order recipient and activates the rest one at a time as each preceding signer finishes, which is what you want for approve-then-countersign chains. The source is either a render you own (renderId) or a PDF fetched from a public URL (pdfUrl) — supply exactly one. Pass preview: true to create the envelope and get every sign URL back WITHOUT sending any email and WITHOUT consuming quota; do that first if you are unsure about field placement. A real send emails the recipients immediately and consumes one signature from the monthly quota PER recipient (free tier: 10 signatures/month, then per-signature billing). Returns { envelope, recipients: [...] } with a sign_url per recipient. Requires a Kamy API key with the `signatures:write` scope; without a key, returns dashboard setup instructions.

List signature requests created by the configured Kamy account, newest first. Without a key, returns dashboard setup instructions.

Returns the authenticated download URL for a signature request's Certificate of Completion PDF — the process audit trail (invite → opened → consent → signed, with IP / user-agent) that legal teams expect. Only available after the request reaches a terminal state. Without a key, returns dashboard setup instructions.

Fetch one signature request by id, with the detail list_signature_requests leaves out: the placed_fields layout, signed_at plus signed_ip and signed_user_agent, last_reminded_at, cc_emails, and envelope_id + recipient_order when it is part of an envelope. Use list_signature_requests to find an id and this to inspect it; use get_signature_certificate when what you actually want is the legal audit-trail PDF rather than the row. `status` is one of pending, waiting, signed, declined, delegated, voided or expired — `waiting` means a sequential envelope has not reached this signer yet, so nothing is wrong and no reminder is due. Read-only and spends no quota. Requires a Kamy API key with the `signatures:read` scope; without a key, returns dashboard setup instructions.

Fetch one multi-signer envelope with every recipient in signing order — each with a live sign_url, status, recipient_order, expires_at and last_reminded_at — plus the envelope's own status and routing. This is the tool for 'who still has not signed?' after a create_envelope send; get_signature_request answers that for a single standalone request and returns no recipient list. Under sequential routing, recipients whose turn has not arrived show status 'waiting'. Read-only and spends no quota. Requires a Kamy API key with the `signatures:read` scope; without a key, returns dashboard setup instructions.

Resend the signature invitation email. Pass signatureRequestId to nudge one signer, or envelopeId to nudge every currently-pending recipient of an envelope — supply exactly one; there is no separate envelope-reminder tool. This sends real email to third parties. Each recipient is capped at one reminder per hour: the single-request form returns 429 REMIND_TOO_SOON with a Retry-After header, while the envelope form silently skips capped recipients and reports skipped_reason per row, so read the per-recipient results rather than assuming everyone was mailed. Only pending recipients are reminded — signed, voided and expired requests return 409, and sequential recipients still in 'waiting' are skipped because it is not their turn. A manual nudge also counts toward the three-reminder auto-cadence cap. Requires a Kamy API key with the `signatures:write` scope; without a key, returns dashboard setup instructions.

Fan one already-rendered PDF out to up to 100 independent signers in a single call — the 'send this NDA to everyone on the list' path. Each signer gets their own request, their own sign link and their own invitation email, but they all share one source render, so only one document is produced and stored. Choose create_envelope instead when the recipients are signing the SAME document together and you need routing, ordering and one envelope status; choose this when they are unrelated parties each signing their own copy. Duplicate signer emails within one batch are rejected up front with 422. Per-signer failures do not abort the batch: the response is { bulkId, count, successCount, failureCount, results } in input order, each row either ok with signatureId and signUrl or ok:false with a reason, and the call returns 207 when any row failed. Consumes one signature from the monthly quota PER signer (free tier: 10 per month, then per-signature billing), so a large batch can exhaust a small plan part-way through and the remaining rows come back failed. Requires a Kamy API key with the `signatures:write` scope; without a key, returns dashboard setup instructions.

Check a placedFields layout against a real render's page geometry before anything is sent: no signature request is created, no email goes out, and no signature quota is spent. It accepts exactly what create_signature_request accepts — all seven field types, `options`, and anchor-positioned fields — so anything that previews clean will send. Returns each page's true width and height, so a sender UI can draw a preview at the right aspect ratio, plus per field valid / issues / the resolved coordinates the request would actually be stored with, after sourcePage scaling and anchor substitution. Issues are PAGE_OUT_OF_RANGE, OFF_PAGE_RIGHT, OFF_PAGE_TOP, DUPLICATE_NAME, ANCHOR_NOT_FOUND (the anchor text is not on that page, so the field falls back to the raw x/y) and OPTIONS_REQUIRED. None of these make create_signature_request fail — that is the point of checking here, because a field that lands off the page is accepted and emailed. The source render must have status 'success'; if its PDF has aged out of storage the call returns 410 and the fix is to re-render. Read-only. Requires a Kamy API key with the `signatures:read` scope; without a key, returns dashboard setup instructions.

List this account's reusable e-signature presets — saved field placements, default invite message, default link lifetime and CC list — newest first. These are signing presets, NOT the document catalog: list_templates is what render_pdf draws from. Rows here carry only id, name, description, expires_in and cc_emails; call get_signature_template for the placed_fields and position. Pass an id as create_signature_request's signatureTemplateId to apply a preset instead of re-specifying the layout every time. Returns { templates, total, limit, offset }. Read-only and spends no quota. Requires a Kamy API key with the `signatures:read` scope; without a key, returns dashboard setup instructions.

Fetch one e-signature preset in full, including the placed_fields array and position that list_signature_templates omits. Use it to inspect or copy an existing field layout before applying it through create_signature_request's signatureTemplateId, or as the starting point for a preview_field_placement check against a new render. Read-only and spends no quota. Requires a Kamy API key with the `signatures:read` scope; without a key, returns dashboard setup instructions.

Cryptographically sign an existing render with PAdES when a Kamy API key is configured. Without a key, returns dashboard setup instructions.

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.

Cryptographically sign an output your agent produced — a PDF, report, code patch, dataset, email — so a third party can later confirm those exact bytes are the ones that were recorded, unmodified. Pass content_text or content_base64 and Kamy hashes the bytes for you; pass content_sha256 alone when the content itself must never leave your environment. Returns { attestation_id, content_sha256, signature, recorded_at, verify_url } — hand verify_url to whoever needs to check the artifact. This proves the bytes match what this account recorded at that time; it makes no claim about whether the content is correct. 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.

Append one signed tool_call -> tool_result pair to a tamper-evident ledger. Call it after any consequential tool invocation — a payment, an outbound email, a write into a customer system — so there is a hash-chained record of what the agent asked for and what came back, signed at write time. Pass a stable run_id to keep an entire agent run in one chain, and parent_sha256 to link records explicitly; read the result back with get_provenance_chain. Returns { record_id, content_sha256, signature, recorded_at, verify_url }. Requires a Kamy API key.

Replay everything recorded under one run_id — artifacts from attest_artifact and calls from record_agent_action — in order, with each record's link to its parent hash. Use it to answer 'what did this agent actually do, and in what sequence?' during an incident review, a handover, or an audit. Returns { run_id, chain_intact, records: [...] }, where chain_intact is the server's verdict on whether the parent-hash links are unbroken across the run. Read-only. Requires a Kamy API key.

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.

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.

Heuristic pattern scan of MCP tool description text for prompt-injection tells — instructions addressed at the reading model, data-exfiltration hints, attempts to override your system prompt or hide content. Run it on descriptions from third-party MCP servers before you act on what they say. Returns risk 'low' | 'medium' | 'high' and the matched findings with excerpts. This is a heuristic aid, NOT a security boundary: a 'low' verdict is not evidence that a tool is safe, and an injection phrased to avoid the patterns will score low. Do not treat any result here as clearance to trust an untrusted tool — keep your own judgement and human review in the loop. Read-only: it analyses only the text you pass in and fetches nothing. Requires a Kamy API key.

Everything needed to go from nothing to a rendered document in one call: the steps to create an API key in the dashboard, and — when you name a `framework` — the install command for the Kamy SDK, the environment variable it reads, and the client-setup snippet for that stack. Add a `template` slug and it also returns a ready-to-paste route handler that renders it. Every argument is optional and each one only adds a section, so calling this with no arguments is the right move when a user has no key yet, and calling it with framework + template is the right move when they are wiring the first endpoint. This replaces the separate install_sdk, generate_integration_code and get_api_key_instructions tools removed in 1.5.0. Pure text: it makes no API call, reads no account state, and needs no API key.

Read everything about the authenticated Kamy account in one call: profile, plan and plan status, the plan's limits (renders per month, API keys, seats, custom templates, overage pricing, priority queue), month-to-date render usage, and whether documents rendered on this plan carry Kamy's own watermark. This is the only tool that answers any of those questions — there is no separate quota tool. Call it before render_batch, create_schedule, or any long series of renders: usage.renders.remaining is how many the API will still accept, and every render tool fails with 402 QUOTA_EXCEEDED once it hits zero, a failure nothing can recover from within the same calendar month. quota and remaining are null on unmetered plans, which means unlimited, not zero. Also check watermarkPolicy.appliedToRenders before generating something the user intends to send on: it is true on the free plan and cannot be turned off per render. Read-only, spends nothing, and works with any valid API key regardless of its scopes.

無需輸入參數。

List the documents this account has already produced, newest first. This is how you find a PDF made earlier — in a previous turn, by a schedule, or by another process — when you no longer hold its URL. Download URLs returned by the render tools are signed and expire after an hour, so a link from earlier in the conversation is probably dead; find the render here, then call get_render with its id to mint a fresh one. Returns { renders: [{ id, name, templateId, templateName, status, bytes, durationMs, cost, createdAt }], total, page, pageSize, hasMore, currency }. The `name` field is whatever label was passed at render time, which is the fastest way to identify the right document. Read-only and spends no quota.

Fetch one previously produced document by its render id, with a freshly signed download URL valid for the next hour. This is the recovery path for an expired link: the URL is minted at read time, so calling this again on an old render always yields a working download. Use list_renders first if you do not have the id. Returns { id, name, templateId, templateName, status, bytes, durationMs, url, createdAt }, where url is null when the render failed, has not finished yet, or its file has aged out of retention — check status before assuming a download exists. Read-only and spends no quota.

Rasterise every page of an existing render to a PNG image and return one signed 1-hour URL per page, with pixel width and height. Use this when a page has to be looked at rather than read — thumbnails, previews, visual QA of a layout, or an image attachment — and use extract_from_render when you want the text. The render must already have status 'success'; a queued or failed one comes back as 409 RENDER_NOT_READY. Repeated calls overwrite the same page images, so it is safe to retry. Rasterisation costs no render quota. Returns { pages: [{ page, width, height, url }], count, dpi }.

Read the text or the form fields back out of a document this account already rendered, without uploading anything. Pass type='text' (the default) for per-page text plus a joined fullText string, or type='fields' for the PDF's AcroForm field names, types and current values — the latter is how you discover what edit_pdf can fill in. Choose extract_document instead when the PDF came from outside Kamy or when you need AI-structured JSON against a schema; this tool is a plain mechanical read of an existing render, spends no render quota and no extraction credits. The render must have status 'success' or the call returns 409 RENDER_NOT_READY.

Queue one PDF render and return immediately with { jobId, status: 'queued' } instead of waiting for the document. Choose this over render_pdf when blocking is not acceptable — a heavy template, a large data set, or a turn where you have other work to do — and poll get_job with the returned jobId until status is 'completed' (the finished render, including its download URL, arrives on the job) or 'failed'. Choose render_pdf when a single document is small enough that waiting a few seconds is fine and you want the URL in one call, and render_batch when you have many documents to make at once. Same template, data and page options as render_pdf, and the same one render from the monthly quota — the quota is checked when the job is accepted, so an over-quota call fails here with 402 rather than silently queueing.

Poll an asynchronous render job started by render_async. Returns { jobId, status } where status is 'queued', 'processing', 'completed' or 'failed'; on 'completed' the response also carries `render` with the finished document's id, signed URL, size and duration, and on 'failed' it carries `error` with the reason. Poll every few seconds rather than in a tight loop — a typical render finishes in seconds, a heavy one can take a minute. If a job's signed URL has since expired, pass its render id to get_render for a fresh one. Read-only and spends no quota.

Render up to 100 documents in a single blocking call, each from its own template, HTML or URL, and get every result back in one response. Choose this over calling render_pdf in a loop whenever you have more than a couple of documents — it is one round trip, one quota reservation and one rate-limit charge. It does block: items render sequentially inside a 300-second budget, so expect to wait, and reach for render_async instead when you cannot. Returns { results: [...] } in request order, where each entry is either a finished render or an { error: { code, message } } — a partial batch is normal and successful items are still yours. The whole batch's quota is reserved up front, so a batch that would cross the monthly quota is rejected in full with 402 and nothing is rendered; call get_account first if you are near the limit. Items that would overrun the time budget come back as SERVICE_UNAVAILABLE having been neither rendered nor billed — retry just those in a smaller batch.

Set up a recurring render: a cron expression, a template, and where each document goes. Use this instead of render_pdf when the user wants a document produced repeatedly on a calendar — a weekly report, a monthly invoice run — so nothing has to stay running. Delivery channel is 'email' or 'whatsapp' (recipients required) or 'download' (stored only; retrieve later with list_renders). The cron is evaluated in the given IANA timezone, and how often it may fire is plan-gated: at least 60 minutes apart on Free, 15 on Starter, 5 on Pro and above — a tighter expression is rejected with a validation error naming the limit. Every firing spends one render from the monthly quota, so a frequent schedule can exhaust a small plan on its own. Returns the created schedule including its id and next_run_at.

List this account's recurring render schedules, newest first, with the id needed to delete one. Use it to answer what is already automated before creating a duplicate, and to diagnose a schedule that is not producing documents: each row carries enabled, schedule, timezone, next_run_at, and last_run_at / last_run_status / last_run_error from the most recent firing — last_run_error is where a delivery or quota failure shows up. Returns { schedules, total, limit, offset }. Read-only and spends no quota.

Permanently delete a recurring schedule so it stops firing. There is no undo and no trash — recreate it with create_schedule if it is deleted by mistake, so confirm with the user before calling this on a schedule you did not just create. If the intent is only to pause it, do not use this tool: a schedule can be switched off and back on again via its `enabled` flag on the REST endpoint (PATCH /v1/schedules/{id}), which this MCP surface does not expose. Documents already produced by past firings are unaffected and remain available through list_renders. Returns { deleted: true }, or 404 if the id does not belong to this account.

Register an HTTPS endpoint that Kamy POSTs to when work finishes, so a long render or an e-signature does not have to be polled. Use this when the caller owns a server that can receive callbacks; use get_job or list_renders when it cannot. The response includes a one-time signing secret used to verify delivery signatures — it is shown here and never again, so surface it to the user immediately and tell them to store it. Defaults to the render.completed and render.failed events; the full set is render.completed, render.failed, signature.signed, signature.voided, signature.expired, signature.envelope_completed, signature.envelope_voided, test.ping, and any other string is accepted so new events can be subscribed to without an upgrade. Endpoint URLs on private, loopback, link-local or cloud-metadata hosts are rejected at registration, so a localhost tunnel will not work — use a public URL.

List the webhook endpoints registered on this account, with the id needed to test one. Each row carries url, events, enabled, and lastDeliveryAt / lastStatus from the most recent delivery — lastStatus is the HTTP code the caller's own server returned, so this is where a silently broken endpoint shows up as a 4xx or 5xx. Signing secrets are never returned here; they are shown only once, by create_webhook. Read-only and spends no quota.

無需輸入參數。

Send a real test.ping event to a registered webhook endpoint — an actual outbound HTTP POST to whatever URL the user configured, signed like a genuine delivery. Use it to prove an endpoint is reachable and that signature verification works before relying on it. Delivery is dispatched in the background, so the { message: 'Test ping dispatched' } you get back means accepted for sending, not that the endpoint answered: wait a few seconds and call list_webhooks to read lastStatus and lastDeliveryAt for the real outcome. The ping is delivered regardless of which events the endpoint subscribes to.