Skip to main content
Glama

Foliyo

by io.foliyo
OverviewDiscussionsAdmin

Publish HTML as a Foliyo link

publish_html
Destructive

Create or update a Foliyo link from finished HTML: static by default, or interactive:true to keep its scripts in a sandboxed frame. For NEW work, first resolve all six choices through prepare_foliyo and obtain approval of the complete summary (readyToBuild=true); a format choice alone does not authorize publishing or defaulting other choices. Returns the URL, generated PIN and requested personal recipient links. The API's fallback PIN is not permission to skip the access question. Updates preserve omitted settings and require the current revision from get_page. An unverified email gate records claimed addresses; verified email access requires Pro. Notification email is opt-in.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoNamed recipients. Each gets their own link so opens are attributable.
gateNoUse "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.
htmlYesThe 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.
noteNoOne 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.
slugNoPreferred URL slug. One taken for you if omitted.
replyNoPut 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.
titleNoTitle shown on the page and in link previews.
trackNoEnable viewing analytics; plan limits still apply.
assetsNo
formatNoPresentation format; fixed slides use data-foliyo-slide on every slide.
notifyNoEmail 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.
senderNoWho it is from: a saved identity's label, e.g. "Ashford Advertising". brand_guide lists the saved identities. Unknown labels are refused.
verifyNoEmail a code to prove the viewer owns the address.
expiresNoWhen it stops working: "14d", "48h", or an ISO date.
projectNoWhich 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.
audienceNoA 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.
maxViewsNoStop working after this many views.
notesOffNoPro only. Section names (heading text or data-section) to switch reader notes off for. Sections are on by default. Omit to leave the current setting; [] switches all back on. When two headings share a name, 'name#index' (index = the section's 0-based position among the page's h1/h2/h3/data-section elements, e.g. 'Summary#4') switches off only that one; the plain name switches off every section with that name. Authors can also mark a heading with data-notes="off".
passwordNoA 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.
descriptionNo
interactiveNoKeep the page's scripts. The document runs in a sandboxed frame like a Claude artifact: inline scripts and scripts from cdnjs.cloudflare.com, cdn.jsdelivr.net, unpkg.com, cdn.tailwindcss.com and code.jquery.com; stylesheets from fonts.googleapis.com and those hosts; no fetch or network, no storage or cookies, no dialogs, no embedded documents. Omit on updates to keep the page's current setting. Off by default: a static page is lighter and prints completely.
acceptStaticNoAcknowledge removal of scripted functionality from a STATIC page. Prefer interactive:true when the scripts matter, or convert to static HTML first.
expectedRevisionNoRequired for updates. Use the revision returned by get_page, never guess.
allowContentRemovalNoOnly true after the user intentionally removes content reported by preflight or an update warning.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / acceptStatic / description
      Previous value: -"Acknowledge removal of scripted functionality. Prefer converting to static HTML before publishing."New value: +"Acknowledge removal of scripted functionality from a STATIC page. Prefer interactive:true when the scripts matter, or convert to static HTML first."
    • addedInput schema / properties / interactive
      Added value: +{
+  "description": "Keep the page's scripts. The document runs in a sandboxed frame like a Claude artifact: inline scripts and scripts from cdnjs.cloudflare.com, cdn.jsdelivr.net, unpkg.com, cdn.tailwindcss.com and code.jquery.com; stylesheets from fonts.googleapis.com and those hosts; no fetch or network, no storage or cookies, no dialogs, no embedded documents. Omit on updates to keep the page's current setting. Off by default: a static page is lighter and prints completely.",
+  "type": "boolean"
+}
    • addedInput schema / properties / notesOff
      Added value: +{
+  "description": "Pro only. Section names (heading text or data-section) to switch reader notes off for. Sections are on by default. Omit to leave the current setting; [] switches all back on. When two headings share a name, 'name#index' (index = the section's 0-based position among the page's h1/h2/h3/data-section elements, e.g. 'Summary#4') switches off only that one; the plain name switches off every section with that name. Authors can also mark a heading with data-notes=\"off\".",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
  2. Changed3 schema fields changed
    • 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"
+}
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare write/destructive/open-world/non-idempotent, and the description adds substantial context beyond that: omitted settings are preserved on update, the server mints a six-digit PIN returned as sharePassword, an unverified email gate only records claimed addresses while verified access needs Pro, notification email is opt-in, and approved summaries are a precondition. This is exactly the kind of behavioral detail annotations cannot carry.

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?

Front-loaded with what the tool does, then the create/update rules, then return values and edge cases. For 24 parameters and a multi-step approval workflow it stays compact, though several sentences are dense enough to require a second read.

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?

No output schema exists, and the description compensates by naming the return values (URL, generated PIN, personal recipient links). It covers the new-vs-update precondition, revision requirement, access gates, plan gating, and notification default, which is complete for a 24-param publishing tool.

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 92%, so the per-parameter burden is already met (baseline 3). The description adds cross-parameter semantics the schema cannot state alone: that a format choice does not authorize defaulting the other choices, that gate/notify/password defaults have deliberate consequences, and that omissions on updates preserve current settings.

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?

Opens with a specific verb+resource ('Create or update a Foliyo link from finished HTML') and immediately distinguishes the two modes (create vs update). It also names the sibling that gates new work (prepare_foliyo), so an agent can place this tool among its siblings without opening a schema.

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?

Explicitly separates NEW work (route through prepare_foliyo, obtain a full summary with readyToBuild=true, a format choice alone does not authorize publishing) from UPDATE work (preserve omitted settings, require the current revision from get_page). It also states when-not to notify and when the fallback PIN must not be used, giving real routing guidance rather than implied usage.

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

All Foliyo toolsInspect
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