Render an interactive card with tabs, each showing a different context of the same subject (for example one tab per programming language, OS, or skill level). Tab content can be plain text, HTML, or code with a copy button.

Render an HTML table card from explicit rows, or convert loosely delimited text into a balanced table (delimiter auto-detected; newlines can mark cells). URL cells become links.

Render a form card the user fills in to give the conversation context and direction. Submitting sends the values back to the chat as the next prompt (optionally shaped by promptTemplate with {{fieldName}} tokens).

Open step 1 of the efficient-prompt flow: a card asking the user to describe, in no more than 350 characters, the gist of where they want to go. Call this when a message is tagged [efficient-prompt], or when the user asks for help writing a prompt. Submitting the card sends back the gist along with the rules for the rest of the flow, so answer with the card and wait rather than asking follow-up questions in chat.

Step 2 of the efficient-prompt flow: ask the fewest multiple-choice questions that close the gaps the gist left. Radios by default, checkboxes when several answers can be true at once; every question also gets a free-text "Other". At most 3 refine rounds - pass the round number so the card can say how many are left. Skip this step entirely when the gist is already clear enough to write the prompt.

Step 3 of the efficient-prompt flow: hand back the finished prompt in an editable card with a character and token count, a copy button, and a send button gated behind a confirmation box. Write one prompt that is verbose only where verbosity buys a complete first-pass answer: no restated context, no filler, an explicit output shape. Do not act on the prompt here - wait for the user to send it back as a message.

Render a dynamically generated SVG chart card (bar, line, pie, or donut) with a legend and a collapsible data table. Use for useful graphics summarizing referenced data.

Render a card with an HTML video player for a short clip. src must point straight at a video file (mp4/webm): a direct http(s) URL, a small data:video/* URI, or a blob: URL. Streaming platform page URLs (YouTube, Vimeo, Twitch, TikTok, and similar) are REJECTED, because a video element pointed at a player page renders a card that can never play. When no direct video source exists, use create_animation_card to generate an animated clip instead.

Render a short animated clip as a card when no direct video URL exists but motion would communicate better than static content - explanations, walkthroughs, and data stories. Scenes play sequentially in a 16:9 stage with play/pause, replay, and progress controls; everything is generated text, SVG shapes, and CSS animation (no external assets). Compose classic clip patterns and vary them per conversation: title reveal into bullet build (fade/slide), diagram walk-through with arrows tracing in (draw), a chart that zooms into the label range under discussion and back out (chart.zoom), and a closing takeaway scene (zoom). Mix scene kinds freely; per-scene transition and duration make endless variations from the same schema.

Render a card of collapsible show/hide sections with show-all/hide-all buttons. Good for step-by-step guides, FAQs, spoilers, and long reference material. Put source in a section's code field rather than inline in text, so it renders as a monospace block with a copy button instead of a paragraph.

Render a nested ordered list card with hierarchical numbering (1., 1.1., 1.1.1.). Good for procedures, outlines, and curricula.

Render a markdown document as one interactive card: tables become card tables, fenced code gets copy buttons, and H2 sections fold into show/hide reveals. Pass either the markdown content or the path of a markdown file generated earlier in the conversation (for example a walkthrough or guide) to plug it into the chat in one call. Raw HTML in the markdown is NOT rendered as markup: it is shown as literal text, the same as in every other card's text fields, so use markdown syntax for formatting. Long documents split at H2 boundaries into parts of about 32,000 rendered characters each; the result's structuredContent.parts {current,total,hasMore} says whether more parts remain. A document with no H2 headings cannot be split and renders as one part.

Render a project's source as an interactive card with one tab per file. Source files are syntax-highlighted for their detected language and line-numbered, with a Raw/Code toggle and a copy button, the way a repository browser shows a file; a language with no grammar renders as a plain code block. Markdown files (.md, .markdown, .mdx) render as a formatted page - headings, tables, links, copyable fenced code - with a Raw/Rendered toggle back to the source, so a README in a tour reads as documentation rather than as source. Explicit files keep the order they are given in, with README and manifests hoisted to the front; archive files are ordered README, manifest, then src. Pass the path of a zip archive generated earlier in the conversation for a one-call plug-n-play tour, or pass files explicitly. Files are packed into parts of about 32,000 rendered characters each regardless of how many there are, so a handful of medium files still splits. The result's structuredContent.parts {current,total,hasMore} reports the split: while hasMore is true some files were withheld, so call again with part: current + 1 and identical other arguments until every part has rendered.

Return the Insert Card bookmarklet and usage instructions. Browsers do not let page script extend the native right-click menu, so this bookmarklet is how a copied card gets placed visually: after the user copies a card (right-click menu "Copy card" or the header button), running the bookmarklet on the host page shows an "Insert Card" item beside every right-click, which injects the copied card at that spot. The insertion is cosmetic and page-local (gone on reload, not part of the conversation history). Call this when the user asks how to place a card at an arbitrary spot on the page.

Read a text file from the filesystem OF THE MACHINE RUNNING THIS SERVER so its content can be reviewed and plugged into cards. Over a remote bridge that is not the caller's sandbox: a file you generated on your side is not visible here, so pass its text to the card tool directly. Size-capped; binary files are refused. Set MCP_CHAT_CARDS_FS_ROOT to confine reads to one directory.

List a zip archive's entries and return the contents of its text files, so a project can be inspected and turned into cards (code tours, tables, walkthroughs). The path is resolved ON THE MACHINE RUNNING THIS SERVER, not in the caller's sandbox. Build caches and binary entries are skipped.

Fetch a public web page and return structured data: title, description, headings, readable text, tables, images, links, and form specifications. Feed the results into the card tools (tables into create_table_card, numbers into create_chart_card, and so on).

Fetch a public web page, extract one of its forms, and render it as an interactive card in the conversation. When the user submits the card, the values return to the chat as a structured payload for the submit_web_form tool, so a model-created task can submit the actual website form.

Submit values to a real website form (form-encoded GET or POST). Only call this with data the user entered in a mirrored form card, or values the user explicitly confirmed. Returns the HTTP status and a snippet of the response.