A2UI Atomic Catalog

Open a real, cycle-exact Amiga 500 emulator in-chat (MCP Apps hosts only). Boots straight into AROS, a free open-source environment (no copyrighted Kickstart ROM involved), with a public-domain Amiga game already loaded and running. This is a fixed, self-contained retro-computing demo -- there is nothing to configure and no arguments to give it; call it when someone wants to see or play with a real emulated Amiga. On a host without MCP Apps support this says so as text; an emulator has no useful non-visual form.

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-section content.

Build a PowerPoint (.pptx) file from a scene list or an A2UI payload. Deterministic (same input, same bytes), nothing is stored or fetched, text is fitted with real font metrics and the file is linted (overlap, bounds, contrast, alt text). Returns the file as an embedded resource plus a report: errors, lint, warnings and unsupported atoms. Opens in PowerPoint and Google Slides (checked in Google Slides). Demo limit: 10 builds a day per connection.

List the slide layouts the PPTX renderer builds (title, bullets, stats, quote, table, media, cta), each field with its limits, the targets, the film-only scenes, and the A2UI atoms that have a slide recipe (payload_atoms). Read this before writing a deck.

Check a deck (scene list or A2UI payload) without building it. Returns every error with its slide, field and exact limit, warnings (no speaker notes, no link) and, for a payload, which atoms have no slide recipe. Not rate-limited.

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.

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.

Draw a diagram in-chat with the full Diagram Studio interface (MCP Apps hosts only; it opens fullscreen where the host allows it). YOU write the diagram; nothing is generated server-side and nothing is stored. PREFER `graph`: give vertices (id, label, type start|process|decision|database|cloud|end) and edges (source, target, optional label). The person then gets the whole studio: they can switch the same graph between Mermaid, D2, PlantUML and draw.io, flip its direction, zoom, copy the code, open it in the real draw.io editor with one click, and edit nodes and connections themselves (their edits come back to you). Use `syntax` with `source` instead only for diagrams a flow graph cannot express, drawn exactly as written: "mermaid" for sequence, class, state, ER, gantt and mind maps; "d2" for architecture diagrams with containers and nested boxes. Give exactly one of `graph` or `syntax` with `source`. Keep diagrams compact (the input schema states the limits). If the tool or the view reports a problem, fix it and call this tool again. On a host without MCP Apps support the diagram comes back as text.

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 in the view; other hosts can pass the returned payload to preview_url for a link.

Open a diagram you wrote in draw.io (diagrams.net). YOU write the diagram as mxGraph XML, the format draw.io reads; this tool checks it, and returns a link that opens it in the draw.io editor for the person, plus a .drawio file to download (kept for one hour). Nothing is drawn or laid out for you, so give every shape its x, y, width and height. The XML must be uncompressed and shaped like this (ids unique, every shape parent="1", edges name source and target ids): <mxGraphModel><root><mxCell id="0"/><mxCell id="1" parent="0"/><mxCell id="a" value="Start" style="rounded=1;whiteSpace=wrap;html=1;" vertex="1" parent="1"><mxGeometry x="40" y="40" width="120" height="60" as="geometry"/></mxCell><mxCell id="b" value="Done" style="rounded=1;whiteSpace=wrap;html=1;" vertex="1" parent="1"><mxGeometry x="240" y="40" width="120" height="60" as="geometry"/></mxCell><mxCell id="e1" style="edgeStyle=orthogonalEdgeStyle;html=1;" edge="1" parent="1" source="a" target="b"><mxGeometry relative="1" as="geometry"/></mxCell></root></mxGraphModel> If the check finds problems it lists each one with the cell id and the fix; correct the XML and call again. Limits: 200 KB of XML and 500 cells. For AWS and Google Cloud diagrams the check also looks at missing labels, overlaps, text that does not fit, contrast and placement (for example an instance outside a subnet); each finding names the cell. These are vendor-style conventions drawn from draw.io's own libraries, not an official checker from AWS or Google. Labels may use simple HTML (set html=1 in the style); scripts, iframes, event handlers and javascript: links are refused. The diagram travels in the link's fragment, which is never sent to a server.

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

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 contract. Ask them; do not guess the answers. ON SUCCESS YOU GET BOTH `payload` AND `url`, AND THEY ARE NOT THE SAME OFFER. `payload` is the compiled surface — pass it STRAIGHT to render_surface and the reading appears inline, in the conversation, where the reader already is. `url` is the shareable link, for later or for elsewhere. Default to rendering: handing back only a link makes the reader leave to see the thing they asked for. If the reading was too large to encode as a link you get `payload` and `url_unavailable` instead — that is a SUCCESS, so render it and say the link is missing. Available stampable runbooks: (1) learning_hub — curriculum/revision study app: subject tabs, slide pills, timeline/drill/flashcards/quiz/takeaways/method interactions per slide, the full rich hub UI. Prefer this over emit_training_runbook for study/curriculum content — much richer output, still zero composition decisions. (2) article_playbook — a steered critical reading of SOMEONE ELSE'S article: source attribution bar, a hero mental-model card, then rungs down a rail. The reader picks a lens (explain, apply to their domain, challenge, situate in prior art) and says what they want it to look for; the rung progression is Toulmin (claim → grounds → warrant) so the analysis lands on the assumption a summary drops. Use it whenever asked to analyse, critique, tear down, or work out what an article means for a particular domain. You fetch and read the article yourself; nothing is retrieved server-side.

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.

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.

