Skip to main content
Glama

Kamy

by dev.kamy

Edit an existing PDF

edit_pdf

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoLabel for the resulting render row.
pdfUrlNoPublicly fetchable URL of a PDF Kamy has never seen. Kamy downloads it, applies the operations and stores only the edited result — the source does not become a separate render, and the call costs one render either way. Supply exactly one of renderId or pdfUrl.
renderIdNoUUID of an existing render owned by this account. Supply exactly one of renderId or pdfUrl.
operationsYes1–200 operations applied in the order given. 'fill_field' writes into an AcroForm widget; 'stamp_text' draws text at an absolute position; '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.
flattenFieldsNoBake AcroForm values into the page content stream after the fill_field ops so they can no longer be edited. Leave true before e-signing. Pass false only when something downstream still needs the live form.

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide readOnlyHint=false (mutation), openWorldHint=true (unexpected results possible), destructiveHint=false (source unchanged). The description adds crucial behavioral details: operations apply in order, source is untouched (a NEW render is created), cover does NOT delete underlying bytes and carries a COVER_VISUAL_ONLY warning, 'op: redact' is rejected with REDACTION_NOT_SUPPORTED. It also discloses auth requirements (Kamy API key with `render` scope) and warns about warnings carrying out-of-range pages/unmatched field names. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but not verbose; every sentence carries important information. It front-loads the core purpose and operations, then adds usage, then behavioral caveats, then parameter details. The only inefficiency is the near-verbatim repetition of the cover caveat in both the description and the operations schema item description, but that is defensible for clarity. At roughly 300 words, it is thorough yet focused.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (three operation types, source selection, auth scope, warning handling), the description covers all necessary aspects: what the tool does, how to use it, behavioral side effects, failure modes (warnings, not hard errors), and relationships to sibling tools. No output schema exists, but the description lists the return fields ('{ id, url, bytes, durationMs, name, warnings }') and explains the significance of warnings. No gaps remain for an AI agent to make incorrect assumptions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the coordinate origin (BOTTOM-left), that 'flattenFields' defaults to true and why ('so they cannot be edited after signing'), and the 'cover' operation's visual-only nature. However, it could more explicitly tie each parameter to the operations array or clarify how to supply exactly one of renderId/pdfUrl inline. The extra detail lift it to a 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Modify an existing PDF' and enumerates the three specific operations (fill AcroForm fields, stamp text, paint opaque boxes). It distinguishes itself from sibling tools like render_pdf ('use render_pdf when the document should be generated from a template instead'), and notes relationships to create_signature_request, create_envelope, merge_pdfs, and split_pdf. The verb–resource combination is precise and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells when to use this tool ('when a document already exists and needs values or marks') and when not to ('use render_pdf when the document should be generated from a template'). It also warns against using cover for redaction ('never use it to hide secrets or personal data'), and states the alternative for removing sensitive data ('regenerate the document without it'). The distinction between renderId and pdfUrl sources is clearly explained.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Kamy toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

Each tool targets a distinct action or resource with minimal ambiguity. For example, `render_pdf`, `render_docx`, `render_xlsx`, and `pptx` are clearly different output formats, while `merge_pdfs`, `split_pdf`, and `edit_pdf` target different PDF operations. The signature tools (`create_signature_request`, `get_signature_request`, etc.) are also clearly separated by lifecycle stage. No two tools appear to do the same thing.

Naming Consistency5/5

Tool names follow a highly consistent `verb_noun` pattern throughout, such as `create_signature_request`, `get_signature_request`, `list_signature_requests`, and `remind_signature`. This pattern is applied uniformly across all major domains (render, signature, template, webhook, trace), making the API predictable and easy for an agent to navigate.

Tool Count4/5

With 59 tools, this is a large surface area, but it is justified by the breadth of functionality: document rendering in multiple formats, e-signatures, template management, webhooks, scheduling, and a crypto/audit trail. While large, each tool has a distinct purpose, and the count feels appropriate for the scope of a comprehensive document automation API. A surface this large risks being overwhelming, but the internal organization is logical.

Completeness5/5

The tool surface is remarkably complete, covering the full lifecycle for multiple domains. For e-signatures, there are tools for CRUD (requests, templates), sending (individual, bulk, envelope), monitoring (get, list), reminders, and certificates. For documents, it covers creation, conversion, editing, merging, splitting, and verification. The inclusion of utility tools like `get_started`, `validate_payload`, and the audit trail tools further solidifies this as a well-considered, production-ready API surface.

Resources