Skip to main content
Glama

Flowershow

by app.flowershow
OverviewDiscussionsAdmin

Server Details

Publish Markdown and HTML from your AI session as a live website. No account needed.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL
Repository
flowershow/flowershow
GitHub Stars
1,108

TDQS

A4.8/5.0

Scored across 1 tool

Disambiguation5/5

There is only one tool, so there is no possibility of confusing it with another. Its purpose (publishing files as a live site) is stated unambiguously.

Naming Consistency5/5

A single, clear action verb 'publish' that directly matches the domain. No mixed conventions exist because there is only one name.

Tool Count4/5

One tool is thin in absolute terms, but it is a rich, well-scoped operation that absorbs create, update, and delete-adjacent behaviors via parameters. It fits a narrowly focused publishing service rather than feeling like an extreme mismatch.

Completeness4/5

Lifecycle coverage is strong: create, incremental update, deletion of files, and whole-site replacement are all handled, plus error/confirmation flows. Minor gaps remain—no read/list/status tool to inspect current site contents or expiry without republishing.

Available Tools

1 tool
publishPublish to FlowershowA
Destructive
Inspect

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).

NameRequiredDescriptionDefault
filesYesFiles to add or update. When updating a site, send only the files that changed; other files are kept. Can be empty when only deleting.
deleteNoPaths of existing files to remove from the site (with siteId), e.g. ["old-page.md"]
siteIdNoUpdate this existing site instead of creating a new one
claimTokenNoThe claimToken returned when the anonymous site was created (needed with siteId when not signed in)
replaceWholeSiteNoSet 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.
confirmDeleteCountNoWith 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

NameRequiredDescription
siteIdYes
liveUrlYes
messageYes
claimUrlNo
expiresAtNo
claimTokenNo

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool update
    • Changedpublish4 fields changed
      • 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"
+}
  2. 1 tool update
    • First observedpublish

Related MCP Connectors

Related MCP Servers

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.

Resources