Provider hosted
No sign in
Tools: 28
MCP App

a2uicatalog

A2UI Atomic Catalog

A2UI Catalog: 500 typed, declarative UI components for AI agents — MCP-ready, no HTML generated by the model. Renders natively on web, Google Meet, Apps Script, Chat, and MCP Apps.

https://a2uicatalog.ai/

Use in your AI tool

Use the tools from this page

Opens ChatGPT on the web or desktop and asks it to use the WebMCP tools available here.

Connect the MCP server

Connect straight to this server’s public endpoint.

Remote MCP URL
https://a2uicatalog.ai/mcp

Use on MCPBundles

We add this server to your workspace, then open Studio — saved access, one connection to many servers, with a history of what ran.

Last probed Sep 14, 2026 · a2uicatalog.ai

28tools discovered

Tools discovered (28)

Showing 25 of 28 from the live probe.

  • List Catalogs

    List every A2UI catalog with a when-to-use, so you can pick the extension catalogs a surface needs. The base catalog (a2ui-atoms-v1) is always resolved.

  • Get Catalog

    Return one catalog's atoms (type + one-line description) so you know its vocabulary.

  • Get Atom Schema

    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.

  • Required Catalogs

    Given an A2UI payload, return the resolvable catalog URIs it needs (deterministic — pure function of the atoms).

  • Build Multi Page Surface

    Build a multi-section A2UI app from raw title+content sections — you never estimate size or decide how to split; each section becomes its own independently-encoded page (no shared hub, so per-page size never grows with page count — genuinely unlimited sections). Returns the first page's `url` plus a `pages` array ([{heading, url}]) for every section — present that list to the user yourself (e.g. numbered links); pages do not cross-link to each other. Prefer this over make_surface_url for multi-s

  • Make Surface Url

    Render an A2UI payload in the CALLER'S OWN environment. Pass renderer_url (your deployed renderer /exec) and get a live URL + the catalogs it declares. Omit renderer_url to get the encoded fragment + BYO guidance. We host nothing and never see your content. NEVER hand-write your own gzip/base64 encoding for the ?p= URL, in ANY language, even as a "just this once" fallback. This is the single most common cause of "could not decompress gzip" — a self-written encoder with one wrong flag (wrong wbi

  • Preview Url

    Quick DEMO render on the public renderer (ephemeral, nothing stored). Limited to 2 runs per client, then deploy your own renderer and use make_surface_url. Onboarding only — not the workflow. DATA-IN-URL: keep payloads SMALL (URL < ~2000 chars); large payloads make long URLs that get truncated (→ render errors). For substantial content GRADUATE with emit_deployment instead — no size limit.

  • Render Surface

    Render an A2UI payload INSIDE the chat as a live interactive view (MCP Apps hosts only — on other hosts this returns the payload as text). No URL, no size ceiling, nothing stored: the payload travels in the tool result and renders in the a2ui_catalog_view. Accepts the blocks dialect or a v1.0 createSurface envelope (templates + dataModel decode in the view). Prefer this over preview_url when the host supports MCP Apps. If the user names one of the Workspace's own pre-built views — Wall Builder,

  • Render Ping

    Diagnostic: render a tiny test view in-chat (MCP Apps hosts only). Proves view mounting works independent of the full catalog renderer. Echoes back whatever payload you pass.

  • Distill Document

    Compile a training.md / roadmap markdown document into a live interactive A2UI app — DETERMINISTIC parser, no model involved. Fact sheet: input is MARKDOWN following the training-md contract (frontmatter id/domain/name/source/license + a # Steps section); the text transits to the catalog's stateless parser service for the duration of the call and is NOT stored; lint errors come back as a structured report (fix and re-call). On success the result IS the compiled surface — MCP Apps hosts paint it

  • Publish Url

    STORES the payload server-side and returns a SHORT shareable link. Opt-in only: requires acknowledge_storage=true — confirm with the user first that they accept operator-hosted storage (ONE WEEK retention on the public tier, revocable earlier via the returned delete_token; anyone with the link can view). target "play" (default) renders in the a2uicatalog playground by reference (no URL size ceiling); target "gas" makes the short link redirect to the public Apps Script renderer. For storage in th

  • Unpublish Url

    Delete a published short link before its TTL using the delete_token returned by publish_url.

  • Emit Deployment

    🎓 GRADUATE a tested surface into a dedicated, DEPLOYER-ONLY standing app in YOUR OWN Google Apps Script account. Returns a deterministic recipe (config files + clasp ops + least-privilege scopes derived from the atoms + verify) — you run it with your own clasp; nothing runs on our side, we hold no creds.

  • Emit Training Runbook

    Build a multi-lesson training/course surface as ONE properly-linked page with real in-app tab navigation between lessons — prefer this over build_multi_page_surface for training/course content specifically: that tool produces N independent pages with NO links between them (you must present the list yourself); this tool produces one page where lessons are real, clickable tabs. Zero sizing/estimation judgment required — give it your lessons, it handles composition and navigation.

  • Emit Runbook Surface

    Stamp your content through a DECLARED runbook — a pre-authored, judgment-free surface composition. You supply content only; the runbook supplies the composition (which atoms, how arranged, navigation). DISCOVERY: call with runbook_id only (no content) to get that runbook's input_contract + parsing_guide — shape your source data to the contract (parsing is your job as the consumer), then call again with `content`. Some runbooks also return `elicit` — questions to ASK THE USER before you fill the

  • Describe Playbook

    Explain a playbook to a HUMAN as a rendered surface: the frame it reads against, the lenses available, and the questions it will ask them. Compiled from the runbook declaration, so it costs nothing and cannot drift from what the stamper enforces. This is NOT emit_runbook_surface discovery — that returns a contract addressed to YOU. Use this when someone asks what a playbook does or how it works; pass the result to render_surface.

  • Open Workspace

    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. "op

  • Get Profile

    Read the signed-in reader's saved profile and recent history. Call this BEFORE asking a runbook's `elicit` questions: if a domain or default lens is already saved, CONFIRM it ("reading as: a2ui, generative ui — change?") instead of asking from scratch. Returns available:false on the public endpoint, where there is no one to have a profile — that is the designed state, so degrade quietly and just ask the questions.

  • Save Profile

    Update the signed-in reader's profile. Only the keys you pass change; pass null to clear one. Save what the reader TOLD you, never what you inferred from one article — a profile that drifts on every reading is worse than no profile, because they stop being able to predict what it will do.

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

  • Export Reading

    Export a kept reading as something that outlives this connector. format "html" returns ONE self-contained file — styles inlined, no network, opens in any browser years from now with nothing installed. "url" rebuilds a link against any renderer (yours by preference). "surface" returns the payload for repainting in place. "json" returns the decoded payload. Needs a reading saved WITH its payload; older link-only rows cannot be re-rendered and will say so.

  • Render Reading To Slack

    Post a kept reading into Slack as real, native Block Kit — the continuity proof: generate here, save it, and the SAME content reopens in Slack, not a link back to a renderer. Requires the caller's Slack account to already be linked (`/a2ui link` in Slack) and only works on an authenticated connection — it posts to a real workspace using a shared bot token.

  • List Readings

    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.

  • Delete Reading

    Permanently remove one or more of the reader's saved readings from their History. Takes an array so the Workspace's multi-select can delete a batch in one call rather than one round trip per row. Ids that don't exist (or belong to someone else's history) are silently skipped — the response's `deleted` count says how many rows actually went, never assume it equals the number of ids you sent.

  • Unlink Slack Account

    Revoke one or more Slack accounts' link to this reader's store, from the Workspace side (the reverse of the Slack-side `/a2ui unlink` command — see slack-compiler/DESIGN-identity.md, "many Slack -> one sub"). Removes that account's ability to post via render_reading_to_slack or resolve to this reader; everything else about the reader's account is untouched. Takes an array so the Workspace's multi-select can revoke a batch in one call.

