Skip to main content
Glama

Fast.io

by io.fast.mcp
OverviewDiscussionsAdmin

E-Signature Management

sign_manage
Destructive

Fastio e-signature writes: draft envelopes, send (reserves signing credits), void, retry, the caller's signing link, and sign templates. Destructive: sign-send, sign-void, sign-template-delete (confirm='true'). Reads are on sign.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoEnvelope or template name (required on sign-template-create). sign-template-instantiate defaults it to the template name.
actionYesOperation. Use 'describe' for full action reference.
fieldsNosign-create/-update: JSON array of field placements (coords 0..1; see note).
reasonNosign-void: void reason.
confirmNo'true' is required for sign-send, sign-void and sign-template-delete.
snapshotNosign-template-create/-update: JSON {recipient_slots, document_slots, fields, policy}; a full replacement on update.
documentsNoJSON array. sign-create/-update: 1-20 documents (see note). sign-template-instantiate: slot overrides [{document_slot_index, source_node_id, source_version_id?}].
expires_atNosign-create/-update: expiry 'Y-m-d H:i:s UTC' (not a day count; omit = policy default).
recipientsNosign-create/-update: JSON recipients array (see note).
descriptionNosign-template-create/-update: template description.
envelope_idNosign-*: numeric envelope ID.
policy_jsonNosign-create/-update: optional JSON policy {auth_method,...}.
template_idNosign-template-get/-update/-delete/-instantiate: template id (30-char base32, `sa` family).
workspace_idNoWorkspace ID (19-digit NUMERIC; the document/audit download stream route rejects custom workspace names). Envelopes are workspace-parented.
describe_actionNoWith action='describe': return one action's params and notes instead of the action index.
expected_versionNosign-template-update: the `version` from sign-template-get (optimistic CAS; 409 on a concurrent write).
recipient_bindingsNosign-template-instantiate: JSON object slot_key -> {email, display_name?, auth_method?} (not an array).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior4/5

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

Annotations only say destructiveHint=true generically; the description narrows it to the exact three actions (sign-send, sign-void, sign-template-delete) and states the confirm='true' gate, plus the billing side effect that send 'reserves signing credits'. It omits reversibility and rate-limit behavior, but the per-action destructive mapping is real added value.

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?

Three dense sentences with zero filler: capability list first, destructive/confirm caveat second, sibling routing last. Every clause carries information an agent needs.

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

Completeness4/5

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

For a 17-parameter, 11-action tool with no output schema, the description supplies scope, sibling routing, the destructive subset, and the describe escape hatch — enough to call it correctly given 100% schema coverage. It stops short of mapping actions to intents, which is the remaining gap.

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% and every parameter carries a per-action note, so the schema does the heavy lifting; baseline 3 applies. The description only repeats the confirm='true' requirement and adds the credit-reservation note for send, adding little parameter meaning beyond the schema.

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 ('Fastio e-signature writes') and enumerates the concrete operations (draft, send, void, retry, signing link, templates), so the agent knows exactly what surface this tool covers. It also explicitly delimits itself from the sibling read tool ('Reads are on `sign`').

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?

It states the write-vs-read split and routes reads to `sign`, and it points to action='describe' for the full action reference. What it does not do is help choose among the eleven write actions for a given intent — the agent must go to the schema enum or call describe.

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

All Fast.io toolsInspect
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