Skip to main content
Glama
Sign In

A2UI Atomic Catalog

by ai.a2uicatalog
OverviewDiscussionsAdmin

list_readings

Read-onlyIdempotent

The reader's recent stamped surfaces, newest first — what makes "compare this to my last three teardowns" answerable at all. Optionally filter to one runbook. Returns available:false when nobody is signed in.

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": "list_readings"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoDefault 20, max 100.
runbookNoFilter to one runbook, e.g. "article_playbook".

Output Schema

NameRequiredDescriptionDefault
noteNoGuidance for the caller.
countNoNumber of readings returned.
reasonNoWhy it is unavailable.
readingsNoSaved readings, newest first.
availableYesFalse when there is no signed-in reader or the store failed.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive, open-world, so the safety profile is covered. The description adds genuinely useful behavior not in annotations: ordering (newest first) and the failure mode "available:false when nobody is signed in." It stops short of describing anything about what a "reading" contains or whether results paginate.

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?

Two short sentences, front-loaded with what is returned and in what order, then the auth caveat. The embedded example quote is slightly wordy but functional. No filler or repetition.

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

Completeness4/5

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

A moderate-complexity read tool with only 2 optional params, an output schema (so return shape needn't be explained), and full annotation coverage. Ordering and the unauthenticated failure mode are the key extras and both are present, though the term "reading/stamped surface" remains undefined.

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 already carry descriptions (limit default 20/max 100; runbook filter with an example). The description only restates that runbook filtering is optional, adding no syntax or semantics beyond the schema. Baseline 3 applies.

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?

"The reader's recent stamped surfaces, newest first" names a resource (stamped surfaces) and an ordering, but the domain vocabulary ("stamped surfaces", "readings") is undefined for an outside agent. It's not a clear verb+resource statement — there's no explicit "list readings" framing, so an agent has to infer that this enumerates previously saved readings.

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

Usage Guidelines3/5

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

The parenthetical "what makes 'compare this to my last three teardowns' answerable at all" implies a usage scenario (retrieving recent history for comparison) and "optionally filter to one runbook" gives one concrete usage path. However, no sibling is named and there's no explicit when-not-to-use guidance, e.g. vs. list_catalogs or get_profile.

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 toolsInspect
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.

Resources