update_flyer
Replace the contents of a flyer you already published, keeping the same URL. Use this for every revision to a page that is already live — a fix, a new section, a chart the user asked you to add — so the link they may have already sent to someone keeps working and shows the new version. Prefer thi...
This record as markdown: /tools/com-flingflyers-flingflyers/update-flyer.md
What update_flyer does on Flingflyers
AI agents use update_flyer to create or update resources in Flingflyers, usually the action step of a workflow, after the agent has gathered context. Every call changes real data in your Flingflyers environment.
| Parameter | Type | Required | Description |
|---|---|---|---|
id | string | Yes | The flyer id, e.g. x7Kp2mQ. |
html | string | Yes | The complete replacement HTML document, including <!doctype html>. Must be self-contained. |
ttl_hours | integer | — | Optional. Reset the expiry to this many hours from now, maximum 720 (30 days). Omit to keep the flyer's existing expiry. |
owner_token | string | Yes | The owner_token returned by publish_flyer. |
Parameters from the server's own tool schema.
Why update_flyer is rated Medium
This tool modifies existing data (flyer contents) reversibly without deleting anything. It's a standard update operation. Severity is medium because: (1) it modifies publicly-shared content that may have been distributed, potentially affecting downstream users; (2) the description emphasizes this keeps 'the same URL', meaning changes are invisible to link recipients; (3) however, the owner token acts as a mitigating…
From the tool's definition Tool description states 'Replace the contents of a flyer you already published' and 'for every revision to a page that is already live' — these are classic modify/update operations.
Risk signalsAccepts raw HTML/template content (html) · Bulk/mass operation — affects multiple targets
Attacks that exploit this kind of access
The rule that runs update_flyer safely
PolicyLayer is an MCP gateway: it sits between your AI agents and Flingflyers, and checks every tool call against a rule you set before the call runs. Nothing changes on the server itself. For update_flyer, this is the rule to start with:
update_flyer stays usable, but capped: an agent stuck in a loop can't make hundreds of changes a minute. Everything else on the server is denied unless you say otherwise.
The button opens the PolicyLayer dashboard: create your workspace, connect Flingflyers, apply this rule, and every update_flyer call is checked against it from then on.
Questions about update_flyer
Replace the contents of a flyer you already published, keeping the same URL. Use this for every revision to a page that is already live — a fix, a new section, a chart the user asked you to add — so the link they may have already sent to someone keeps working and shows the new version. Prefer this over publishing again. A second publish_flyer call mints a different URL and leaves the old page live and out of date, which is almost never what the user meant by "update it". Needs the id and owner_token returned when it was published; there are no accounts, so that token is the only proof of ownership. Send the complete replacement document, not a patch or a fragment — the old contents are overwritten and cannot be recovered. The expiry is left alone unless you pass ttl_hours, so editing a page does not quietly extend how long its link stays alive. It is categorised as a Write tool in the Flingflyers MCP Server, which means it can create or modify data. Consider rate limits to prevent runaway writes.
update_flyer accepts 4 parameters: id, html, ttl_hours, owner_token. Required: id, html, owner_token. The full parameter table on this page comes from the server's own tool schema.
Register the Flingflyers MCP server in PolicyLayer and add a rule for update_flyer: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Flingflyers. Nothing to install.
update_flyer is a Write tool with medium risk. Write tools should be rate-limited to prevent accidental bulk modifications.
Yes. Add a rate_limit block to the update_flyer rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for update_flyer. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
update_flyer is provided by the Flingflyers MCP server (https://flingflyers.com/mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
More on Flingflyers, and thousands of servers like it.
This server
Across the catalogue