Skip to main content
Glama

getsign_save_document_configuration

Save document fields or sequential signing order.

    action=placeholders (default): persist AI-detected fields. placeholders MUST be
    the exact objects from getsign_detect_placeholders_ai (data.placeholders) —
    always call that tool first and pass its output through unmodified except for
    field_assignments. Do NOT hand-author placeholder coordinates yourself
    (e.g. guessing x/y/width/height from where you drew boxes on a generated
    PDF). The wire shape has two separate coordinate fields —
    formField.coordinates (bottom-up, native PDF points) and placeholder (the same
    point converted top-down) — and this route does not validate that they agree.
    A hand-typed placeholder that gets the two conventions wrong is accepted and
    stored (no error), but silently fails to render in the PDF editor and fails to
    resolve any signer in getsign_get_signer_data. If there is no PDF to detect
    against yet, or the user wants manual control, use getsign_get_document_url(action="edit")
    instead of inventing coordinates.

    Route from the ID pair (not from the word "template"):
    - envelope_id + item_id + file_id → POST /files/map-placeholders (item
      document). Default is_template_update=true saves to the shared template
      and every item using it. Pass is_template_update=false when the
      user says this one item, and ALWAYS when the workflow has useFileColumn
      enabled — a document sourced from a monday File column is that item's own
      file with no shared template behind it. A template-scoped save there is not
      rejected: the file is not pinned to a template, so the backend updates only
      that file, takes the template signing-order branch, and still answers
      "Template updated successfully", so reporting that result verbatim tells the
      user about a template-wide change that never happened.
    - template_id (no item) → POST /template-gallery/map-template-placeholder/:id
      (gallery). file_id is optional, and existing_fields is an optional override.
      is_template_update is ignored.
    Pass one shape, not both. merge=true (default) keeps existing fields.
    After a force detect the save replaces instead (merge=false) so new
    field ids do not stack on the previous run.

    Signer assignment (email / people / mirror-email-column only — use
    getsign_monday_item's signer_columns / emailColumn — raw emails are
    not allowed). If you save without an assignee on an item, this tool
    returns those lists so you can follow up:
    - Prefer field_assignments: [{placeholder_id, assignee_column_id,
      assignee_column_type, optional assignee_column_title}] so each
      signature or standard field can get its own column in one save.
    - Or pass a single assignee_column_id(+type) as a default for every
      field that has no per-field assignment.
    Leave both unset to save fields without signers, then map later in
    getsign_get_document_url(action="edit"). Match is_template_update with edit_template
    when opening the editor to review.

    action=signing_order: set who signs first, second, and so on, without
    opening the PDF editor. Needs envelope_id + item_id. Each ordered_signers
    entry must already be a mapped signer (a board column stamped onto a
    signature field). Identify them with email_column_id, label, or email from
    getsign_get_signer_data, in the sequence they should sign. Example: Priya
    (CISO) first, then the CFO. The second person is emailed only after the
    first signs. required=true (default) turns sequential signing on.
    required=false with an empty ordered_signers list turns it off so everyone
    is notified at once. List every mapped signer when turning it on. This
    writes the same signerOrderSettings the editor Save button writes, so
    existing customers who set order in the editor are not broken. Default is
    item-level (is_template_update=false). Pass true only when the user wants
    the order on the shared template. Call getsign_get_signer_data first. Do
    not bounce the user into the editor just to configure order.
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
mergeNo
actionNoplaceholders
file_idNo
item_idNo
requiredNo
envelope_idNo
template_idNo
placeholdersNo
assignee_colorNo
existing_fieldsNo
ordered_signersNo
field_assignmentsNo
assignee_column_idNo
is_template_updateNo
assignee_column_typeNo
assignee_column_titleNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

With annotations providing no safety hints, the description carries the full behavioral burden and exceeds it. It discloses the coordinate-system mismatch and its silent failure mode, the template-scoped save on a File column that falsely reports 'Template updated successfully', the merge=true/replace-on-force-detect behavior, and the signerOrderSettings equivalence with the editor's Save button. These are exactly the side effects an agent needs to know.

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 the length is justified by the tool's complexity: two actions, two routes, multiple defaults, and several dangerous edge cases. It is front-loaded with the core purpose and uses clear action blocks and bullets. However, some paragraphs are dense enough that an agent might need multiple passes to extract the key routing rules, so it is not maximally concise.

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 16-parameter tool with no output schema, the description is impressively complete: it covers routing, defaults, alternatives, and failure modes. The main gap is that it never describes the success/error return envelope or the shape of the lists returned when saving without an assignee, which matters more because no output schema is available to fill that void.

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 explain the parameters, and it covers nearly all of them: action, placeholders, is_template_update, merge, file_id, existing_fields, ordered_signers, required, field_assignments, assignee_column_id, assignee_column_type, and assignee_column_title. It does not mention assignee_color at all, and the nested object shapes for field_assignments and ordered_signers are described only at a high level, so a perfect 5 is not warranted.

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 opening line 'Save document fields or sequential signing order' names a specific action and resource, and the two action modes are clearly separated. The description also differentiates this tool from related siblings such as getsign_detect_placeholders_ai and getsign_get_document_url, so an agent can identify what this tool uniquely does.

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 gives explicit routing guidance: 'always call that tool first and pass its output through unmodified', 'If there is no PDF to detect against yet, or the user wants manual control, use getsign_get_document_url(action="edit")', and 'Do not bounce the user into the editor just to configure order.' It also states when is_template_update should be false and when to prefer field_assignments over a single assignee_column_id, which is strong when-to-use detail.

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