MCP Safety: How FlipLink Guards Destructive Actions

Connecting an AI assistant to a real tool is exciting right up until you realize the assistant can now do things — create, publish, and yes, delete. When you hand an AI agent the keys to your FlipLink account through an MCP server, the obvious question is: what stops it from deleting a published flipbook or changing a price because it misread your request?

This guide walks through how the FlipLink MCP server handles MCP server security — the three modes you can run it in, the confirm-token gate that protects destructive and money actions, and how to choose the right setup for the way you work.

Why Letting an AI Run Write and Delete Is Risky

A read-only AI is low-stakes. The worst it can do is summarize the wrong list. But the moment an assistant can call flipbook_delete or change pricing, a single misunderstanding has real consequences: a misread instruction, an over-eager “clean up old flipbooks” loop, or a prompt-injection attempt buried in a document can all turn into actions you never intended.

The fix is not to ban writes — that defeats the point of automation. The fix is graduated trust: expose only what the task needs, and put a deliberate speed bump in front of the actions you can't easily undo.

The Three Modes

FlipLink's MCP server ships with three modes, set with the FLIPLINK_MCP_MODE environment variable. Each mode controls exactly which tools the AI client can even see — if a tool isn't exposed, the assistant cannot call it.

A few things worth calling out:

• safe is the default. If you set nothing, you get reversible writes only — create, publish/unpublish, set expiry, assign to folder, configure lead capture. The actions you'd be comfortable undoing by hand.
• readonly is perfect for analytics and reporting. Point an assistant at your account to answer “how many flipbooks did we publish this quarter?” with zero chance of a write.
• full unlocks the last 8 tools — delete and commerce — but those don't fire on the first call. They go through the confirm-token gate.

You set the mode in your client config block alongside your API key:

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

The Confirm-Token Gate

In full mode, the two riskiest categories — destructive actions (deleting a flipbook) and money actions (sale and pricing changes) — never run on the first call. Instead, the server uses a preview-then-confirm handshake.

When the assistant calls a gated tool, the server does not perform the action. It returns a one-line preview of what would happen plus a short-lived confirm_token. That token is bound to the exact arguments of the call and expires in 5 minutes. To actually run the action, the assistant has to call the tool again with the matching token.

Here's the round trip. First call — the assistant asks to delete a flipbook:

// Call 1: flipbook_delete { "FlipbookID": "90442" }
// Server response (nothing deleted yet):
{
  "preview": "Will permanently delete flipbook 90442 (\"Q3 Sales Deck\").",
  "confirm_token": "cf_9f3a...e21",
  "expires_in": 300
}

The assistant shows you that preview. If you say go ahead, it calls again with the token:

// Call 2: flipbook_delete { "FlipbookID": "90442", "confirm_token": "cf_9f3a...e21" }
// Now the action runs:
{ "Result": "OK" }

Because the token is args-bound, an assistant can't get a token for deleting flipbook A and reuse it on flipbook B — the arguments won't match and the server rejects it. And because it expires in five minutes, a token left lying around in a long conversation goes stale on its own.

How to Pick a Mode

A simple rule of thumb:

• Just exploring or reporting? Use readonly. You get insight with zero risk.
• Day-to-day automation — creating and publishing flipbooks? Use safe (the default). Everything you do is reversible.
• You genuinely need delete or pricing automation? Use full, and rely on the confirm-token gate to keep the irreversible actions deliberate.

Most people should stay on safe. Reach for full only when a specific workflow needs it — for example, an end-of-quarter script that retires old flipbooks — and even then, the gate ensures every deletion is previewed before it happens.

🚀

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.

Server-Side Enforcement (the API Is Unchanged)

One important detail: all of this lives in the MCP server, not in the FlipLink API. The REST API is exactly the same as it always was — same endpoints, same X-Api-Key auth, same Result response model. The modes and the confirm-token gate are guardrails the MCP layer adds on top.

That matters for two reasons. First, your existing API integrations and scripts are unaffected — nothing about them changes. Second, the safety isn't something the AI client can talk its way around: the server simply doesn't expose hidden tools in readonly/safe, and it refuses to act on a gated tool without a valid token. The enforcement is structural, not advisory.

If your API key is missing or wrong, every tool returns clear setup instructions instead of failing silently — so a misconfigured client tells you what to fix.

MCP Annotations

On top of mode filtering and the gate, every tool carries standard MCP annotations — metadata hints that well-behaved AI clients read to understand a tool's nature:

• readOnlyHint — the tool only reads; it won't change anything.
• destructiveHint — the tool can remove or overwrite data (e.g. delete).
• idempotentHint — calling it twice with the same arguments has the same effect as calling it once.

These hints let a thoughtful client surface its own warnings or ask for confirmation before invoking a destructive tool — an extra layer of caution that complements the server-side gate rather than replacing it.

FAQ

Is MCP safe to use with a real account? Yes, when the server is built with guardrails. FlipLink defaults to safe mode (reversible writes only), and the irreversible actions in full mode are protected by a confirm-token gate. You decide how much access to grant via FLIPLINK_MCP_MODE.

What does the default mode actually allow? safe mode exposes 79 tools: reads, reversible writes (create, publish, set expiry, assign to folder), and access-control settings. It does not include delete or any commerce/pricing tools.

Can the AI delete a flipbook without my approval? Not in readonly or safe — the delete tool isn't even exposed. In full mode, delete is gated: the server returns a preview and a 5-minute confirm token first, and the action only runs when the assistant calls again with that exact token.

Does any of this change the FlipLink API? No. The modes, the gate, and the annotations all live in the MCP server. The underlying API — endpoints, X-Api-Key auth, and the Result model — is unchanged, so your existing integrations keep working as-is.

Related Reading

• What Is an MCP Server?
• Connect FlipLink to Claude with an MCP Server
• Build an AI Agent That Creates Flipbooks
• FlipLink MCP server overview
• FlipLink API reference