Skip to main content
Glama

A2UI Atomic Catalog

make_surface_url

Read-onlyIdempotent

Render an A2UI payload in the CALLER'S OWN environment. Pass renderer_url (your deployed renderer /exec) and get a live URL + the catalogs it declares. Omit renderer_url to get the encoded fragment + BYO guidance. We host nothing and never see your content.

NEVER hand-write your own gzip/base64 encoding for the ?p= URL, in ANY language, even as a "just this once" fallback. This is the single most common cause of "could not decompress gzip" — a self-written encoder with one wrong flag (wrong wbits, standard vs. urlsafe base64, un-stripped padding) produces a broken URL at ANY size, not just large ones. Always call this tool again — never substitute your own implementation.

SIZING IS AUTOMATIC — you do not need to estimate, count characters, or decide whether to split. Call this tool ONCE with your FULL, unsplit payload. If it fits, you get back url (and nothing else to do). If it does not fit the real size ceiling, the tool SPLITS IT FOR YOU server-side (at natural heading boundaries) and returns auto_split: true plus a pages array of independent URLs — present that list to the user (e.g. as numbered links) instead of the single url. Never pre-split your content before the first call; always send everything in one call and let the response tell you what happened.

GRADUATE substantial surfaces with emit_deployment instead (no size limit at all) when you want a standing app rather than a shareable link.

IF A RENDER CHECK REPORTS "could not decompress gzip" / "Render error" / "invalid distance too far back" on a URL this tool returned: STOP. Do NOT call this tool again with the SAME unchanged payload — re-call it with the SAME payload once to confirm, and if it still fails, use emit_deployment instead. Never fall back to a hand-written encoding script.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "payload": "<payload>"
    },
    "name": "make_surface_url"
  }
}

Input Schema

NameRequiredDescriptionDefault
payloadYesThe A2UI payload to encode into a ?p= URL: {title, theme, blocks:[...]}. Send it whole; oversize payloads are split for you.
renderer_urlNoyour renderer /exec (BYO). Omit for fragment + guidance.

Output Schema

NameRequiredDescriptionDefault
urlNoLive renderer URL (present when renderer_url was given; the first page when split).
noteNoGuidance for the caller.
sizeNoPresent when the URL is large: url_length, warning and recommendation.
pagesNoOne entry per page, each with a url.
fragmentNoThe ?p= fragment to append to your own renderer (present when renderer_url was omitted).
clipboardNoOptional ready-made copy commands for the URL (linux, macos, windows) plus a note.
auto_splitNoTrue when the payload was split into pages.
page_countNoNumber of pages when split.
required_catalogsYesCatalog URIs the payload needs (base catalog first).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description layers on non-obvious behavior: nothing is hosted or inspected, sizing is computed server-side, auto_split triggers heading-boundary splitting into a `pages` array, and the recovery path when a render check fails. That is substantive context the 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?

Front-loaded and well-sectioned with the size behavior before the error troubleshooting, and nearly every sentence maps to a distinct failure mode. It is on the long side for a two-parameter tool, and the anti-hand-encoding warning is restated in the final paragraph, costing some tightness.

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, yet the description still explains the branches an agent must act on (url alone vs. auto_split plus pages) and explicitly tells the agent to present `pages` as numbered links. Combined with the sizing and error-recovery guidance, nothing needed to invoke or handle the result correctly is 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 baseline is 3, but the description adds real meaning: renderer_url is your own /exec endpoint and omitting it changes the return shape, and payload must be sent whole rather than pre-chunked. It stops short of explaining the block/theme semantics, deferring to list_catalogs/get_catalog, which is reasonable.

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?

States a specific verb and resource ('Render an A2UI payload') plus the crucial scope qualifier ('in the CALLER'S OWN environment'), and explicitly distinguishes the output modes (live URL via renderer_url vs. encoded fragment). It also names the sibling it is not ('GRADUATE substantial surfaces with emit_deployment instead'), so an agent can route 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?

Explicit when-to-use rules: pass renderer_url to get a live URL, omit it for a BYO fragment, use emit_deployment for standing apps with no size limit. It also rules out the wrong behavior ('Never pre-split your content before the first call') and gives a decision procedure for the render-check failure case.

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.