MCP for paperworkFilled: letting AI agents fill and send forms

Your ops engineer has an agent that already reads the inbox, finds the client in the CRM and drafts a reply. The next request is obvious: "and fill in the lease application while you're at it, then send it to both tenants to sign." Until recently that meant writing glue code for every form tool. Now there's a standard socket for it.

This piece explains what the Model Context Protocol means for paperwork, walks through a real flow from client record to signature, and sets out the guardrails we think any agent should have around forms. It builds on our look at what general chat assistants can and can't do with PDFs.

What is MCP, in one paragraph?

The Model Context Protocol is an open standard for connecting AI applications to outside systems. An MCP server exposes tools, such as "fill this document," that any compatible AI app can call. The protocol's own site describes it as "an open-source standard for connecting AI applications to external systems."

The MCP site (opens in a new tab) puts it in a sentence: "Think of MCP like a USB-C port for AI applications." It lists support across AI assistants such as Claude and ChatGPT and developer tools such as Visual Studio Code and Cursor. For a team, that means one integration that works from whichever assistant your people already use.

The three roles you'll hear about:

Why is paperwork a good fit for AI agents?

Paperwork is mostly moving known facts from one place to another: a client's name, date of birth and address, from a record into a form, many times over. The inputs are structured, the output is checkable field by field, and the slow part is retyping. That's exactly the kind of work an agent with the right tools does well.

Good fits:

• Repeat forms from a record. Intake, onboarding, tenancy, engagement letters.
• Batch jobs. "Fill the lease for every applicant in this sheet."
• Routing. "Send it to both tenants, in order, with reminders."
• Status questions. "Who hasn't signed yet?"

Poor fits, at least without a person:

• Declarations and judgment questions. "Has the applicant ever...?" isn't a lookup.
• Anything final. Submitting an application or paying a fee commits a person to it.
• Records with gaps. An agent will happily invent a plausible middle name unless the tool stops it.

What does an agent's paperwork flow look like?

Find the record, upload the form, detect its fields, fill what the record supports, read back the per-field results, stop on anything flagged, then send for signature. Each step is a tool call, and each result tells the agent what really happened, so it can ask a person instead of carrying on.

Here's an example session with AppliFlo's MCP server, using a lease form and a tenants spreadsheet (example data, made up):

1. Ask. "Fill lease-2026.pdf with tenants.csv row 2."
2. upload_document returns a document ID.
3. detect_fields finds 14 fields and flags 1.
4. fill_document fills 13 and reformats one date to the form's MM/DD/YYYY.
5. Per-field result: guarantor_phone: needs a human (no value in row 2).
6. The agent stops and asks for the guarantor's phone number.
7. Ask. "Send it to both tenants for signature."
8. send_envelope creates an envelope with two signers, awaiting signature.

Step 5 is the important one. Every fill returns per-field results (filled, shrunk to fit, reformatted, overflowed, needs a human), so the agent branches on what happened instead of shipping a broken PDF.

How do you keep an AI agent from submitting or paying?

Don't give it the tools to. Expose only actions that prepare documents and route them to people, keep keys narrow and revocable, make flagged fields a hard stop, and leave signing to the signers. An agent that can't submit or pay can't do either by mistake, or because a document it read told it to.

Guardrails we'd put on any paperwork agent:

• No submit, no pay. The toolset should end at "send for signature." AppliFlo never submits a form or pays, with or without an agent.
• Narrow, revocable keys. One key per integration, stored as a secret, rotated if exposed. AppliFlo stores only a hash of each key and shows it once.
• Flags are hard stops. No sending while any field needs a human.
• People sign. Signature lines are routed to signers, never filled by the agent.
• Least data. Give the agent the record it needs for this form, not the whole CRM.
• Treat documents as data, not instructions. Text inside an uploaded PDF shouldn't be able to redirect the agent. MCP's own docs include a security best-practices section worth reading.
• Logs. Keep a record of every call and its per-field result.

We go further into the reasoning in Flag, don't guess.

How do I get started with the AppliFlo MCP server?

Get an API key on the Business plan, add the AppliFlo MCP server to your MCP client with that key, and call the tools. The same key works for the REST API, and every REST endpoint has a matching MCP tool with the same name and the same per-field results. The developers page has the quickstart.

What's available, per the AppliFlo developers page:

Limits to plan for: 120 requests a minute per key, a shared pool of 20 a minute across detect, fill and send, and AI pages counted the same as in the app. Past the limit, a read returns ai_pages.exhausted. Plan details are on the pricing page.

Signed documents go through AppliFlo Sign, so each one gets a PAdES seal, a certificate of completion and an audit trail.

Where is this heading?

Agents will do more of the paperwork, but the shape of the work won't change much: facts from a record, into a form, checked, signed by people. The tools that suit agents best will be the ones that report exactly what happened to every field and refuse to cross the lines that belong to humans.

If your data lives in spreadsheets rather than a CRM, our guide to filling PDFs from Excel, CSV or your CRM covers the non-agent route to the same result.

Routing a document for signature isn't legal advice. Check your own compliance requirements before sending contracts.