GetSign MCP

getsign_update_workflow_settings

Update workflow settings such as generation, signing, email, and tracking.

    Signature collection (signatureCollection.isEnabled=true with fileColumnId,
    the signed docs File column, and statusColumnId, the workflow status/track
    column) is what makes the backend save the signed PDF into that File column
    on signing completion.

    Sign anywhere is a sub-option of it — sending for signature without predefined
    signature pads — and does not control that file write. To enable it, call this
    tool with signatureCollection.isEnabled=true,
    enableSignAnywhere=true, fileColumnId (signed docs File column),
    statusColumnId (workflow status/track column), and emailColumn (one or more
    {id, type, title} from getsign_monday_item's emailColumn — id is emailColumnId).
    Present every listed email column and let the user pick a single column or
    multiple. Discover file/status columns from getsign_monday_item's
    status_columns / file_columns.
    Do not send enableSignAnywhere alone and do not auto-pick columns.

    To enable Use stored document, set useFileColumn=true and presignedFileColumnId
    to a board File column (from getsign_monday_item's file_columns)
    holding a pre-made document per item — the signing document then comes from that
    column instead of a template. Do not send useFileColumn=true without
    presignedFileColumnId.

    Email logo: after getsign_set_workflow_email_logo returns a storage key, pass
    logo_key to attach it. Pass remove_email_logo=true to clear the current logo
    and delete its storage object. Do not send logo_key and remove_email_logo
    together. settings may be omitted when only attaching or removing a logo.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`logo_key`	No
`settings`	No
`workflow_id`	Yes
`force_update`	No
`remove_email_logo`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 18, 2026

TDQS

A3.6/5.0

Behavior1/5

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

Annotation Contradiction: the annotations declare destructiveHint=false, but the description states that remove_email_logo=true will 'delete its storage object.' Since the description explicitly describes a destructive side effect that the annotation claims does not exist, the description contradicts the annotations. Per rubric, this must score 1 regardless of the detail otherwise provided.

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 long but well-organized into thematic paragraphs (signature collection, stored documents, email logo). The core purpose is front-loaded, and each section adds necessary operational detail. It could be trimmed, but the structure helps an agent parse the dense content.

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 complex, multi-feature tool with no output schema and uninformative annotations, the description covers the critical non-obvious workflows and pitfalls. It does not detail every nested setting (e.g., generateDocument, shareAndTrack), but the schema supplies those field names. The description is sufficient for the high-risk paths.

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 description coverage is 0%, so the description must compensate. It does for the most important parameters: signatureCollection.isEnabled, fileColumnId, statusColumnId, emailColumn, enableSignAnywhere, useFileColumn, presignedFileColumnId, logo_key, and remove_email_logo. However, workflow_id and force_update are not explained, leaving a small gap for a required parameter.

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 opening sentence, 'Update workflow settings such as generation, signing, email, and tracking,' clearly identifies the verb and resource with a specific scope. It does not explicitly differentiate from sibling tools, but the 'update' action is distinct from 'create,' 'get,' and 'select' siblings.

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?

The description provides explicit scenario-based guidance: when to enable signature collection, sign anywhere, use stored documents, and attach/remove logos. It includes clear exclusions and prohibitions: 'Do not send enableSignAnywhere alone,' 'Do not send useFileColumn=true without presignedFileColumnId,' and 'Do not send logo_key and remove_email_logo together.' This leaves no ambiguity about how to invoke the tool correctly.

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?