A2UI Atomic Catalog

save_reading

Record a stamped surface in the reader's history so it can be compared and reopened later. Call it AFTER emit_runbook_surface, and PASS ITS payload — that stores the reading itself rather than a link to it. Silently no-ops when nobody is signed in.

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": {
      "runbook": "<runbook>"
    },
    "name": "save_reading"
  }
}

Input Schema

Name	Required	Description
`url`	No	The stamped surface url returned by emit_runbook_surface.
`lens`	No	The lens the reading was made through (e.g. "explain"), so history can show it.
`title`	No	The ANALYSIS title (yours), not the source headline.
`payload`	No	The compiled surface emit_runbook_surface returned (its `payload`). PASS IT. Without it the row is a link only, and a link depends on a renderer staying reachable — with it the reading is stored portably and can be re-rendered or exported long after any URL stops working.
`runbook`	Yes	e.g. "article_playbook"
`source_url`	No	The original article, so history stays attributable.
`source_title`	No	The original article's headline, kept beside source_url.

Output Schema

Name	Required	Description
`id`	No	Id of the stored reading.
`note`	No	Guidance for the caller.
`saved`	No	True when the row was stored.
`reason`	No	Why nothing was saved.
`warning`	No	Why the payload was not stored.
`portable`	No	True when the payload was stored with it.
`available`	Yes	False when there is no signed-in reader or the store failed.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Discloses a behavior the annotations do not: it 'silently no-ops when nobody is signed in,' which is critical for an agent to know since a successful-looking call may do nothing. It also explains the storage model (payload stored portably vs. a link that depends on a reachable renderer), adding real context beyond the readOnly/openWorld hints.

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?

Three tight sentences, front-loaded with the action and followed by the ordering constraint and the no-op caveat. Every sentence carries information an agent needs.

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 mutation tool with an output schema and full annotation coverage, the description covers the ordering dependency, the payload requirement, and the silent no-op edge case. Nothing essential to calling it 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 genuine meaning: it stresses passing the payload and explains why (portability, re-render/export after URLs die), and clarifies that 'title' is the analysis title, not the source headline.

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 ('Record a stamped surface in the reader's history') plus the downstream benefit ('compared and reopened later'). It also implicitly separates itself from emit_runbook_surface by positioning this as the follow-up step.

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?

Gives explicit sequencing ('Call it AFTER emit_runbook_surface') and a concrete instruction to pass the payload. It does not name when to skip it or point to alternatives like export_reading or delete_reading, so it falls short of full when/when-not guidance.

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.