Formify — AI Assisted E-Signing

Send Reminder

send_reminder

Destructive

Send a signing reminder to one or more signees who have not yet signed. Always call get_document first. Two conditions decide who can be reminded: (1) the document status must be awaiting_signatures — any other status returns 403; (2) include only signees whose signatureStatus is awaiting_signature, never one whose signatureStatus is signed. Show who will be reminded and ask for confirmation before sending. Rate limit: max 2 reminders per signee per 60-minute rolling window, after which the API returns 429. signeeDetails[].reminders.reminderCooldown from get_document is the number of seconds left before the next reminder is allowed — check it before calling, and tell the user how long is left instead of retrying.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "documentId": "<documentId>",
      "signeeIds": "<signeeIds>"
    },
    "name": "send_reminder"
  }
}

Input Schema

Name	Required	Description	Default
`signeeIds`	Yes	Signee IDs to remind (get these from get_document response)
`documentId`	Yes	Unique identifier of the document

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 10, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only flag destructiveHint/openWorldHint/non-idempotent; the description adds far more: a 403 on wrong document status, a concrete rate limit ('2 per signee per 60-minute rolling window') producing 429, and how to interpret `reminders.reminderCooldown` from get_document to avoid the error. That is exactly the operational context annotations cannot express.

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?

Purpose is front-loaded in sentence one, followed by preconditions, error behavior, and rate-limit remediation in a logical order. It is dense but every sentence carries actionable content; the numbered conditions make it scannable.

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?

For a 2-parameter mutation with no output schema, the description covers everything needed to call it correctly: prerequisites, eligibility rules, confirmation behavior, failure modes (403/429), and how to recover from a cooldown. Nothing material is left to inference.

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 coverage is 100%, so parameter documentation is already handled. The description still adds a filtering rule the schema does not encode — restrict `signeeIds` to those with `signatureStatus` = `awaiting_signature` — which meaningfully changes how the parameter should be populated.

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?

Opens with a specific verb+resource pair ('Send a signing reminder') and immediately scopes it to signees 'who have not yet signed'. No sibling tool overlaps with reminders, and the description makes the target set 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?

Explicit preconditions: 'Always call get_document first', document status must be `awaiting_signatures`, and only signees with `signatureStatus` = `awaiting_signature` may be included, with an explicit exclusion ('never one whose signatureStatus is signed'). It also prescribes a confirmation step and the cooldown-check pattern instead of blind retries.

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

All Formify — AI Assisted E-Signing tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?