Flowershow

Publish to Flowershow

publish

Destructive

Publish files as a live website on Flowershow and get a shareable URL. Use when the user says "publish this", "put this online", "make this a website", "share this as a page" or "host this".

Accepts Markdown (.md, rendered as a styled page with navigation), HTML (.html, served as-is) and supporting files such as CSS, JS, JSON and images: one page or a small site, up to 50 files and 3 MB per call. Name the home page index.md or index.html.

Without an account this creates a new site that expires in 7 days and returns a claim link: always show the user the live URL and the claim link exactly as returned, so they can keep the site. To update that site later in the conversation, call publish again with its siteId and claimToken and only the files you changed or added: files you don't send are kept as they are. To remove pages or files, list their paths in delete (files can then be empty). Only when the user explicitly asks to start the site over, set replaceWholeSite to true: the files you send become the whole site and every other file is removed. If that would remove existing files, the call is refused and tells you how many and which; ask the user, then call again with confirmDeleteCount set to that number. For bigger sites, suggest the Flowershow CLI (fl).

Input Schema

Name	Required	Description
`files`	Yes	Files to add or update. When updating a site, send only the files that changed; other files are kept. Can be empty when only deleting.
`delete`	No	Paths of existing files to remove from the site (with siteId), e.g. ["old-page.md"]
`siteId`	No	Update this existing site instead of creating a new one
`claimToken`	No	The claimToken returned when the anonymous site was created (needed with siteId when not signed in)
`replaceWholeSite`	No	Set true only when the user asks to start the site over: the files sent become the whole site and all other files are permanently removed. Never use it to update a few pages. Default false.
`confirmDeleteCount`	No	With replaceWholeSite: the number of existing files the replace will remove, as reported by the refused first call. Set it only after the user has confirmed.

Output Schema

Name	Required	Description	Default
`siteId`	Yes
`liveUrl`	Yes
`message`	Yes
`claimUrl`	No
`expiresAt`	No
`claimToken`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 25, 2026

addedInput schema / properties / confirmDeleteCount

Added value: +{
+  "description": "With replaceWholeSite: the number of existing files the replace will remove, as reported by the refused first call. Set it only after the user has confirmed.",
+  "maximum": 9007199254740991,
+  "minimum": 0,
+  "type": "integer"
+}

addedInput schema / properties / delete

Added value: +{
+  "description": "Paths of existing files to remove from the site (with siteId), e.g. [\"old-page.md\"]",
+  "items": {
+    "type": "string"
+  },
+  "maxItems": 1000,
+  "type": "array"
+}

changedInput schema / properties / files / description

Previous value: -"The complete set of site files"New value: +"Files to add or update. When updating a site, send only the files that changed; other files are kept. Can be empty when only deleting."

addedInput schema / properties / replaceWholeSite

Added value: +{
+  "description": "Set true only when the user asks to start the site over: the files sent become the whole site and all other files are permanently removed. Never use it to update a few pages. Default false.",
+  "type": "boolean"
+}

First observedOct 25, 2026

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds substantial behavior beyond the annotations: anonymous sites expire in 7 days, a claim link must be shown, files not resent are kept, delete paths remove files, replaceWholeSite is destructive, and a refusal/confirmDeleteCount confirmation flow guards against accidental mass deletion. These details are consistent with destructiveHint=true and openWorldHint=true, and they materially improve safe invocation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but front-loaded: the first sentence states the action and the second gives trigger examples. The remaining paragraphs are dense with operational rules that earn their place, with no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex, destructive, open-world publishing tool, the description covers the full lifecycle: creating, sharing, claiming, updating, deleting, replacing, and escalating to the CLI. An output schema exists, so it does not need to explain return values, and nothing important appears absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents each parameter. The description still adds meaningful workflow semantics: how siteId and claimToken work together, that only changed files should be sent on update, that files can be empty when deleting, and how replaceWholeSite and confirmDeleteCount interact. That goes beyond the schema, though the schema already carries the basic per-parameter definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: publish files as a live website on Flowershow and get a shareable URL. It distinguishes creation from updating by siteId and explains the output expectation, so an agent can tell exactly what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit trigger phrases ('publish this', 'put this online', 'host this') and clear conditions for updating an existing site, deleting files, replacing a whole site, and suggesting the CLI for larger sites. The when-to-use and when-not-to-use boundaries are unusually well specified.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Flowershow tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.