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 by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
100.0% over 43 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL
Repository
round/anew.page
GitHub Stars
0

TDQS

A3.8/5.0

Scored across 4 tools

Disambiguation3/5

anew_read and anew_write are clearly distinct (decode vs encode), and their relationship is well explained. However, anew_editor and anew_page both open the editor (one fullscreen on a blank page, one beside the chat and able to open a URL), creating real overlap that could cause misselection.

Naming Consistency4/5

All names share the 'anew_' prefix and are lowercase snake-ish, which is predictable. The slight inconsistency is that read/write are verbs while editor/page are nouns, but the set remains readable and coherent.

Tool Count4/5

Four tools is a tight, well-scoped set for a URL-based page publish/read/edit service. It's on the lean side but each tool earns its place; the only redundancy is the two editor-openers.

Completeness4/5

The domain (encode a page into a URL, read it back, open/edit it) is covered end-to-end, and the read-then-write revision loop substitutes for an update operation. No delete/list exists, but these are arguably out of scope for URL-carried, account-less pages.

Available Tools

4 tools
anew_editoranewB
Read-only
Inspect

Open anew from the sidebar: the editor, fullscreen, on a new blank page. Takes no arguments.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.1/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, covering the safety profile, so the bar is lower. The description adds useful UI context (opens fullscreen onto a fresh blank page, no arguments), which explains why idempotentHint=false is plausible for a window-opening action, but it never states whether an existing editor is reused, focused, or replaced.

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?

One sentence, front-loaded with the verb and action, with no filler. The colon-heavy phrasing and undefined 'anew' slightly reduce readability, but structurally it is tight.

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

Completeness3/5

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

For a zero-parameter, no-output-schema tool the explanation of the action is present, but with no output schema the description does not say what the agent observes after calling it (state change, returned handle, focus behavior). It is adequate but leaves that gap.

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?

There are zero parameters and the schema is fully self-describing, so the baseline is 4. The description's 'Takes no arguments' is a small but accurate confirmation that adds a little reinforcement.

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

Purpose3/5

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

It states a verb and resource ('Open ... the editor, fullscreen, on a new blank page'), which is more specific than a bare name restatement, but the object 'anew' is never defined and reads as product branding rather than a resource, leaving ambiguity about what exactly is being opened. It gives modifiers (fullscreen, blank page) that help, but it never contrasts with sibling tools like anew_page or anew_read, so the agent must infer the distinction.

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

Usage Guidelines2/5

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

No when-to-use guidance and no exclusions are provided. With three siblings (anew_page, anew_read, anew_write) offering overlapping 'anew' concepts, the description should have said when to pick the editor over the page/read/write variants, but it supplies nothing.

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

anew_pageanew
Read-only
Inspect

Open a page in the anew editor beside the chat, so the user can edit it by hand: pass an anew.page URL to open that page, or nothing for a new blank page. The editor reports the page it holds back to the chat after every edit. Call it only when the user asks to open the editor or to edit a page themselves; anew_write and anew_read do everything else.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlNoAn anew.page URL or bare slug to open in the editor. Omit it, or leave it empty, for a new blank page.
anew_readRead a page (anew.page URL → its HTML source)A
Read-only
Inspect

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.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=false, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds real beyond-annotation context: decoding is local and exact, no prior visit or fetch needed, returns the author's exact bytes with no anew-injected tags and byte-for-byte re-encoding. It does not fully explain the idempotentHint=false nuance, but the behavioral substance is well above the annotation baseline.

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 the core action and return values, followed by the disambiguation parenthetical and the re-authoring guidance. Dense and mostly every sentence earns its place, though the digression about the two same-named in-page tools is longer than strictly needed.

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?

Given an output schema exists (so return values need not be re-explained) and annotations cover safety, the description supplies exactly the missing pieces: disambiguation from same-named siblings, the round-trip editing workflow, and the exact-bytes/local-decode guarantees. Complete for correct invocation.

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 coverage is 100% and both parameters (url, format) carry detailed schema descriptions covering slug/subdomain/hash forms and the text vs resource distinction with the same-bytes guarantee. The description adds context that URL is the canonical source but adds no parameter syntax beyond the schema, so baseline 3 is correct.

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?

Front-loads a precise verb+resource: 'Pass an anew.page URL, get back the HTML document encoded in it, plus its canonical URL and byte size.' It explicitly resolves the name collision with two sibling in-page tools that share this name, and names the counterpart anew_write for revisions. An agent can distinguish this from anew_editor/anew_page/anew_write without opening schemas.

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?

Gives explicit when-to-use (read, edit, write back for revisions; any anew URL reads with no prior visit) and when-NOT-to (never re-author from a rendered page, scraped DOM, or screenshot). It routes against alternative input sources explicitly rather than leaving it to inference.

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

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.

ParametersJSON 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

ParametersJSON Schema
NameRequiredDescription
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.

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.

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 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. 1 tool update
    • Changedanew_write4 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. 1 tool update
    • Changedanew_page2 fields changed
      • changedInput schema / properties / url / description
        Previous value: -"An anew.page URL or bare slug to open in the editor. Omit it for a new blank page."New value: +"An anew.page URL or bare slug to open in the editor. Omit it, or leave it empty, for a new blank page."
      • removedInput schema / properties / url / minLength
        Removed value: -1
  4. 2 tool updates
    • Addedanew_editor
    • Addedanew_page
  5. 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."
  6. 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"
+]

Related MCP Connectors

Related MCP Servers

  • htmldrop

    vin-spiegel
    A
    license
    A
    quality
    B
    maintenance
    Publish HTML or markdown artifacts (reports, dashboards, demos) as instant shareable links with TTL expiry, social preview cards, and optional password protection. Works with the hosted service or a self-hosted instance.
    1
    15 npm
    13
    MIT

  • HTML Cloud

    viljamilaurila
    A
    license
    A
    quality
    A
    maintenance
    Lets AI assistants share HTML they generate as a private, end-to-end encrypted link, and update the page later at the same link. The page is encrypted locally before upload, the key stays in the link, and no account is needed.
    2
    2
    MIT
Try in Browser
Let your AI agent see the webWeb-to-screenshot MCP for Claude, Cursor and Codex. No cookie banners. Free to start.snap-render.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources