Skip to main content
Glama

Get a URL to upload a PDF

create_upload_url

Get a short-lived URL to upload a PDF that GoodSign will turn into a document. Use this for a document that is NOT based on an existing GoodSign template — e.g. a Statement of Work, contract or NDA drafted for this specific deal. After the PUT succeeds, call create_document_from_upload with the upload_id this returns. The URL is valid for 15 minutes.

If you are GENERATING the PDF yourself, embed text tags where fields should go — GoodSign places a real field at each tag's exact position, and each distinct KEY becomes one signer (reuse the same KEY on every tag that person fills).

TAG REFERENCE — this is the complete list; any other tag type is discarded:

  • [sign|KEY] signature. [in|KEY] initials. Signature size variants: [signxs|KEY] [signsm|KEY] [signmd|KEY] [signlg|KEY] [signxl|KEY].

  • [date|KEY] date of signing, filled in automatically.

  • [input|KEY] required text box. [input?|KEY] optional text box. [input|KEY|Some text] pre-filled, signer can edit.

  • [name|KEY] and [email|KEY] text boxes pre-filled with that signer's name / email address.

  • [c|KEY|Label] optional checkbox. [c*|KEY|Label] required checkbox. [c|KEY|x Label] pre-checked. [c1|KEY|Red] [c1|KEY|Blue] = radio group (same digit = one group, signer picks one).

RULES — breaking any of these corrupts or silently drops fields:

  1. KEY is the signer key: letters and digits ONLY (Client, signer1), identical spelling and case on every tag for that person. Keys differing only in case, spaces or punctuation collide into the wrong signer. Exception: trailing padding spaces before the closing ] (rule 4) are stripped before the key is matched, so [name|Client ] still keys to Client.

  2. A tag must be one unbroken run of selectable text on a single line in a normal font — never an image, never wrapped across lines.

  3. Do not use square brackets anywhere else in the document — prose like "[insert date]" gets parsed as a tag. Use parentheses instead.

  4. The tag's printed size becomes the field's size: its font size sets the field height, and an input/name/email box is exactly as wide as the printed tag text — write the tag at the size you want the answer to be. To WIDEN an input/name/email field without making it taller, pad with trailing spaces INSIDE the tag before the ] — e.g. [name|Client ] — the spaces count toward the printed width but are stripped from KEY. Spaces after the ] do nothing. Print the tag in a monospace font (e.g. Courier) so each padding space adds a full, predictable character width.

  5. Leave 2-3 blank lines of clear space around sign/in tags: the drawn signature renders much larger than the tag text.

GoodSign erases the tag text from the final PDF and renders the field value in its place. After create_document_from_upload, confirm with get_document that the signer keys and field count match what you embedded.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Discloses rich behavioral details well beyond the sparse annotations: short-lived URL, PUT flow, 15-minute expiry, tag parsing rules, key collisions, field sizing, and the fact that tag text is erased from the final PDF. It even warns about corruption or silent drops, which is critical for correct invocation.

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?

Although long, the description is front-loaded with the core purpose and then organized into a tag reference and numbered rules where every sentence conveys an operational constraint. No filler or redundant restatement is present; the length is justified by the complexity of the PDF tag behavior.

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?

Given that there is no output schema and minimal annotations, the description carries the full burden and succeeds: it identifies the returned upload_id, gives the complete tag spec, explains the required PUT workflow, and recommends verification with get_document. An agent has enough to invoke the tool and the dependent tool correctly.

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?

The input schema has zero properties, so the 0-parameter baseline of 4 applies. The description adds no parameter details (there are none), but its workflow and tag guidance are the relevant operational semantics for this tool.

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 immediately states a specific action ('Get a short-lived URL to upload a PDF') and the downstream conversion intent. It differentiates from siblings by explicitly scoping to documents NOT based on an existing GoodSign template, separating it from template-based flows like send_from_template.

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?

Gives explicit when-to-use guidance: non-template documents such as SOW/contract/NDA, and instructs the agent to call create_document_from_upload after the PUT. It also specifies the 15-minute validity and when to embed tags (if generating the PDF yourself), making the usage context unmistakable.

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