mcp-chat-cards

Overview Schema Source Related Servers Discussions Admin

Create sequential list card

create_list_card

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

Instructions

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

Input Schema

Name	Required	Description
`intro`	No
`items`	Yes
`title`	Yes
`subtitle`	No
`tutorTerms`	No	Educational tutor terms. The first occurrence of each term in the card's visible prose is underlined; hovering ~1.2s shows the tip and notifies the host so the model can follow up. Terms are matched once per card, longest first, and never inside code samples, tooltips, or another term's tip. Matching is CASE-SENSITIVE, so "PATH" does not attach its tip to a filesystem "path"; set caseInsensitive on a term to match any casing. Term and tip are PLAIN text.
`contextActions`	No	Right-click menu actions the model anticipates being useful. Choosing one sends its prompt to the conversation; use {{selection}} to include the user's selected text.

Output Schema

Name	Required	Description
`card`	Yes
`parts`	Yes	Split state, present on EVERY card result so one completeness check works for all card types. Cards that cannot split always report {current:1,total:1,hasMore:false}; create_markdown_card and create_code_tour_card pack oversized content into parts and can report more. Read hasMore rather than the card title to decide whether content was withheld.
`display`	No	Present only when the host is not mounting this server's MCP Apps template (see MCP_CHAT_CARDS_RENDER): the card ships as a ready-made visualizer widget instead.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.0.0-alpha.1.0.1Oct 17, 2026

addedOutput schema / properties / display

Added value: +{
+  "additionalProperties": false,
+  "description": "Present only when the host is not mounting this server's MCP Apps template (see MCP_CHAT_CARDS_RENDER): the card ships as a ready-made visualizer widget instead.",
+  "properties": {
+    "action": {
+      "description": "What the caller must do to put the card in front of the user",
+      "type": "string"
+    },
+    "loading_messages": {
+      "description": "show_widget loading_messages",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "shown": {
+      "description": "False: the user cannot see this card until action is taken",
+      "type": "boolean"
+    },
+    "title": {
+      "description": "show_widget title (snake_case)",
+      "type": "string"
+    },
+    "widget_code": {
+      "description": "show_widget widget_code, passed unchanged",
+      "type": "string"
+    }
+  },
+  "required": [
+    "shown",
+    "action",
+    "title",
+    "loading_messages",
+    "widget_code"
+  ],
+  "type": "object"
+}

Changed6 schema fields changedv0.1.3-alphaAug 21, 2026

removedInput schema / $schema

Removed value: -"http://json-schema.org/draft-07/schema#"

changedInput schema / properties / tutorTerms / description

Previous value: -"Educational tutor terms. The first occurrence of each term in the card's visible prose is underlined; hovering ~1.2s shows the tip and notifies the host so the model can follow up. Terms are matched once per card, longest first, and never inside code samples, tooltips, or another term's tip. Term and tip are PLAIN text."New value: +"Educational tutor terms. The first occurrence of each term in the card's visible prose is underlined; hovering ~1.2s shows the tip and notifies the host so the model can follow up. Terms are matched once per card, longest first, and never inside code samples, tooltips, or another term's tip. Matching is CASE-SENSITIVE, so \"PATH\" does not attach its tip to a filesystem \"path\"; set caseInsensitive on a term to match any casing. Term and tip are PLAIN text."

addedInput schema / properties / tutorTerms / items / properties / caseInsensitive

Added value: +{
+  "description": "Match the term regardless of letter case (default false)",
+  "type": "boolean"
+}

removedOutput schema / $schema

Removed value: -"http://json-schema.org/draft-07/schema#"

addedOutput schema / properties / parts

Added value: +{
+  "additionalProperties": false,
+  "description": "Split state, present on EVERY card result so one completeness check works for all card types. Cards that cannot split always report {current:1,total:1,hasMore:false}; create_markdown_card and create_code_tour_card pack oversized content into parts and can report more. Read hasMore rather than the card title to decide whether content was withheld.",
+  "properties": {
+    "current": {
+      "description": "Part number this result rendered (1-based)",
+      "type": "number"
+    },
+    "hasMore": {
+      "description": "True when content was withheld; call again with part: current + 1",
+      "type": "boolean"
+    },
+    "total": {
+      "description": "How many parts the content splits into",
+      "type": "number"
+    }
+  },
+  "required": [
+    "current",
+    "total",
+    "hasMore"
+  ],
+  "type": "object"
+}

changedOutput schema / required

Previous value: -[
-  "card"
-]New value: +[
+  "card",
+  "parts"
+]

Changed1 schema field changedv0.1.1-alphaAug 12, 2026

changedInput schema / properties / tutorTerms / description

Previous value: -"Educational tutor terms. Occurrences in the card are underlined; hovering ~1.2s shows the tip and notifies the host so the model can follow up."New value: +"Educational tutor terms. The first occurrence of each term in the card's visible prose is underlined; hovering ~1.2s shows the tip and notifies the host so the model can follow up. Terms are matched once per card, longest first, and never inside code samples, tooltips, or another term's tip. Term and tip are PLAIN text."

First observedv0.0.0-alphaAug 10, 2026

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden, yet it only describes what the card looks like. It says nothing about the creation/mutation semantics, the interactive tutorTerms and contextActions behavior, or any side effects — all of which matter for a tool that constructs a live card.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences with the core capability front-loaded and the numbering scheme given concretely. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be described, and the two complex params carry rich schema docs. However, with no annotations and no mention of the card's interactive features, the definition is only minimally complete for an agent deciding how to populate it.

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 only 33%, so the description must compensate. It does explain the nested/hierarchical nature that maps to items.children (which itself has no schema description), but it never mentions title, intro, subtitle, tutorTerms, or contextActions, leaving half the parameters to the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Render) and resource (nested ordered list card) plus the distinctive feature (hierarchical numbering 1., 1.1., 1.1.1.). It is clearly distinguishable from sibling card types like create_table_card or create_chart_card, though it never names them explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

"Good for procedures, outlines, and curricula" gives implied usage context, but there is no explicit when-not guidance and no routing to alternatives (e.g., a flat list or a markdown card). The agent must infer when this card beats its siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.