Skip to main content
Glama

Kamy

by dev.kamy

Send for e-signature

create_signature_request

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
messageNoOptional message rendered in the email invitation body.
ccEmailsNoUp to 10 observer addresses CC'd on the invite and the completion notice. Not signers themselves.
positionNoOptional sender-chosen signature placement in PDF points (72 dpi, origin bottom-left). Defaults to bottom-right of the last page sized 220×64 pt; when omitted, the signer can drag the placeholder on the sign page.
renderIdYesRender UUID returned by render_pdf or any /v1/render call. The render's PDF is the document the signer will receive.
expiresInNoHow long (seconds) the sign link stays valid. Defaults to 30 days. Min 1 hour, max 30 days.
authMethodNoIdentity-verification mode. `link` (default) — possession of the secret URL is the only check. `email_otp` — sign page renders a 6-digit OTP gate; code emailed to `signerEmail`. `sms_otp` — same gate, code texted to `signerPhone` (which must then be supplied). Recommend `email_otp` for higher-value transactions.
signerNameYesRecipient full name. Must be typed verbatim by the signer to confirm intent.
signerEmailYesRecipient email address.
signerPhoneNoE.164 phone number. Required when `authMethod` is `sms_otp`; ignored otherwise. Example: `+14155551234`.
placedFieldsNoUp to 100 sender-defined fillable fields stamped onto the PDF at sign time. Use for flat PDFs that don't ship AcroForm widgets. Names must be unique.
requireStampNoRequire the signer to upload a company stamp / seal alongside their personal signature (UAE, KSA, JP, KR, IN, CN B2B workflows). Server refuses to seal without one.
signOnEveryPageNoWhen true, the server stamps the signer's signature on every page of the source PDF instead of only the configured position. Common B2B contract pattern.
signatureTemplateIdNoApply a signature template's defaults (placedFields, position, message, expiresIn, ccEmails). Request-level fields override the template.
reminderCadenceHoursNoWhen set (24–168), the auto-reminder cron resends the invite every N hours while the request stays pending, up to 3 reminders. Omit for no auto-reminders.

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already mark the tool as non-read-only and non-destructive; the description adds the prerequisite of a Kamy API key and the conditional behavior of returning dashboard setup instructions without a key. This is useful behavioral context that goes beyond the annotations.

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

Conciseness5/5

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

The description is two sentences, front-loaded with the main action and a conditional. Every word earns its place; there is no redundancy or filler.

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

Completeness3/5

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

The tool is complex (14 params, nested objects, no output schema), and the description is minimal. It explains the no-key fallback but not the success return value or the overall workflow (e.g., what happens after sending). The schema fills in parameter details, but the description should provide more behavioral context for such a complex tool.

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

Parameters3/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 no parameter-level details beyond 'previously rendered PDF' (implied renderId) and 'signer' (implied signerEmail/Name), so it does not augment the schema's already-thorough parameter documentation.

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 the specific action ('Send a previously rendered PDF to a signer for e-signature') and resource, and the condition about 'when a Kamy API key is configured' adds useful scoping. It distinguishes this tool from siblings by emphasizing the input is a rendered PDF and the purpose is e-signature sending.

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

Usage Guidelines4/5

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

The description gives clear context: use when you have a previously rendered PDF and a Kamy API key is configured, and warns about the fallback when no key is set. It does not name explicit alternatives or exclusions, but the context is strong enough for an agent to select this tool appropriately.

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