Skip to main content
Glama

Update document signatory

update-document-signatory
DestructiveIdempotent

Edit the details of a document signatory.

Use this tool when:

  • A signatory's name, title, mobile phone, or party assignment needs to change before signing starts

  • You need to move an existing signatory to a different party on the document

document_uuid and signatory_email are required to identify the signatory. All other arguments are optional and only need to be sent if their value should change. For internal signatories (linked to an account user), signatory_first_name, signatory_last_name, and signatory_title cannot be changed — they come from the user's profile.

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": {
      "document_uuid": "<document_uuid>",
      "signatory_email": "<signatory_email>"
    },
    "name": "update-document-signatory"
  }
}

Input Schema

NameRequiredDescriptionDefault
document_uuidYesUUID of the document where the signatory is being updated. If you don't already have the document's UUID, use the list-documents tool to find it.
signatory_emailYesEmail address of the signatory to update.
signatory_titleNoNew job title. Cannot be changed if internal_user is true
signatory_last_nameNoSignatory's new last name. Cannot be changed if internal_user is true
signatory_first_nameNoSignatory's new first name. Cannot be changed if internal_user is true
signatory_mobile_phoneNoNew mobile phone number in E.164 format. Depending on the document's signature_type, may be required before signing can be started
signatory_party_identifierNoIf given, moves the signatory to this party. Must be a ref_uuid, reference, or entity_name of an existing party in the document

Output Schema

NameRequiredDescriptionDefault
nameNoName of the signatory
uuidNoDo not show to the user unless they ask for it
emailNoEmail of the signatory
party_uuidNoUUID of the party this signatory belongs to. Absent if the signatory has not been assigned to a party yet, which prevents signing from being started. Do not show to the user unless they ask for it
_entity_typeNoOnly relevant for tooling. Do not show to the user
internal_userNotrue if the signatory has a fynk user in this account
signing_orderNoThe order in which this signatory signs

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

The description adds real behavioral context beyond the annotations: internal users (account-linked signatories) cannot have their name or title changed because those come from the user profile, and mobile phone may be conditionally required depending on the document's signature_type. With annotations already declaring readOnlyHint=false, destructiveHint=true, and idempotentHint=true, this is substantive added context, though it does not clarify what happens if the update is attempted after signing has started or what 'destructive' means for an edit.

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?

The purpose is front-loaded in one sentence, followed by scannable bullet conditions and a compact paragraph on required vs optional parameters. Every sentence carries information the agent needs to call the tool correctly.

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?

An output schema exists, so return values need not be described, and annotations cover the safety profile. Combined with the internal-user restriction, the optional-field semantics, and the conditional mobile-phone requirement, the description is nearly complete; the only gap is behavior when the document is already in signing state.

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 the baseline is 3, but the description adds genuine semantics by stating that document_uuid and signatory_email identify the signatory and that all other arguments should only be sent when their value should change — an update-semantics rule not obvious from the schema alone. It also restates the internal_user restriction and the conditional mobile-phone requirement, reinforcing schema details.

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 verb and resource — 'Edit the details of a document signatory' — which an agent can distinguish from the sibling create-document-signatory, delete-document-signatory, and update-document-party tools without opening any schema.

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?

Two explicit bullet conditions ('before signing starts' edits, and moving a signatory to a different party) give clear context for use, and the required identifiers vs optional fields are spelled out. It stops short of naming alternatives explicitly (e.g., that delete-document-signatory handles removal), so there is no explicit when-not-to-use guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources