Build an AI Agent That Creates Flipbooks

What if “publish this month's report as a flipbook” was a thing your computer did on its own — no dashboard, no upload, no copy-pasting a share link into an email? That's the promise of an AI agent for documents: you describe the outcome, and the agent calls the right tools in the right order to make it happen.

This tutorial shows how to build one with the FlipLink MCP server and Claude. The agent will take a freshly generated PDF report, create a flipbook from it, publish it, and hand back a share link — the kind of thing you can run on a schedule and forget about. We'll also be honest about where a fully unattended agent hits real limits, and when a plain script (the CLI) is the better tool.

The scenario: an auto-published monthly report

Picture a recurring job. On the first of every month, some pipeline produces report.pdf — sales numbers, a newsletter, a board deck. Today a human uploads it to the dashboard, publishes it, copies the link, and pastes it somewhere. We want to automate that with an agent that can reason about the steps instead of us hard-coding every one.

The agent needs to be able to: create a flipbook from the file, publish it, and fetch the share link. With the FlipLink MCP server connected, those map to real tools the model can call directly.

Step 1 — Wire up the MCP server

The Model Context Protocol is how an AI client (Claude, Cursor, and others) discovers and calls external tools. The FlipLink MCP server exposes the FlipLink API as a set of tools the model can use in a conversation.

For the full walkthrough, see Connect FlipLink to Claude with the MCP server. The short version — nothing to install by hand, your client launches it with npx:

claude mcp add fliplink -e FLIPLINK_API_KEY=YOUR_API_KEY -- npx -y fliplink-mcp

Or, as an mcpServers config block (Claude Desktop, Cursor, Codex):

{
  "mcpServers": {
    "fliplink": {
      "command": "npx",
      "args": ["-y", "fliplink-mcp"],
      "env": { "FLIPLINK_API_KEY": "YOUR_API_KEY", "FLIPLINK_MCP_MODE": "safe" }
    }
  }
}

Tools are generated from the FlipLink spec and named <noun>_<verb> — so the agent will see flipbook_create_by_file, flipbook_publish, flipbook_get_share_link, and a top-level whoami health check, among others. Get your key by signing in at go.fliplink.me.

Step 2 — Write the agent prompt

An agent is really just a model plus a loop: it reads the goal, decides which tool to call, reads the result, and decides what to do next until the goal is met. The quality of that loop comes almost entirely from a clear prompt that names the tools, the order, and the success condition.

Here's a realistic system/task prompt for the monthly-report agent:

SYSTEM:
You are a publishing agent for FlipLink. Your job is to turn a PDF report
into a published flipbook and return its share link. You have FlipLink MCP
tools available (names follow the pattern noun_verb).

Operating rules:
1. Start by calling `whoami` to confirm the API key works and check the
   remaining flipbook quota. If `whoami` fails, STOP and report the error.
2. Create the flipbook from the file with `flipbook_create_by_file`
   (field File = the PDF path; set Name and Title from the task).
3. Read the result. Every FlipLink response has a top-level `Result` field
   that is "OK" or "ERROR". If `Result` is "ERROR", STOP and report the
   `Message` — do NOT retry blindly or proceed.
4. On success, capture the returned flipbook ID.
5. Publish it with `flipbook_publish` using that ID. Check `Result` again.
6. Fetch the share link with `flipbook_get_share_link`.
7. Report back: the flipbook ID, the published share URL, and the quota left.

Never invent tool names or IDs. If a step has no clear next action,
stop and explain rather than guessing.

TASK:
Publish this month's report. File: ./reports/2026-06-report.pdf
Title: "June 2026 Report". Name: "june-2026-report".

Two things make this prompt work. First, it tells the agent to branch on the Result field — FlipLink returns application errors as HTTP 200 with Result: "ERROR", so a naive “did the call return 200?” check would silently treat failures as successes. Second, it gives an explicit stop condition for every failure path, which keeps an unattended run from spiraling into retries.

Step 3 — Guardrails for unattended runs

This is where you have to be clear-eyed. The default MCP mode is safe (79 tools): reads plus reversible writes, with no delete and no commerce tools. Our monthly-report agent only creates, publishes, and reads — all of which fit inside safe mode — so for this job you can leave the default and the agent runs end to end without friction.

Destructive actions are a different story. If your agent ever needs to delete a flipbook or touch pricing/sales, it must run in full mode (87 tools). In full mode, delete and money tools never run on the first call: the server returns a one-line preview plus a short-lived confirm_token (bound to the exact arguments, expires in 5 minutes), and the assistant has to call again with that token. That gate lives in the server — the FlipLink API itself is unchanged.

Be honest about what this means for “fully autonomous”:

• A read-and-create-and-publish agent in safe mode can run unattended cleanly. Nothing it does is gated.
• An agent that deletes things cannot be frictionless and unattended at the same time. The confirm-token gate is there on purpose. Either a human approves the destructive step, or your harness runs in full mode and explicitly handles the preview → confirm-token → second-call handshake in code. Don't design a pipeline that assumes a flipbook will silently delete itself with no confirmation — it won't, and that's the point.

For the full breakdown of modes and the confirm-token flow, see MCP server safety and guardrails. The tools also carry MCP annotations (readOnlyHint, destructiveHint, idempotentHint) so a careful harness can reason about risk before it calls anything.

🚀

Try FlipLink Free

Convert your PDF in seconds. No sign-up, no credit card — just upload and go.

Drop your PDF here or click to browse

Max 40MB

Paid plans from $39 raise this to 150 MB.

Step 4 — Schedule it

Once the agent runs reliably by hand, put it on a timer. How you do this depends on your client — a cron job that invokes Claude headlessly with the task prompt, a scheduled workflow, or your own orchestration. The mechanics are out of scope here; the important part is that the prompt and the mode are what make a scheduled run safe, not the scheduler itself. Keep the agent in safe mode for create/publish jobs, and the run stays unattended without hitting a confirmation wall.

Step 5 — Verify the output

Don't trust “the agent said it worked.” Verify the real artifact:

• The agent's final report should include a flipbook ID and a share URL. Open the URL — it should load the published flipbook.
• Spot-check whoami quota before and after, so you know the create actually consumed one slot rather than erroring silently.
• Because every tool result carries a Result field, a well-built agent surfaces the exact Message on failure. If the run reports Result: "ERROR", read the message rather than re-running — a quota limit or oversize file won't fix itself on retry.

When the CLI is the better tool

Here's the honest counterpoint to all of the above: for a headless, deterministic job in CI, you usually don't want an LLM agent at all.

An AI agent shines when the task involves judgment — deciding what to title something, reacting to ambiguous input, or chaining steps you didn't fully spell out. But “take this exact file, create a flipbook, publish it, print the link” has zero ambiguity. Running an LLM for it adds cost, latency, and non-determinism for no benefit, and you still have to handle the same Result branching.

For that, reach for the FlipLink CLI. It's generated from the same spec as the MCP server and the API, so it can't drift, and it returns clean exit codes (0 success, 1 request error, 2 application error) that CI can branch on without any parsing:

fliplink config set-key "$FLIPLINK_API_KEY"
ID=$(fliplink flipbook create ./reports/2026-06-report.pdf \
  --title "June 2026 Report" --name june-2026-report --json | jq -r '.ID')
fliplink flipbook publish "$ID"
fliplink flipbook share-link "$ID"

That's the whole monthly job, no model required. For a complete pipeline — including running it inside continuous integration — see Automate flipbook publishing in CI/CD.

Rule of thumb: use an AI agent when the task needs judgment; use the CLI when it needs to be the same every time. Many teams run both — the agent for ad-hoc “publish this for me” requests, the CLI for the scheduled, mechanical runs.

Start building

An AI agent for documents removes the manual middle of publishing: you state the outcome, it calls the tools. With FlipLink MCP in safe mode, a create-and-publish agent runs end to end without friction — and where destructive actions enter the picture, the confirm-token gate keeps unattended runs honest rather than dangerous.

Ready? Connect the MCP server, point an agent at a report, and watch it publish. For the deterministic CI path, the CLI docs have you covered. The full endpoint catalog lives in the API reference.

Related Reading

• Connect FlipLink to Claude with the MCP server
• MCP server safety and guardrails
• Natural-language flipbook automation
• Automate flipbook publishing in CI/CD
• The FlipLink CLI documentation
• The FlipLink API reference