A2UI Atomic Catalog

get_atom_schema

Read-onlyIdempotent

Return the PROP SHAPE (field names + what each field takes) for named atoms. get_catalog tells you an atom EXISTS; this tells you how to fill it. Call this before authoring any atom you have not used before — guessing prop names is the single most common cause of an atom rendering empty or wrong. Accepts several types at once, so a multi-atom surface resolves in one call.

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": {
      "types": "<types>"
    },
    "name": "get_atom_schema"
  }
}

Input Schema

Name	Required	Description	Default
`types`	Yes	Atom type names, e.g. ["weather_now","chartjs_bar"] (max 25)

Output Schema

Name	Required	Description
`hint`	No	What to do about the unknown names.
`atoms`	Yes	Prop shapes keyed by atom type; each value has fields, description and surfaces.
`unknown`	No	Requested names that are not real atoms.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already establish readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds real context beyond that: the failure mode if skipped (atoms rendering empty or wrong) and the batching trait that several types resolve in one call. It does not mention the 25-type cap, but that lives in the schema.

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 with the return shape, then differentiation, then usage guidance, then batching — a sensible order with no filler sentences. Slightly conversational in tone but each sentence carries a distinct piece of information.

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 one-parameter read-only lookup with an output schema and full schema coverage, the description supplies everything else an agent needs: what comes back at a high level, when to call it, what goes wrong if it is skipped, and that calls can be batched.

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 baseline is 3, and the description earns a bump by explaining that the single array parameter is meant to be filled with several atom types at once so a multi-atom surface resolves in one call. That batching intent is not evident from the schema alone.

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 ('Return the PROP SHAPE (field names + what each field takes) for named atoms') and explicitly contrasts itself with get_catalog ('tells you an atom EXISTS; this tells you how to fill it'). An agent can distinguish it from its sibling without inspecting either 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?

Gives an explicit trigger ('Call this before authoring any atom you have not used before') and names the alternative tool with the condition that separates them. It also quantifies the cost of skipping it, which is stronger guidance than a generic 'use when needed'.

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.