Skip to main content
Glama

getsign_detect_placeholders_ai

Run AI placeholder detection on a PDF document.

    Detects signer-fillable pads (signature, initials, sign dates, text boxes,
    checkboxes) and Monday board fields (email, phone, numbers, location,
    text, date, item-name) in one run. Board fields pull values from the
    item's Monday columns. itemId is the column id, title is the column name.
    Always pass board_id so columns reach the detector. item_id is not
    enough. If omitted, the tool resolves board_id from envelope_id or
    template_id. Printed {{Column Title}} / {columnId} tags are not
    rewritten into board overlays.
    By default waits for the async job to finish and returns detected
    placeholders. Set wait=false to only start the job and get a jobId.

    Present these choices to the user. Do not pick silently.

    First detect — ask which fields to detect:
    - Board fields (filled from Monday columns)
    - Signer-fillable placeholders (the signer writes them)
    - Both
    Pass their choice as intent, e.g. intent="board fields only",
    intent="signer-fillable only", or intent="both". They can add document
    type on the same string. Do not invent a choice they did not give.

    If the result is wrong they can:
    - Edit with text: re-call with refine=true and intent set to what they
      said is wrong (e.g. intent="you missed the signature on page 2").
    - Start from scratch: re-call with force=true. That mints new field ids,
      so save afterwards with merge=false or fields will duplicate.

    If AI detection was already completed / fields are already mapped on this
    file, returns AI_DETECTION_ALREADY_DONE instead of redetecting. Pass
    envelope_id+item_id or template_id so that check can read file state. That
    response includes previous_run and user_options — tell the user those
    options (refine with text vs start over vs review in the editor).

    Prefer this when the user asks to auto-detect signature pads, form
    fields, or Monday board fields on a PDF. After completion, save via
    getsign_save_document_configuration action=placeholders, then open
    getsign_get_document_url(action="edit") so the user can review.

    For item / useFileColumn documents, always pass envelope_id (workflow id) +
    item_id. The tool calls POST /files/find-or-create/with-rendered-string first
    (same as opening the PDF editor) so detect has an S3 key. Without envelope_id
    the ingest step is skipped and Monday-only file ids can fail with
    "File not found or has no storage key".

    This is the required first step for placing signer-fillable or
    board-bound fields via the API. Always call this before
    getsign_save_document_configuration (action=placeholders), and pass
    its data.placeholders through unmodified, including board field types.
    The only field-placement path that skips this tool is the manual PDF
    editor (getsign_get_document_url with action="edit"), where the user
    places fields by hand.
    Never construct a placeholders array yourself from guessed coordinates —
    the save route accepts it without error but it can fail to render or
    resolve a signer, with no indication anything is wrong.
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
waitNo
forceNo
intentNo
job_idNo
refineNo
file_idYes
item_idNo
board_idNo
envelope_idNo
template_idNo
confirm_tokenNoRetry token from a prior CONFIRMATION_REQUIRED response. Do not invent one.
timeout_secondsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / intent
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null
      +}
    • addedInput schema / properties / refine
      Added value: +{
      +  "default": false,
      +  "type": "boolean"
      +}
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations are minimal (readOnlyHint=false, destructiveHint=false). The description carries the full burden and does it well: it discloses async behavior (waits by default, returns jobId if wait=false), the AI_DETECTION_ALREADY_DONE response and its contents, the need for confirm_token on CONFIRMATION_REQUIRED, and the side effect of force=true (minting new field IDs). It also explains the internal POST /files/find-or-create call and the consequence of omitting envelope_id. This goes far beyond the annotations and is not contradicted by them.

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 (roughly 300 words) but every paragraph earns its place. It is front-loaded with the core purpose and then layers in usage, prerequisites, error handling, and workflow. It is structured with clear paragraphs and lists, making it scannable. While a more compact version could exist, the density of critical information justifies the length. It is not merely verbose; it is comprehensive and organized.

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 tool with 12 parameters, no output schema, and a complex async workflow, the description covers a remarkable amount: detection types, intent handling, refine/force flows, AI_DETECTION_ALREADY_DONE handling, file storage prerequisites, and the recommended follow-up steps. It lacks an explicit description of the success response payload structure (e.g., exact shape of data.placeholders), but it does mention that the output includes placeholders and that AI_DETECTION_ALREADY_DONE includes previous_run and user_options. This is a minor gap given the complexity; an explicit response schema would make it complete, but the description is strong enough for an agent to proceed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 8% (only confirm_token has a schema description). The description compensates extensively: it explains intent values ('board fields only', 'signer-fillable only', 'both'), the role of board_id ('Always pass board_id so columns reach the detector'), the envelope_id+item_id pairing requirement, the meaning of wait, refine, force, and job_id (via wait=false). It also clarifies confirm_token's origin. This is a textbook case of the description adding meaning where the schema is silent.

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 clear, specific statement: 'Run AI placeholder detection on a PDF document.' It immediately details what it detects (signer-fillable pads and Monday board fields), and differentiates itself from siblings by stating it is the required first step before getsign_save_document_configuration, and that the manual editor path skips it. This distinguishes it from the 26 sibling tools without ambiguity.

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?

Explicit when-to-use guidance: 'Prefer this when the user asks to auto-detect...' and when-not-to-use (manual editor path). It names the alternative tool (getsign_save_document_configuration, getsign_get_document_url) and the conditions for using them. It also provides critical prerequisites (e.g., 'For item / useFileColumn documents, always pass envelope_id + item_id') and a clear warning against constructing placeholders manually. This is exemplary usage 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