Skip to main content
Glama

anew

by page.anew
OverviewDiscussionsAdmin

Server Details

Encode self-contained HTML pages into shareable URLs.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
100.0% over 23 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL
Repository
round/anew.page
GitHub Stars
0

TDQS

A4.8/5.0

Scored across 2 tools

Disambiguation5/5

The two tools are exact inverses: anew_read takes a URL and returns HTML, while anew_write takes HTML and returns a URL. There is no functional overlap, and the description explicitly clarifies the URL-taking variant of anew_read, eliminating any ambiguity.

Naming Consistency5/5

Both tools follow the identical pattern: the server prefix 'anew_' followed by a simple, opposite verb ('read' and 'write'). This creates a highly predictable and consistent naming convention.

Tool Count4/5

At two tools, the server is slightly below the typical 3-15 range, but the extremely narrow purpose—encoding and decoding a bespoke URL-embedded HTML format—makes this minimal footprint appropriate. Each tool is essential and earns its place.

Completeness5/5

The tool set fully covers its domain. Since anew pages are immutable and revisions produce new URLs, there is no need for update or delete operations; the read/write pair provides complete round-trip coverage for embedding and retrieving HTML.

Available Tools

2 tools
anew_readRead a page (anew.page URL → its HTML source)AInspect

Pass an anew.page URL, get back the HTML document encoded in it, plus its canonical URL and byte size. (Two in-page tools share this name and take no arguments: the editor's reads the document open in the editor, and a rendered page's reads the page being viewed. This one takes a url and reads that page.) 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 returns the author's exact bytes — no anew-injected tags, no proxied image srcs — so it re-encodes byte-for-byte. Never re-author from a rendered page, a scraped DOM, or a screenshot: each loses the author's markup, and none is faster than reading the slug. Decoding is local and exact, so any anew URL reads — the page needs no prior visit and no fetch.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesAn anew.page URL, or a bare slug. Subdomain, cosmetic-prefix and #hash forms all resolve.
formatNoHow the document rides back. "text" (default) is one plain text block. "resource" is one embedded-resource block ({type:"resource"}, mimeType text/html) — the typed MCP form for callers that want the page tagged as HTML rather than loose text. Same bytes both ways.text

Output Schema

ParametersJSON Schema
NameRequiredDescription
urlYesCanonical anew.page URL for this document.
bytesYesEncoded URL length in bytes.

TDQS

A4.7/5.0
Behavior5/5

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

Annotations are all false, so the description carries the full burden, and it delivers: it discloses exact-byte return, absence of injected tags or proxied image srcs, local and exact decoding, no fetch or prior visit required, and that the original page keeps working. These are meaningful behavioral traits beyond the schema.

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 front-loaded with the core action and every subsequent sentence adds value: disambiguation, workflow guidance, byte-exactness, anti-pattern warning, and local decoding. Nothing is redundant despite the length.

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 two-parameter tool with a complete schema and output schema, the description covers disambiguation, return semantics, usage prohibitions, and underlying behavior. An agent has everything needed to invoke it correctly.

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 100%, so the baseline is 3. The description adds some context about the URL being an anew.page URL and the output format, but it mostly restates what the schema already documents rather than enriching parameter meaning.

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 opens with a precise statement: pass an anew.page URL, receive the HTML document, canonical URL, and byte size. It also disambiguates from same-named in-page tools and from the sibling anew_write, so an agent can tell exactly what this 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?

The description explicitly gives the read-write workflow (read, edit HTML, write again), warns against re-authoring from rendered pages/scraped DOMs/screenshots, and clarifies that reading the slug is always the correct path. It names exclusions and describes when not to use alternatives.

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

anew_writeWrite a page (HTML → anew.page URL)AInspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
htmlYesSelf-contained HTML markup and inline CSS only; no script elements, inline event handlers, or executable JavaScript. Encoded into the returned URL.
javascriptNoOptional 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

ParametersJSON Schema
NameRequiredDescription
urlYesThe anew.page URL — return verbatim.
bytesYesEncoded URL length in bytes.
warningNoPresent 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_bytesYesThe submitted HTML in UTF-8 bytes.

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.

Tool Schema Changelog

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

  1. 1 tool update
    • Changedanew_write1 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."
  2. 2 tool updates
    • Changedanew_read2 fields changed
      • 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 / required
        Previous value: -[
-  "url",
-  "bytes",
-  "limit"
-]New value: +[
+  "url",
+  "bytes"
+]
    • Changedanew_write4 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"
+]
  3. 1 tool update
    • Changedanew_write2 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"
+}
  4. 1 tool update
    • Changedanew_write2 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"
-}
  5. 2 tool updates
    • First observedanew_read
    • First observedanew_write

Related MCP Connectors

Related MCP Servers

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