• 

  Prompt becomes a structured agreement with Foxit PDF evidence.

• 

  Clause risks are surfaced before the agent can create a signing request.

• 

  Foxit API activity proves draft-first eSign dispatch and audit history.

• 

  Human approval is bound to the exact PDF fingerprint and signer.

Inspiration

The dangerous moment in document automation is not drafting. It is commitment. An agent can safely retry reversible PDF work, but sending a signature request contacts a real person and may create a legally binding outcome. ClauseGate makes that boundary explicit, cryptographically bound, and auditable.

What it does

ClauseGate accepts a plain-language agreement request, structures the parties, scope, term, price, payment, revisions, and signer, then uses Foxit PDF Services for the reversible document pipeline. It flags financial, liability, intellectual-property, payment-trigger, and date risks before creating a signing request.

The exact PDF bytes are fingerprinted with SHA-256. A human must review the PDF, recipient, and risk summary and enter an approval phrase tied to that hash. The server regenerates and rehashes the document; any changed byte invalidates approval. Only then may ClauseGate call Foxit eSign to create a draft and dispatch it.

How we built it

ClauseGate is a TypeScript and React application deployed on Cloudflare Workers. The runnable Foxit PDF Services MCP evidence pipeline uses the official @foxitsoftware/foxit-pdf-api-mcp-server and calls:

• upload_document
• pdf_from_text
• get_task_result
• download_document
• get_pdf_properties

It records Foxit document IDs, extracted properties, output path, and tool order as evidence.

The eSign boundary uses Foxit's REST API:

• POST /api/oauth2/access_token for a scoped token.
• POST /api/folders/createfolder with processTextTags enabled and sendNow false.
• POST /api/folders/sendDraftFolder only after approval passes.
• GET /api/folders/viewActivityHistory for the signing audit trail.

Challenges we ran into

Creating a signing folder is not idempotent, may email a real recipient, and begins a legal workflow. We deliberately kept eSign outside the agent's MCP tool catalog and implemented it as a separately authorized state transition. The reviewed SHA-256 must match the regenerated PDF; recipient changes invalidate approval; duplicate folders are blocked by document hash; and failures after draft creation never trigger silent recreation.

The public demo never emails anyone. Live mode requires an allowlisted signer and creates a draft before dispatch.

Accomplishments that we're proud of

ClauseGate demonstrates a concrete autonomy boundary instead of merely adding an approval button. The approval is bound to the exact PDF bytes, signer, surfaced risks, and API action. Judges can see what the agent may do alone, where it must stop, and the evidence produced on either side of that line.

What we learned

Human-in-the-loop controls are strongest when approval is attached to immutable evidence, not to a vague workflow state. Foxit's reversible PDF operations and consequential eSign operations create a natural, defensible boundary.

What's next

Reusable policy packs for procurement, employment, NDAs, and regulated documents; multi-reviewer approval policies; signed-document verification; completed-envelope retrieval; and organization-level audit dashboards.

Built With

• cloudflare-workers
• foxit-esign
• foxit-pdf-services
• human-in-the-loop
• mcp
• react
• sha-256
• typescript