Foliyo

Publish HTML as a Foliyo link

publish_html

Destructive

Create or update a Foliyo link from finished static HTML. Returns the URL, generated PIN and requested personal recipient links. New shares default to a generated PIN; updates preserve omitted settings and require the current revision. An unverified email gate records claimed addresses; verified email access requires Pro. Notification email is opt-in.

Input Schema

TableJSON Schema

Name	Required	Description
`to`	No	Named recipients. Each gets their own link so opens are attributable.
`gate`	No	Use "pin" for a generated code, "email" to collect addresses (Pro; verify:true proves mailbox access), "domain:acme.com" to restrict email domain, or "none" to explicitly open a page and remove its PIN. Omit on updates to preserve the current policy.
`html`	Yes	The full HTML document to publish. WRITE IT FOR A PHONE FIRST: most of these links are opened on one. A viewport meta tag, max-width rather than fixed pixel widths, images at max-width:100%, a single column below ~640px, and nothing that needs sideways scrolling. The server adds a viewport tag when you leave it out, but it cannot reflow a 900px-wide layout.
`note`	No	One plain line saying what changed, e.g. "Added the Q3 numbers". Shown to readers on the project hub under 'what changed since you were last here', and used in the update email. Write it every time you republish something inside a project: it is what saves the user from explaining the change to their team by hand.
`slug`	No	Preferred URL slug. One taken for you if omitted.
`reply`	No	Put a one-line reply box at the foot of the page so readers can answer without leaving it. true for the default label, or your own short prompt.
`title`	No	Title shown on the page and in link previews.
`track`	No	Enable viewing analytics; plan limits still apply.
`assets`	No
`format`	No	Presentation format; fixed slides use data-foliyo-slide on every slide.
`notify`	No	Email everyone already holding this link to say it has been updated. Off by default, because republishing while you iterate must not mail anybody. Pass true only when the user says to tell them.
`sender`	No	Who it is from: a saved identity's label, e.g. "Ashford Advertising". brand_guide lists the saved identities. Unknown labels are refused.
`verify`	No	Email a code to prove the viewer owns the address.
`expires`	No	When it stops working: "14d", "48h", or an ISO date.
`project`	No	Which saved project this belongs to, e.g. "acme". Settles the letterhead, the design guide and the recipients in one, so none of them need asking again. Anything you pass explicitly still wins. If the user works on several streams of work and has projects saved, pick the matching one rather than re-asking the same three questions.
`audience`	No	A saved group to send to, e.g. "acme-team". Expands into named recipients exactly as if you had typed them, and stacks with `to` for one-offs. brand_guide lists them.
`maxViews`	No	Stop working after this many views.
`password`	No	A code of the user's own for the PIN gate. LEAVE IT OUT unless the user named one: with gate:"pin" and no `password`, the server mints six digits and returns them as `sharePassword`, which is the code to repeat back. Never invent one yourself - an invented code is a different shape every time, and the lock screen asks the recipient for six digits. A code the user does name is kept as given (minimum 4 characters). Everyone shares the one code, so every reader stays anonymous in the report: add `to` for personal links, or use gate:"email" when the user wants names.
`description`	No
`acceptStatic`	No	Acknowledge removal of scripted functionality. Prefer converting to static HTML before publishing.
`expectedRevision`	No	Required for updates. Use the revision returned by get_page, never guess.
`allowContentRemoval`	No	Only true after the user intentionally removes content reported by preflight or an update warning.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedSep 27, 2026

addedInput schema / properties / allowContentRemoval

Added value: +{
+  "description": "Only true after the user intentionally removes content reported by preflight or an update warning.",
+  "type": "boolean"
+}

addedInput schema / properties / expectedRevision

Added value: +{
+  "description": "Required for updates. Use the revision returned by get_page, never guess.",
+  "exclusiveMinimum": 0,
+  "type": "integer"
+}

addedInput schema / properties / format

Added value: +{
+  "description": "Presentation format; fixed slides use data-foliyo-slide on every slide.",
+  "enum": [
+    "web",
+    "slides-16-9",
+    "slides-flexible",
+    "interactive-static"
+  ],
+  "type": "string"
+}

First observedSep 14, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, openWorldHint=true, so the safety profile is covered. The description still adds real behavior: return values (URL, PIN, recipient links), that new shares mint a PIN, that updates preserve omitted settings and need the current revision, that verified email access requires Pro, and that notification email is opt-in. It never states what is destroyed on update, which keeps it short of a 5.

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

Conciseness4/5

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

Four front-loaded sentences, led by the core action, with each remaining sentence carrying distinct information (return values, create/update semantics, gate/Pro constraint, notification default). It is dense but not padded; the third sentence is somewhat crammed but still earns its place.

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

Completeness4/5

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

For a 22-parameter tool with no output schema, the description does supply the return shape (URL, PIN, recipient links) and the create-vs-update contract. It omits the surrounding workflow (validation via preflight_html, fetching the revision via get_page, identity/audience lookup via brand_guide), which are relevant for correct invocation of a tool this complex.

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

Parameters3/5

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

Schema description coverage is 91%, so the schema already documents nearly every parameter, including nuanced guidance on password, notify, project, and sender. The description only alludes to a few (generated PIN, personal recipient links, revision) without adding syntax or formats beyond the schema, so the baseline 3 applies.

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

Purpose4/5

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

States a specific verb pair and resource: 'Create or update a Foliyo link from finished static HTML.' An agent immediately knows this is the write tool for publishing HTML. It does not name or contrast any sibling (e.g., preflight_html, prepare_foliyo, get_page), so differentiation is left to the tool list rather than the text.

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

Usage Guidelines3/5

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

Implied usage is present: 'New shares default to a generated PIN; updates preserve omitted settings and require the current revision' tells the agent the create-vs-update distinction, and the Pro note scopes the verified email path. However, no alternatives are named (preflight_html for validation, get_page for the revision needed on updates, brand_guide for senders/audiences), so routing guidance is incomplete.

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

All Foliyo tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?