anew

Write a page (HTML → anew.page URL)

anew_write

Put markup and inline CSS in html. For calculations, inputs, buttons, or other interactivity, put raw JavaScript in javascript. Never put tags or inline event handlers in html, and never wrap javascript in tags; the server inserts it before . Encode a self-contained HTML document (or fragment, or plain text) into an anew.page URL and return that URL. 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. Inline all CSS, JS, and images (data: URIs, inline SVG, CSS gradients, or emoji) — the page should render alone forever, and each external reference gambles it on someone else's host staying up. One accepted exception: a webfont is far too large to inline, so a font may load from a durable CDN with a system-stack fallback; do not fight a user who asks for one. There is no size limit below the physical ceilings — 65000 URL bytes (the edge severs the request line past it) and 1048576 decoded bytes (the server's decode cap) — and past either the endpoint refuses with an actionable error (code url_over_budget or content_too_large). Below them there is one strong warning: a URL over 4000 bytes still mints, renders and serves, and the response says the link may break when shared. 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. Brotli slugs (the endpoint, or a local brotli mint) put a short page in a few hundred URL bytes; raw base64 crosses the warning line at ~2900 HTML bytes — know which encoder you are drafting to before judging a page too big. Returns the URL as plain text — return it to the user verbatim. 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

Name	Required	Description	Default
`html`	Yes	Self-contained HTML markup and inline CSS only; no script elements, inline event handlers, or executable JavaScript. Encoded into the returned URL.
`javascript`	No	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).

Output Schema

TableJSON Schema

Name	Required	Description
`url`	Yes	The anew.page URL — return verbatim.
`bytes`	Yes	Encoded URL length in bytes.
`warning`	No	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.
`decoded_bytes`	Yes	The submitted HTML in UTF-8 bytes.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 16, 2026

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

Changed4 schema fields changedSep 14, 2026

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"
+]

Changed2 schema fields changedSep 3, 2026

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"
+}

Changed2 schema fields changedSep 1, 2026

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"
-}

First observedSep 1, 2026

TDQS

A4.8/5.0

Behavior5/5

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

The description discloses substantial behavior beyond the annotations: deterministic encoding, different encoders producing different valid URLs, the size ceilings with error codes, the warning threshold, server insertion before </body>, and the instruction to return URLs verbatim. Annotations only indicate a write operation, so this rich context is genuinely additive.

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 description is long, but nearly every sentence carries operational guidance an agent needs to invoke the tool correctly. It is dense rather than padded, though it could benefit from bullet separation given the number of constraints and edge cases. It earns its length, but is not optimally scannable.

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 tool with nontrivial size limits, encoding behavior, and interactivity constraints, the description covers everything needed to call it correctly: input formatting, return format, failure codes, warning behavior, revision workflow, and the single accepted external-resource exception. No critical context appears missing.

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 100%, so the schema already explains html and javascript. The description adds meaning by reinforcing what must not go in html (no script tags, no event handlers), what javascript should contain (raw source only), and how the server injects it. This goes beyond a plain restatement of the schema.

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 title and description state a specific verb and resource: encode HTML (and optional JavaScript) into an anew.page URL and return it. It clearly distinguishes itself from the sibling anew_read by explaining that revising a page means reading it, editing the HTML, and writing it again.

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?

The description gives explicit when-to-use guidance: use anew_read to read an existing page, edit the HTML, then call anew_write. It also specifies what belongs in html vs. javascript, forbids script tags and inline handlers, permits webfonts as an exception, and explains when shortening the URL is the user's decision.

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

All anew 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.