GetSign MCP

getsign_get_workflow

Read-onlyIdempotent

Fetch Getsign workflow details by id — user-friendly alias for envelope.

    The response carries the full settings blob plus a display_summary: a
    curated, four-section view (Sender / Email settings, Generate document,
    Signature collection, Share and track), each with a title, a plain-language
    description of what it does, and the current value/on-off. Present that
    summary to the user — the section titles + descriptions + current values —
    do NOT dump the raw settings blob and don't silently proceed on defaults
    the user never saw. Only expand a section's details (its configuration
    requirements) when the user asks about that specific section (e.g. "what
    do we need to configure generate document"). Change settings via
    getsign_update_workflow_settings.

    When the workflow has an email logo, the response also includes logo_key
    and a short-lived logo_preview_url. Preview lives here. There is no
    getsign_get_workflow_logo_url. Uploading a new logo is
    getsign_set_workflow_email_logo (starts disabled: enable it with
    getsign_manage_tools first), then attach data.key via
    getsign_update_workflow_settings(logo_key=...).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`workflow_id`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 18, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description reveals the response shape: full settings blob plus a four-section display_summary with titles, descriptions, and current values. It also discloses the short-lived logo_preview_url and explicitly states 'There is no getsign_get_workflow_logo_url.'

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 description is longer than strictly necessary and contains some asides, but it is organized into clear functional paragraphs: purpose, summary-display behavior, settings pointer, and logo handling. Each section carries actionable information, so no part is filler.

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?

With no output schema, the description fully covers the return values: the settings blob, display_summary structure, logo_key, and logo_preview_url. It also explains how to proceed with the result and which sibling tools to use for follow-up actions.

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?

The schema has one parameter, workflow_id, with no description (0% coverage). The description only says 'by id,' which adds little beyond the self-explanatory parameter name; it does not explain where the id comes from, its format, or validation requirements.

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 opens with a specific action and resource: 'Fetch Getsign workflow details by id' and clarifies it is a 'user-friendly alias for envelope.' This clearly distinguishes it from nearby tools like getsign_update_workflow_settings and getsign_get_document_url.

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?

It explicitly instructs to present the display_summary rather than the raw blob and to only expand section details when the user asks. It also routes related actions to named alternatives: 'Change settings via getsign_update_workflow_settings' and logo upload via getsign_set_workflow_email_logo.

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?