A2UI Atomic Catalog

export_reading

Read-onlyIdempotent

Export a kept reading as something that outlives this connector. format "html" returns ONE self-contained file — styles inlined, no network, opens in any browser years from now with nothing installed. "url" rebuilds a link against any renderer (yours by preference). "surface" returns the payload for repainting in place. "json" returns the decoded payload. Needs a reading saved WITH its payload; older link-only rows cannot be re-rendered and will say so.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "export_reading"
  }
}

Input Schema

Name	Required	Description
`id`	No	Reading id from list_readings. OMIT for the most recent one.
`format`	No	Default html. "surface" returns the payload itself, for repainting in place.
`renderer_url`	No	For format "url": your own renderer /exec.

Output Schema

Name	Required	Description
`url`	No	Rebuilt renderer URL (format url).
`html`	No	Self-contained HTML (format html).
`note`	No	Guidance for the caller.
`bytes`	No	Size of the HTML.
`title`	No	Reading title.
`format`	No	"html", "url", "json" or "surface".
`reason`	No	Why it is unavailable.
`payload`	No	The stored payload (format json).
`exported`	No	True when an export was produced.
`available`	Yes	False when there is no signed-in reader or the store failed.
`fonts_delocalised`	No	Remote font faces removed.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds real value beyond them: the html output is guaranteed self-contained with inlined styles and no network dependency, and a failure mode is disclosed — older link-only rows cannot be re-rendered and will report that. Return shape is not discussed, but an output schema exists to cover it.

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 action is front-loaded, then formats are handled one clause each, then the payload precondition closes it out — a logical order with little waste. The opening metaphor ("something that outlives this connector") is slightly ornamental, and the quoted format tokens make the middle dense, but nothing is redundant.

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?

With annotations, a full output schema, and 100% schema description coverage, the remaining burden is explaining format choice and prerequisites — both are covered. The failure case for payload-less readings is disclosed, which is exactly the kind of trap an agent would otherwise hit at call time.

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. The description goes beyond the schema by explaining what each format is for — notably that "surface" yields a payload intended for repainting in place and that "url" rebuilds against the caller's own renderer by preference — which adds intent, not just syntax. The id-omission behavior is left entirely to the schema.

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

Purpose4/5

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

The description states a specific verb and resource ("Export a kept reading") and then enumerates the four output formats with a distinct characterization of each. An agent can tell exactly what the tool produces. It stops short of naming siblings such as render_reading_to_slack or make_surface_url, so the differentiation from those tools is only implicit.

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

Usage Guidelines4/5

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

Each format carries its own use case: html for durable offline artifacts, url for rebuilding a link against a chosen renderer, surface for repainting in place, json for the decoded payload. The precondition "Needs a reading saved WITH its payload" plus the note that link-only rows will fail is clear context. No explicit exclusions or named alternative tools are given, which keeps it out of the top band.

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

All A2UI Atomic Catalog 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.