Get your MCP into directories

A working endpoint is step one. Directory coverage is the coordinated launch across ChatGPT, Claude, Cursor, the MCP Registry, and community indexes.

Directory coverage for brands

Frequently Asked Questions

What is the a2uicatalog MCP server?

A2UI Catalog: 500 typed, declarative UI components for AI agents — MCP-ready, no HTML generated by the model. Renders natively on web, Google Meet, Apps Script, Chat, and MCP Apps.

How do I connect a2uicatalog to my AI agent?

Use the MCP endpoint listed on this page in your MCP client configuration. One-click install pills support Claude, Cursor, VS Code, and other hosts. Copy the remote MCP URL if your client needs a manual entry.

How many tools does a2uicatalog provide?

MCPBundles probed 28 tools on the live server. The tool list on this page reflects what was discovered at the last refresh — connect your client to see the full set available to your session.

What authentication does a2uicatalog require?

No provider sign-in was required during MCPBundles' probe. Your client may still need MCPBundles credentials depending on how you connect.

Maintain this listing

Operate a2uicatalog? Verify ownership to take over this directory entry.

Operate a2uicatalog?

This server appears in the MCPBundles directory. Verify you operate it to take over the listing — name, description, logo, contact email, and skill content. We email a 6-digit code to a maintainer address your server publishes in /.well-known/security.txt or /.well-known/mcpbundles.json. Free, takes about a minute.

Claim this listing