A2UI Atomic Catalog

read_article

Have the catalog's own model (Gemini) read an article through the article_playbook runbook and KEEP the reading in the signed-in reader's history, in one call. For a client with no model of its own (the Android analyser app), or when the reader asks for a Gemini reading. If you can read the article yourself, prefer emit_runbook_surface + save_reading. Pass text when you already have the article (it is then the only source the reading may quote), else url and it is fetched server-side. Takes 20-60 s. Needs a signed-in reader; capped per reader per day.

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": {
      "url": "<url>"
    },
    "name": "read_article"
  }
}

Input Schema

Name	Required	Description
`url`	Yes	The article's public URL. Required: it is the attribution link.
`lens`	No	Default explain.
`text`	No	The article text, if the caller already fetched it. Truncated to 60000 chars.
`domains`	No	For lens "apply": the reader's domains, comma-separated.
`concerns`	No	What the reader wants the reading to look for or push back on.
`source_title`	No	The article's headline, kept with the reading for attribution.

Output Schema

Name	Required	Description
`ok`	Yes	True when the reading was produced.
`url`	No	Renderer URL for the reading.
`note`	No	Set when the article text was truncated.
`payload`	No	The stamped article_playbook surface.
`retrieval`	No	How the text was obtained.
`reading_id`	No	Id of the saved reading.
`analysed_by`	No	Model that read the article.
`reads_today`	No	Reads used today by this reader.
`save_warning`	No	Why the reading was not saved.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

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: discloses a 20-60 s latency, a signed-in-reader auth requirement, per-reader daily rate caps, and — crucially — that the reading is written into the reader's history, which explains the readOnlyHint=false / idempotentHint=false profile. It also warns that when `text` is supplied it becomes the only quotable source. No part of this contradicts the declared annotations.

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?

Dense and front-loaded — purpose first, then fallback routing, then source selection, then operational constraints. Every clause carries information, though the interleaving of guidance and parameter behavior makes it slightly harder to scan than a strictly sectioned description.

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 slow, model-backed, writing tool this covers exactly the unknowns an agent needs: duration, auth, quota, persistence side effect, and source precedence. An output schema exists, so return-value shape is correctly left out.

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 semantics the schema does not: the precedence rule between `text` and `url` and the fact that `url` is fetched server-side. Remaining parameters (lens, domains, concerns, source_title) are left entirely to the schema, so this falls short of a 5.

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 (have Gemini read an article via the article_playbook runbook) plus the distinguishing outcome (the reading is persisted to the reader's history in one call). It is clearly separable from emit_runbook_surface and save_reading, which are named explicitly as the do-it-yourself path.

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 both the when-to-use condition (client with no model of its own, or the reader explicitly asks for a Gemini reading) and an explicit when-not-to-use alternative ("If you can read the article yourself, prefer emit_runbook_surface + save_reading"). Nothing about selection is left to inference.

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.