A2UI Atomic Catalog

open_workspace

Read-only

Open the A2UI Workspace — a rendered surface that IS the demo: each tool is introduced by the scenario it answers, then wired to run, then shows what it saved. This tool RENDERS ITSELF: its result carries the view, so call it alone and show the result — do NOT pass it on to render_surface, and do not describe the payload in prose. Call it when the user asks to open the workspace, wants to see what this connector can do, asks what is saved about them, or names one of its tools directly — e.g. "open the Wall Builder" means THIS tool with view: "wall_builder", not a separate tool named wall_builder. It shows a display name they chose, never their email.

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

Input Schema

Name	Required	Description	Default
`view`	No	Which screen to open — omit or "home" for the tool selector. The workspace UI navigates between these by calling this tool again with a different view (its own back button); you would normally only pass this yourself to jump straight to one, e.g. "open my profile" -> profile, "open the wall builder" -> wall_builder (a native-catalogue rebuild of the Gemini Enterprise wall-builder demo).
`prompt`	No	Composer view only. Pre-fills the custom-prompt box with this text instead of the default example — used by a reopened generation's "Need to tweak?" action to carry its original prompt back into an editable view. Omit for a fresh Composer visit.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations only cover the safety profile (readOnly, not destructive, open world); the description adds behavior annotations cannot express — the tool self-renders, its result already carries the view, it must be called alone, and the UI re-invokes it internally for navigation. The privacy note that it shows a chosen display name and never the email is a further behavioral trait not derivable from structured fields.

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?

Core instruction is front-loaded and the critical constraint (do not pass to render_surface) appears in the first two sentences. It is dense rather than padded, though the clause about each tool being 'introduced by the scenario it answers, then wired to run, then shows what it saved' is descriptive filler that does not change how an agent calls it.

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?

Two optional parameters with full schema coverage and no output schema, yet the description still explains what the result carries (the rendered view), which is the one thing an agent could not infer. Nothing essential about invocation or response handling is left out; only minor framing detail is missing.

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 the enum plus per-parameter descriptions already explain 'view' and 'prompt', so the baseline is 3. The description adds only marginal value here — the natural-language-to-value mapping for wall_builder and the profile hint largely duplicate examples already present in the schema text.

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?

Names a specific verb and resource ('Open the A2UI Workspace') and immediately distinguishes it from the closest sibling by warning not to pass the result to render_surface. It also pre-empts the most likely naming confusion by stating that 'open the Wall Builder' is this tool with view: "wall_builder", not a separate tool.

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 list: user asks to open the workspace, wants to see what the connector can do, asks what is saved about them, or names one of its tools directly. It also states the negative case (do not forward to render_surface, do not narrate the payload in prose), which is exactly the kind of when-not guidance that prevents misuse.

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.