Jotform Sign

Makes an authenticated request to the Jotform REST API with the given method, body, and query parameters. The API host is resolved automatically for the current account, so pass only a relative path. WHEN TO USE: Prefer a dedicated tool when one exists for the requested action (for example: create_form, edit_form, list_submissions, search, fetch, display_form, analyze_submissions). Only use this tool as a fallback when no dedicated tool covers the request. See https://api.jotform.com/docs/ for the full API reference. COMMON ENDPOINTS (relative paths, grouped by resource; not exhaustive): - User: "user", "user/forms", "user/submissions", "user/folders", "user/reports", "user/settings", "user/usage". - Form: "form/{formID}", "form/{formID}/questions", "form/{formID}/question/{questionID}", "form/{formID}/properties", "form/{formID}/properties/{propertyKey}", "form/{formID}/submissions", "form/{formID}/files", "form/{formID}/reports", "form/{formID}/webhooks". - Submission: "submission/{submissionID}". - Report: "report/{reportID}". - Folder: "folder/{folderID}". RULES: - Use a relative path with no leading slash and no "API/" prefix (use "user", not "/API/user" or "/user"). - The endpoints above are examples, not a complete list. You may use any documented Jotform API endpoint. Do not invent sub-resources; if unsure, start from a parent/collection endpoint above (for example "form/{formID}/properties") instead of guessing a new path. - "emails", "conditions", "products" and "formStrings" are not standalone endpoints and are not valid {propertyKey} values. They are returned as grouped sections of "form/{formID}/properties", so read them from there. - Treat a 404 as "this path does not exist" and report it, instead of retrying variations of the same path. TIP: To reference a specific question or property, first GET the parent collection ("form/{formID}/questions" or "form/{formID}/properties") and use the IDs/keys returned there instead of guessing.

mcp_app_request

Create a signable document that can be sent to one or more signers for e-signature. Use this tool when the user wants to collect signatures, build a signing workflow, or prepare a document for signing. The document content is generated from a text prompt; an optional uploaded PDF, image, or DOCX can be passed as reference context (it is analyzed, not used as the final file).

createSignDocument

Refresh an already-created signable document in the rendered App so it can be previewed again after its previous preview expires. The refreshed document is handed to the App, which renders it; the response reports which document was refreshed. Requires the document_id and form_id of an existing sign document.

displaySignDocument

Edit an existing sign document. Can update the document title, regenerate the document content from a new prompt, or modify document settings. If the document was created from an uploaded file, a reconstruction of the document is needed for the edit operation, which may change how the document looks or reads. Before editing such a document, warn the user that the result may differ from the original and confirm with them before calling this tool.

editSignDocument

Retrieve the signers of a sign document or sign form — participants that have signature/date/text fields assigned to them — including their participant IDs, names, emails, roles, signing order, and signing status. When given a form ID, this returns signers across all of the form's documents (the editable draft plus every sent document), each annotated with its document ID and status. Participant roles with no assigned fields are excluded. Use this to see who has been sent a document and to get participant IDs before updating signers.

getSigners

Report the current status of a sign document including the overall document status and per-signer status (sent, viewed, signed, declined) with key timestamps. Accepts a sign document ID or a sign form ID (as seen in the /sign/{id} builder URL); when a form ID or draft document ID is given, the most recently sent copy is reported.

getSigningStatus

List signatures and signing submissions for sign documents. Use this tool when the user wants to view who has signed, check signatures, or see signing activity. You can list submissions for a specific sign document by passing its form_id, or across all sign documents when form_ids is empty. Do NOT use this tool to list the user's sign documents themselves — use the sign document listing/search tool for that.

listSubmissions

Search and list the user's Jotform products of these types only: sign document. Use this tool to find products by name or criteria, to list products of one or more types, or to get a product ID for another tool. It does not search submissions. product_type: array of types to include; ["ALL"] covers every available type (sign). filter.title_filter: array of plain strings matched against product titles (OR logic, no regex). Empty array lists all products of the requested types. filter.date_filter: [start, end] creation-date range in YYYY-MM-DD format, or empty array for no date filter. filter.status_filter: null lists active products. favorited_only/archived_only/trashed_only filter owned products by state; shared_only lists forms shared with the user; sent_only lists filled forms and contacted agents; drafts_only lists draft submissions; assigned_tasks_only lists approval tasks and assigned forms. filter.is_filtered_by_rules: LAST RESORT (extra AI call) — only when no title keyword can express the criteria, such as the language a title is written in or an abstract topic with no obvious keyword. When the request contains a plausible title word, ALWAYS prefer filter.title_filter with that word. Never present unfiltered results for criteria the filters could not express. Enterprise server admins: active-status searches cover ALL assets on the server (with owner and team info, server-wide totals and workflow error counts); owned-state filters stay scoped to the admin's own products. order_by: default "last_activity"; only use another option when the user asks for a specific sorting. Examples: (1) product_type=["ALL"], filter.title_filter=["invoice"] to find any product named like "invoice"; (2) product_type=["sign"] to list products of one type; (3) filter.status_filter="trashed_only" to list trashed products.

search

Send a sign document to signers via email. A sign document has a fixed set of signer roles (signature slots). Each send dispatches one independent copy of the document to one person per role — a "set". The number of signer roles only controls how many people are on a single copy; it is NOT a limit on how many people can ever receive the document. You can call this tool as many times as needed to send additional independent copies to different people: a one-signer document can be sent to any number of individuals (one copy each), and a multi-signer document can be sent to different sets of people (one copy per set). To send a copy to a different person or set of people, first point the signer role(s) at them with the updateSigner tool (set each role's name and email), then call this tool — there is no separate "add signer" step, and having only one signer role does not prevent sending to more people. Supports signing order and auto-reminders. This action emails real people — confirm with the user before calling.

sendForSignature

Update an existing signer role on a sign document with a person's name, email, and optional signing order. Use this to fill in signer details (e.g. after assignFieldsToSigners created the signer roles), or to re-target a signer role to a different person before (re-)sending: update the role's name and email here, then call sendForSignature again to send a new independent copy to that person. A document keeps the same signer roles across sends, so repeating updateSigner + sendForSignature lets you send copies to any number of different people even when there is only one signer role. Get valid participant IDs from getSigners. Call this tool once per signer role that needs updating.

updateSigner