Give your agent hands: the paperwork CLI, skills, and MCP

Four days of launch week gave you the parser, signature, audio, and yesterday the whole API. Today is about who calls it. Increasingly, that is not a person typing curl. It is Claude Code, or Codex, or an agent you wrote, working through a folder of PDFs on someone's behalf.

Agents are bad at documents for a boring reason: a document is big, and an agent's context is small and expensive. The naive move is to cat the PDF into the chat and hope. That works for a two-page letter. It does not work for a lease, a policy, or a thousand-page discovery packet, and it leaks anything sensitive straight into a model's working memory.

So we built the agent tooling around one idea: the agent should never read the document. It should ask for exactly the fields it needs, get them back with citations, and move on. Three layers make that work. Use one, two, or all three.

Layer one: the CLI

The paperwork command line wraps the whole Paperwork API. Every resource is a subcommand, output is JSON, and it authenticates with your CloudRaker account or an API key.

brew install cloudraker/tap/paperwork
# or
curl -fsSL https://paperwork.sh | sh

paperwork auth login          # one-time browser sign-in, token refreshes itself
paperwork files list-files --limit 1   # any 200 means auth works

Yes, we bought paperwork.sh for this. No regrets. Windows users: irm https://paperwork.sh | iex.

Running headless, in CI, or inside an agent? Skip the browser. Create a key under Admin → API keys and export it as PAPERWORK_TOKEN. It always wins over the stored login, and a .env in the working directory is loaded automatically.

Then every capability is a command. Upload a file, parse it, and a PDF has become something a model can read:

FILE=$(paperwork files upload ./lease.pdf | jq -r .id)
paperwork parse parse --json "{\"file\": {\"id\": \"$FILE\"}}"

Three flags earn their keep. Output is a table when you are looking at it and JSON when you pipe it. --query takes a JMESPath expression, so you slice a response without reaching for jq. And --dry-run validates a request locally before anything goes over the wire.

Two more exist for the AI crowd. --schema makes every command print a machine-readable JSON Schema of itself: help text for humans, schemas for robots, so an agent can discover the whole surface without guessing. And paperwork generate-skills writes SKILL.md files from that surface, if you want to roll your own. You probably do not need to, because of layer two.

Layer two: the skills

The CLI tells the agent what it can do. The skills tell it how to behave. Documents have sharp edges. Some calls finish in a second. Some take minutes. Some pause and wait for a human. An agent that does not know which is which wastes turns, burns context, or polls a person like a stuck elevator button.

cloudraker-paperwork-skills is our maintained skill pack, in the open Agent Skills format, so it works in Claude Code, Codex, and anything else that reads the format.

npx skills add cloudraker/cloudraker-paperwork-skills

Or, in Claude Code, as a plugin:

/plugin marketplace add cloudraker/cloudraker-paperwork-skills
/plugin install paperwork

One skill per capability, plus an umbrella that routes between them:

• paperwork
• paperwork-parse
• paperwork-extract
• paperwork-classify
• paperwork-fill
• paperwork-redact
• paperwork-sign
• paperwork-compose
• paperwork-pipeline
• paperwork-files
• paperwork-redline
• paperwork-spaces
• paperwork-runs
• paperwork-agents
• paperwork-webhooks

The house style they teach

These rules make sense even if you never open the files.

1. Wait for PDFs, poll everything else. A digital PDF parses inside the default 60-second hold, so the agent just waits. Scans, audio, batches, pipelines, and signatures go out with --wait 0 and get polled every ten seconds. A 202 is not an error. It is the API saying "working on it."
2. Documents never enter the agent's context. No cat-ing a PDF into the chat. No pasting a transcript into its own head. The agent extracts with a schema, or searches the space, and pulls only what it needs. Your agent handles a thousand-page contract without reading a thousand pages.
3. A space per job. A space is a persistent, searchable container for files. The agent mints one, saves the id, and everything for that job lives there.
4. Upload once, reuse the file id everywhere. Parse once, run many. The biggest cost and latency saver on the API, and your bill will thank you.
5. Repeated shapes become saved configs. Repeated files become batches. Multi-step jobs become pipelines. The agent should notice when it is doing the same thing twice.
6. Humans run on human timescales. When a run needs a signature or a review, the agent tells you and moves on. It does not sit there polling a person. We have all worked with someone who does that. Do not build that person.
7. Decide keep-or-expire the moment a run finishes. runs keep-run promotes a result into a space. Everything else purges at its TTL, and nothing accumulates.

Layer three: MCP

If your agent speaks Model Context Protocol, or it lives in a chat window and cannot run a shell, point it at https://mcp.cloudraker.com. We wrote about the design last month. The short version: instead of fifty hand-written tools that drift out of date, the server exposes exactly two, search and execute, built live from the API's OpenAPI spec. The agent searches the surface, generates a call, and runs it. Generated code runs in an isolated worker with no network of its own. The real call happens on the host with your key injected there, so the credential never enters the sandbox.

claude mcp add --transport http cloudraker https://mcp.cloudraker.com \
  --header "Authorization: Bearer $CLOUDRAKER_API_KEY"

In claude.ai or Claude Desktop, add https://mcp.cloudraker.com as a custom connector. It discovers OAuth on its own. No token to copy. Nine guided skills ship with the server as skill:// resources, so a chat client gets the same house style the CLI pack gives a coding agent.

There is a second server for the docs themselves, https://docs.cloudraker.com/_mcp/server, so an agent can query the documentation instead of scraping pages. And for an agent writing an integration from scratch, docs.cloudraker.com/developers/agents.md is the whole API contract in one Markdown file, short enough to hold in context.

What it looks like

Give Claude Code the CLI and the skills, then ask for something real:

Extract the rent, term, and expiry from lease.pdf, then send the abstract to the tenant for signature.

Here is what a well-behaved agent does. It mints a space for the job. It uploads the lease once and keeps the file id. It runs extract with a small schema and citations: true, fires with --wait 0 because a scan might need OCR, and polls. It reads three fields and the page each one came from. It composes the abstract from a template, runs sign, and when the run lands on needs_input, it tells you a human has to sign and moves on to the next thing.

At no point did it open the PDF. That is the whole point.

Getting started

curl -fsSL https://paperwork.sh | sh
paperwork auth login
npx skills add cloudraker/cloudraker-paperwork-skills

The CLI reference is paperwork <resource> --help, and every command answers --schema. The skills are on GitHub, MIT. The MCP setup and the agent quickstart are at docs.cloudraker.com/developers/agents. Grab a key at signup.cloudraker.com.

Go build something. Preferably something that fills out forms, so you never have to.

Launch week: Day 1, rakedoc-nano · Day 2, RakeSign · SOC 2 Type 2 · Day 3, rakeaudio-asr · Day 4, the Paperwork API · Day 5, agent tools.