Formify — AI Assisted E-Signing

Request File Upload URL

request_file_upload_url

Stage an upload for a PDF that is attached to the conversation, for clients that can execute shell commands but cannot pass the file to a tool directly. Returns a presigned upload URL plus a ready-made curlCommand that streams the file to it. Only use this tool if you are able to run that command; if you cannot, skip it and call upload_file directly with fileReference (a file reference supplied by the host application), url (a PDF reachable over HTTPS) or file (base64) plus fileName. After calling this tool, run the returned curlCommand to upload the file. CRITICAL: wait for it to complete and return HTTP 200 before calling upload_file — the staged entry holds no bytes until then, and upload_file will fail. The upload URL expires in 10 minutes. Once the upload has succeeded, call upload_file with the returned uploadId. ONE AT A TIME: only one staged upload can be pending per user. Finish the current file (curl, then upload_file) before requesting the next — do not request several upload URLs up front, not even for files that will be merged. A request made while another upload is pending is refused with an error that repeats the pending uploadId and, while its file has not arrived yet, its curl command so you can finish it; that refusal is expected, not a server fault. If the curl command fails with a network, DNS, or 'host not in allowlist' error, the client's code-execution sandbox is blocking outbound requests to this server — do not retry the same command. Report what blocked it, then either fall back to upload_file with file (base64), or, if the client lets the user allow outbound domains for code execution (the setting lives in the client's code-execution or sandbox preferences), tell the user how to allow this server's domain there and retry once they have done so.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`fileName`	Yes	Filename with extension (e.g. 'contract.pdf')

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 10, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only convey that it is not read-only (readOnlyHint=false); the description carries the full burden and delivers richly. It discloses that the staged entry holds no bytes until curl completes, the 10-minute URL expiry, the single-pending-upload-per-user rule, the exact refusal behavior (repeating pending uploadId and curl command), and how to diagnose sandbox blocking (network/DNS/allowlist errors). This is well beyond what annotations provide.

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 every sentence earns its place given the complex two-step protocol, fallback path, and error-handling rules. CAPS markers (CRITICAL, ONE AT A TIME) highlight the highest-stakes guidance, and the flow is mostly chronological. It is dense rather than padded, though a bit monolithic in structure.

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?

With no output schema, the description correctly explains what is returned (presigned URL, curlCommand, uploadId) and covers the full lifecycle: request, execute curl, wait for HTTP 200, call upload_file, one-at-a-time constraint, refusal handling, and fallback to direct upload. Nothing an agent needs to execute the tool correctly is missing.

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

Parameters3/5

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

Schema coverage is 100% and there is only one parameter (fileName), so the schema already fully documents it. The description reinforces that the file is a PDF and ties the parameter to the attachment context, but it does not add meaningful new semantics beyond what the schema states. Baseline 3 is appropriate.

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 states a specific verb and resource ('Stage an upload for a PDF... Returns a presigned upload URL plus a ready-made curlCommand'), which clearly distinguishes it from the sibling upload_file. The scoping to shell-capable clients and the explicit mention of the two-step flow make the purpose unambiguous.

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?

Extremely explicit: it names the exact condition for use (can execute shell commands but cannot pass the file to a tool), the when-not path (skip and call upload_file with fileReference/url/file), the required follow-up order (run curl, wait for HTTP 200, call upload_file with uploadId), and the one-at-a-time constraint. No inference is required.

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

All Formify — AI Assisted E-Signing tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?