Semantic search over the atom catalog: describe the UI piece you need in plain words and get the best-matching atoms, ranked best-first, each with a description and an example need. YOU choose from the list (the first entries are most likely, but check the descriptions), then call get_atom_schema for the one(s) you pick. Use this instead of scanning get_catalog when the vocabulary is large. Describe the need as a user would (e.g. "let clients choose grooming services and see the total price"), not by guessing an atom name.

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.

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

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.

CALL THIS FIRST, before any other a2ui-catalog tool, once per session. Declares your own model identity so this response can hand you capability-matched guidance up front — some models need simpler, judgment-free tools; skipping this just means you default to the full toolkit, including tools that require sizing/pagination judgment calls. HOW TO ANSWER — do not guess: - Copy your model name EXACTLY as stated in your own system prompt or developer context (look for phrasing like "you are powered by the model named X" or similar). Do NOT infer it from your training cutoff, your own behavior, or general capability. - Examples of valid values: "claude-haiku-4-5", "claude-sonnet-5", "claude-opus-4-8", "gemini-2.0-flash", "gpt-4o". Partial names are fine ("haiku", "sonnet"). - If your model name is genuinely not stated anywhere in your context, pass "unknown" — do NOT guess a plausible-sounding value. A wrong report is worse than no report: it can hand you tools you cannot reliably operate.

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.

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.

