Skip to main content
Glama

Write a page (HTML → anew.page URL)

anew_write

Publish a web page: encode one self-contained HTML document (or fragment, or plain text) into an anew.page URL and return that URL. Use it when the user asks for a page, a site or a link they can open and share. The page is carried in the URL itself — no account, and no copy of the page is kept — so anyone who has the URL can open it; each call also starts a screenshot of the page, cached publicly for link previews. Put markup and inline CSS in html and any JavaScript in javascript as plain source; the server inserts it before . Inline the page's CSS, scripts and images so it renders on its own; a webfont may load from a CDN. Each encoding path is deterministic: the same input through the same path always produces the same URL. Different paths use different Brotli encoders, though, so the same HTML may mint different — equally valid — URLs; compare pages by their decoded HTML, never by slug. Limits: a page whose URL would pass 4000 bytes, or whose HTML passes 1048576 bytes decoded, is refused with an error that states the size and the overage; apps cut longer links short when they are shared. To revise an existing anew page, its URL is its source: read it, edit that HTML, write it again. The new URL is a separate page and the original keeps working. Read it with anew_read first, then call this with the edited HTML.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
htmlYesThe page: HTML markup with inline CSS — a full document, a fragment, or plain text. Its JavaScript goes in javascript. Encoded into the returned URL.
javascriptNoOptional client-side JavaScript for the page, as plain source without script tags. The server inserts it immediately before </body> (or at the end when there is no body).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesThe anew.page URL of the page.
bytesYesEncoded URL length in bytes.
warningNoNot returned: a page past a size limit is refused with an error instead.
decoded_bytesYesThe submitted HTML in UTF-8 bytes.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / properties / warning / description
      Previous value: -"Present when the URL is over 4000 bytes: the page works, and some apps cut a link that long short when it is shared."New value: +"Not returned: a page past a size limit is refused with an error instead."
  2. Changed4 schema fields changed
    • changedInput schema / properties / html / description
      Previous value: -"Self-contained HTML markup and inline CSS only; no script elements, inline event handlers, or executable JavaScript. Encoded into the returned URL."New value: +"The page: HTML markup with inline CSS — a full document, a fragment, or plain text. Its JavaScript goes in javascript. Encoded into the returned URL."
    • changedInput schema / properties / javascript / description
      Previous value: -"Optional raw client-side JavaScript. Populate for any interactive behavior. Source only — no script tags. The server inserts it immediately before </body> (or at the end when there is no body)."New value: +"Optional client-side JavaScript for the page, as plain source without script tags. The server inserts it immediately before </body> (or at the end when there is no body)."
    • changedOutput schema / properties / url / description
      Previous value: -"The anew.page URL — return verbatim."New value: +"The anew.page URL of the page."
    • changedOutput schema / properties / warning / description
      Previous value: -"Present when the page minted past a warning line (URL past 4000 bytes — a chosen margin, past which some apps may truncate or refuse the link): the URL works and serves. Deliver the URL as minted and tell the person; whether to shorten it is their decision. Never remove content, sections or features to clear a warning without asking."New value: +"Present when the URL is over 4000 bytes: the page works, and some apps cut a link that long short when it is shared."
  3. Changed1 schema field changed
    • changedOutput schema / properties / warning / description
      Previous value: -"Present when the page minted past a warning line (URL past 4000 bytes — a chosen margin, past which some apps may truncate or refuse the link — or content near the decode ceiling): the URL works and serves. Deliver the URL as minted and tell the person; whether to shorten it is their decision. Never remove content, sections or features to clear a warning without asking."New value: +"Present when the page minted past a warning line (URL past 4000 bytes — a chosen margin, past which some apps may truncate or refuse the link): the URL works and serves. Deliver the URL as minted and tell the person; whether to shorten it is their decision. Never remove content, sections or features to clear a warning without asking."
  4. Changed4 schema fields changed
    • removedOutput schema / properties / decoded_limit
      Removed value: -{
      -  "description": "Recommended decoded-byte budget (160000).",
      -  "type": "integer"
      -}
    • removedOutput schema / properties / limit
      Removed value: -{
      -  "description": "Unfurl-safe URL threshold (4000); headroom = limit - bytes. Past it the URL still works (hard ceiling 65000), it may just break in some apps.",
      -  "type": "integer"
      -}
    • changedOutput schema / properties / warning / description
      Previous value: -"Present when the page minted past a share-safe budget (URL over the share-safe budget, or content over the recommended byte budget): the URL works and serves, with the stated caveat. Relay it to the user with the URL."New value: +"Present when the page minted past a warning line (URL past 4000 bytes — a chosen margin, past which some apps may truncate or refuse the link — or content near the decode ceiling): the URL works and serves. Deliver the URL as minted and tell the person; whether to shorten it is their decision. Never remove content, sections or features to clear a warning without asking."
    • changedOutput schema / required
      Previous value: -[
      -  "url",
      -  "bytes",
      -  "limit",
      -  "decoded_bytes",
      -  "decoded_limit"
      -]New value: +[
      +  "url",
      +  "bytes",
      +  "decoded_bytes"
      +]
  5. Changed2 schema fields changed
    • changedInput schema / properties / html / description
      Previous value: -"A self-contained HTML document, fragment, or plain text. Encoded into the returned URL."New value: +"Self-contained HTML markup and inline CSS only; no script elements, inline event handlers, or executable JavaScript. Encoded into the returned URL."
    • addedInput schema / properties / javascript
      Added value: +{
      +  "description": "Optional raw client-side JavaScript. Populate for any interactive behavior. Source only — no script tags. The server inserts it immediately before </body> (or at the end when there is no body).",
      +  "minLength": 1,
      +  "type": "string"
      +}
  6. Changed2 schema fields changed
    • changedInput schema / properties / html / description
      Previous value: -"Self-contained HTML markup and inline CSS only; no script elements, inline event handlers, or executable JavaScript. Encoded into the returned URL."New value: +"A self-contained HTML document, fragment, or plain text. Encoded into the returned URL."
    • removedInput schema / properties / javascript
      Removed value: -{
      -  "description": "Optional raw client-side JavaScript. Populate for any interactive behavior. Source only — no script tags. The server inserts it immediately before </body> (or at the end when there is no body).",
      -  "minLength": 1,
      -  "type": "string"
      -}
  7. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing statelessness (no account, no stored copy, URL is the payload), public screenshot caching for link previews, deterministic-but-not-identical URL minting across encoder paths with an explicit 'compare by decoded HTML, never by slug' caveat, concrete size limits (4000-byte URL, 1048576-byte HTML) with the error behavior on overflow, and how revision creates a separate page. This is exactly the behavioral context annotations cannot convey.

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?

The purpose is front-loaded in sentence one and each subsequent sentence carries distinct operational information (payload model, encoding determinism, limits, revision loop). It is long and dense, but the length is largely justified by genuinely non-obvious constraints.

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?

An output schema exists, so return values need no elaboration. The description covers the payload model, determinism caveats, limits and error semantics, screenshot side effect, and the revision workflow, leaving nothing an agent needs in order to call it correctly.

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 coverage is already 100%, so the schema baseline is 3, but the description adds real meaning: that html holds markup plus inline CSS (document, fragment, or plain text), that javascript is plain source without script tags, and that the server injects it before </body>. It also instructs inlining CSS/scripts/images for self-containment.

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 first sentence states a specific verb and resource ('Publish a web page'), names the concrete artifact produced (an anew.page URL), and explains the mechanism (encoding HTML into the URL). It is clearly distinguishable from anew_read, which it explicitly positions as the revision counterpart.

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 states exactly when to use it ('when the user asks for a page, a site or a link they can open and share') and gives the alternative workflow for revision: read the existing URL with anew_read, edit, then call this again. Sibling routing and trigger conditions are explicit rather than inferred.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.