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

Name	Required	Description
`message`	No	Optional message rendered in the email invitation body.
`ccEmails`	No	Up to 10 observer addresses CC'd on the invite and the completion notice. Not signers themselves.
`position`	No	Optional 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.
`renderId`	Yes	Render UUID returned by render_pdf or any /v1/render call. The render's PDF is the document the signer will receive.
`expiresIn`	No	How long (seconds) the sign link stays valid. Defaults to 30 days. Min 1 hour, max 30 days.
`authMethod`	No	Identity-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.
`signerName`	Yes	Recipient full name. Must be typed verbatim by the signer to confirm intent.
`signerEmail`	Yes	Recipient email address.
`signerPhone`	No	E.164 phone number. Required when `authMethod` is `sms_otp`; ignored otherwise. Example: `+14155551234`.
`placedFields`	No	Up 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.
`requireStamp`	No	Require 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.
`signOnEveryPage`	No	When 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.
`signatureTemplateId`	No	Apply a signature template's defaults (placedFields, position, message, expiresIn, ccEmails). Request-level fields override the template.
`reminderCadenceHours`	No	When 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

A3.6/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint=false (write operation) and destructiveHint=false. The description adds the key behavioral trait that an API key is required for execution, and that without it the tool returns setup instructions. This provides useful context beyond the annotations without contradicting them.

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 short sentences, front-loaded with the primary action. Every word contributes value, and there is no redundancy or filler. Perfectly concise for a tool with rich schema documentation.

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

Completeness2/5

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

Despite full schema coverage, the description is too brief for a complex tool with 14 parameters, nested objects, and no output schema. It omits high-level workflow context such as the role of renderId (must come from render_pdf), the fact that the signer receives an email invitation, and how response behaves. The description does not adequately prepare the agent for the full sequence of events.

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 coverage is 100%, so the schema already describes all 14 parameters in detail. The description does not add any parameter-level meaning or usage hints. Baseline of 3 applies because the schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the tool sends a previously rendered PDF for e-signature, using a specific verb and resource. It adds a conditional about API key configuration, making the purpose precise. However, it does not differentiate from sibling tools like bulk_signature_requests, so it loses a point for lack of sibling distinction.

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

Usage Guidelines3/5

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

The description tells when to use the tool (when a Kamy API key is configured) and what happens without it (returns setup instructions). It does not provide explicit guidance on when not to use or mention alternatives such as bulk_signature_requests for multiple signers, making the usage context implied rather than fully explicit.

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

All Kamy tools Inspect

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.2/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose with detailed descriptions that differentiate similar tools (e.g., render_pdf vs render_async vs render_batch, create_signature_request vs create_envelope). No two tools overlap in a way that would cause confusion.

Naming Consistency5/5

All tool names follow a consistent lower_snake_case verb_noun pattern (e.g., attest_artifact, convert_document, list_renders). No mixing of conventions or ambiguous verb choices.

Tool Count4/5

47 tools is high but reflects the broad scope of the platform (document generation, signing, auditing, scheduling, webhooks, verification). Some informational tools could be merged, but the count is still reasonable for the domain.

Completeness3/5

The tool set covers the core document lifecycle well but has notable gaps: no tool to delete renders, no tool to void/cancel signature requests, and no CRUD for templates (only list and schema). The inability to pause schedules via MCP is also a gap.

Resources

Need Help?