Make a short motion film (a social clip, launch teaser, quote card...) built by the A2UI Design Studio: you choose a template and supply the words; the studio builds the film. Use this instead of composing motion_timeline blocks yourself. It plays inline here and comes with a link that opens in the A2UI Studio app on Android, where the user can edit the text and export MP4 or GIF on the phone. BEFORE CALLING, ask the user in one short message for what you do not know: what it is about (the hook line), any real numbers with their labels, the call to action, and where it will be posted (portrait 9:16 for LinkedIn/Instagram/stories, 16:9 for slides or YouTube, 1:1 for a quote card). Never invent statistics: with no real numbers, use scenes without a Numbers or Chart scene. Templates (each a ready scene sequence; pass `scenes` to replace it): launch: Product launch, Title, numbers, phone, call to action (16:9; scenes title > stats > device > cta) data: Data story, Chart, numbers, steps (16:9; scenes title > chart > stats > steps) agent: Agent demo, Chat, particle word, CTA (16:9; scenes chat > word > cta) quote: Quote card, A quote and a name (1:1; scenes quote > cta) hook: LinkedIn hook, Portrait: captions, numbers, CTA (9:16; scenes captions > stats > cta) client: Client feature demo, Title, features that light up beside your pictures, CTA (16:9; scenes title > features > cta) event: Event promo, Particle word, title, photo, CTA (16:9; scenes word > title > morph > cta) Scene types and their fields (`fields` keys; text supports *word* for the accent colour; list fields take one item per line in the format the label gives): title (Title): eyebrow = Eyebrow; headline = Headline (use *word* for accent); sub = Subline stats (Numbers): kicker = Kicker; stats = Stats, one per line: value | label; roll = Number style chart (Chart): heading = Heading; kind = Chart; data = Data, one per line: label value; unit = Unit chat (Chat): heading = Heading; messages = Messages, alternating you / agent word (Particle word): word = Word (A-Z 0-9, up to 12); sub = Subline features (Feature walkthrough): heading = Heading; features = Features (2-6): a title, a line of detail and an optional picture each; images = collage (Collage swap): heading = Heading; sets = Sets of tiles, up to 4, separated by a blank line. One tile per line: label | optional picture link (2-6 tiles a set); hold = Seconds each set stays (0.8 to 8); swap = Seconds the swap and outline change take (0.4 to 3); fx = Panel outline bubbles (Bubbles title): heading = Heading; count = Bubbles (2-14) beats (Beat countdown): items = One word or number per beat, 2-8 lines (fades; keep each beat over 0.35 s) dock (Icon dock): heading = Heading; items = Icons, one per line: glyph | name (2-7) lit (Cards light up): heading = Heading; cards = Cards, one per line: title | text (2-6) arcs (Arc mark): heading = Heading; effect = Effect lockup (Centred lockup): lines = Lines, one per line; write {mark} where the arc mark goes (up to 4 lines); effect = Effect pattern (Text pattern): text = Repeated text; word = One word turned on its side (optional); angle = Angle (-90 to 90) fit (Fill-the-width word): word = Word (up to 20 characters); recede = Recede at the end; effect = Effect morph (Shape morph): heading = Heading; shapes = Shapes (comma list; also panel, notch, step, tab); wide = Wide panel (1.78:1); effect = Effect image (Photo): heading = Heading; url = Image URL (https); caption = Caption device (Phone): heading = Heading; items = Checklist on the phone captions (Captions): sentence = Sentence (lights word by word) steps (Steps): heading = Heading; steps = Steps, one per line (2-6) quote (Quote): quote = Quote; name = Name; role = Role cta (Call to action): headline = Headline; b1 = Button 1 text; l1 = Button 1 link; b2 = Button 2 text; l2 = Button 2 link; foot = Footer line Give the user the returned `link` as well as showing the film.

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 wbits, standard vs. urlsafe base64, un-stripped padding) produces a broken URL at ANY size, not just large ones. Always call this tool again — never substitute your own implementation. SIZING IS AUTOMATIC — you do not need to estimate, count characters, or decide whether to split. Call this tool ONCE with your FULL, unsplit payload. If it fits, you get back `url` (and nothing else to do). If it does not fit the real size ceiling, the tool SPLITS IT FOR YOU server-side (at natural heading boundaries) and returns `auto_split: true` plus a `pages` array of independent URLs — present that list to the user (e.g. as numbered links) instead of the single `url`. Never pre-split your content before the first call; always send everything in one call and let the response tell you what happened. GRADUATE substantial surfaces with emit_deployment instead (no size limit at all) when you want a standing app rather than a shareable link. IF A RENDER CHECK REPORTS "could not decompress gzip" / "Render error" / "invalid distance too far back" on a URL this tool returned: STOP. Do NOT call this tool again with the SAME unchanged payload — re-call it with the SAME payload once to confirm, and if it still fails, use emit_deployment instead. Never fall back to a hand-written encoding script.

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.

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.

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 the USER's own account use emit_deployment; for nothing-stored links use preview_url.

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.

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.

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.

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, profile, history, links, composer — call open_workspace(view: ...) instead of composing one here yourself; those are wired demos with their own state, not something to reconstruct block by block. And never invent a generic block type (there is no "text" or "button" atom) — call get_catalog / get_atom_schema for the real vocabulary first; an unrecognised type is caught and replaced with a visible notice rather than silently dropped, but the block still won't render as intended.

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

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.

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.

Continue a sketch_agent_start task: returns every stroke newer than the given cursor (an event log, not a snapshot — nothing is skipped regardless of poll timing) plus the next cursor, reveals the result in-chat the same way render_surface does, and reports whether the drawing is complete. Call again with the returned cursor until done is true.

Start a real, live agent_sketchpad drawing: one Gemini call plans a complete picture as an ordered list of SVG strokes, the first stroke renders immediately, and the rest reveal as you call sketch_agent_poll again — a real multi-turn task, not a single one-shot render. MCP Apps hosts only (same as render_surface). Stateless server: the task is held in KV for 1 hour, not in this connection — keep the returned taskId and the next cursor to keep polling.

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.

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

Compute a coursed block/brick wall specification — course and unit counts, weight, cost, mortar bags, a build-time curve across 1-6 builders, and load-bearing/height advisories. Pure arithmetic, no model call: a native-catalogue rebuild of the Gemini Enterprise "Wall Builder" demo, kept byte-for-byte correct against that original's formulas (see mcp-worker/test/test_wall_calc_parity.py). `country` is not an input — it is derived from block_id and returned in the result.

Diagnostic (MCP Apps hosts only): mounts a view that instantiates a tiny hand-assembled WebAssembly module, computes per-frame state in it, renders to canvas, and captures arrow-key input -- the same three ingredients a WASM game port would need. Answers whether THIS host permits WASM execution inside a ui:// View iframe; it proves nothing about any other host or sandbox.

Report who this connection is authenticated as. Answers two SEPARATE questions that are easy to conflate: which APPLICATION is connected (the OAuth client), and which HUMAN authorised it (the signed-in account, when the endpoint is one that can know). The public endpoint is anonymous by design and will say so — that is not an error, it is the free tier. Use it to check whether per-user features (saved profile, reading history) are available before offering them.