GetSign MCP

getsign_get_document_url

Return a GetSign edit or preview URL for an item document or gallery template.

    action=edit opens field mapping. action=preview opens read-only review.
    Pass envelope_id + item_id for an item (file_id optional), or template_id +
    file_id for a gallery template, never both shapes. When the workflow has
    useFileColumn enabled, the document is item-level: pass envelope_id + item_id
    with edit_template=False, matching the scope of the save, and tell the user the
    editor is open on this item's document rather than a shared template.
    edit_template applies only
    to action=edit: omitted means shared-template editing. Pass false for this item
    only. Preview rejects edit_template and redirects completed items to download.

Input Schema

TableJSON Schema

Name	Required	Description
`action`	Yes
`file_id`	No
`item_id`	No
`envelope_id`	No
`template_id`	No
`confirm_token`	No	Retry token from a prior CONFIRMATION_REQUIRED response. Do not invent one.
`edit_template`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 18, 2026

TDQS

A4/5.0

Behavior4/5

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

The description adds useful behavioral detail beyond annotations: action=edit opens field mapping, preview opens read-only review, preview rejects edit_template, and completed items redirect to download. It does not contradict the annotation flags, though it omits details like side effects or rate limits.

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 purpose is front-loaded, and line breaks separate action semantics, parameter shapes, and special-case guidance. It is somewhat long but each sentence adds relevant information, and the item-level workflow case is explained efficiently.

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 7-parameter tool with no output schema, it covers action semantics, parameter shapes, and edge behavior well. It does not describe the return format in detail or the CONFIRMATION_REQUIRED retry flow beyond the schema's confirm_token note, leaving a small completeness gap.

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?

With only 14% schema coverage, the description compensates well by explaining action values and valid parameter combinations, including the optional file_id and edit_template semantics. confirm_token is left to the schema, which already documents it, so the main gap is that not every parameter is explicitly re-explained.

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 begins with 'Return a GetSign edit or preview URL for an item document or gallery template,' which names a specific resource and operation. It clearly distinguishes the edit and preview modes, but does not explicitly compare against sibling tools like generate_signing_link.

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 provides explicit conditions: pass envelope_id + item_id for an item, template_id + file_id for gallery templates, never both shapes, and use edit_template=False for item-level workflows. It stops short of naming alternatives or exclusionary cases vs other tools, but the within-tool guidance is strong.

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

All GetSign MCP 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?