Skip to main content
Glama
jhauga

mcp-chat-cards

by jhauga
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Create code tour card

create_code_tour_card

Turn a project's source into an interactive card with tabbed, syntax-highlighted files, line numbers, raw/code views, and rendered Markdown, making code review and navigation simpler.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
partNoPart number for large projects (1-based). Big tours split automatically; while structuredContent.parts.hasMore is true, call again with the next part.
filesNoExplicit files to show when not using archivePath
introNoGuidance shown in a leading 'Start here' tab
titleYes
includeNoWith archivePath: only include entries whose path contains one of these
maxTabsNo
subtitleNo
tutorTermsNoEducational 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.
archivePathNoPath to a zip ON THE MACHINE RUNNING THIS SERVER, not in the caller's sandbox. Over a remote bridge those are different machines: if the archive exists only on your side, pass its text files as files instead.
contextActionsNoRight-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.
tutorTermsInCodeNoAlso highlight tutorTerms inside the code samples. Off by default, because marking up language keywords in source is noise rather than teaching.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
cardYes
partsYesSplit 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv0.1.3-alpha
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • changedInput schema / properties / part / description
      Previous value: -"Part number for large projects (1-based). Big tours split automatically; when the result says more parts remain, call again with the next part."New value: +"Part number for large projects (1-based). Big tours split automatically; while structuredContent.parts.hasMore is true, call again with the next part."
    • 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"
+]
  2. Changed3 schema fields changedv0.1.1-alpha
    • changedInput schema / properties / archivePath / description
      Previous value: -"Path to a local zip; its text files become tabs"New value: +"Path to a zip ON THE MACHINE RUNNING THIS SERVER, not in the caller's sandbox. Over a remote bridge those are different machines: if the archive exists only on your side, pass its text files as files instead."
    • 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."
    • addedInput schema / properties / tutorTermsInCode
      Added value: +{
+  "description": "Also highlight tutorTerms inside the code samples. Off by default, because marking up language keywords in source is noise rather than teaching.",
+  "type": "boolean"
+}
  3. First observedv0.0.0-alpha

TDQS

A4.6/5.0
Behavior5/5

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

With zero annotations, the description carries the full disclosure burden and meets it thoroughly. It reveals the surprising behaviors an agent must know: files split into ~32,000-character parts regardless of count, README/manifests are hoisted, ordering differs for archives vs explicit files, unknown languages degrade to plain code blocks, and the hasMore loop may withhold files. This is exactly the kind of non-obvious behavior that prevents incorrect invocation.

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?

The description is long (~300 words) but earnestly dense: each clause conveys a behavioral fact — rendering features, markdown special-casing, file ordering, splitting, pagination — and there is no filler. It is front-loaded with the core purpose before the detail. The only structural weakness is that it is one undifferentiated block; paragraph breaks at the markdown, ordering, and pagination transitions would improve scanability.

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

Completeness5/5

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

For an 11-parameter, zero-annotation tool with a rich output schema, the description is remarkably complete. It covers the rendering contract, the markdown exception, ordering semantics, both invocation modes, the splitting mechanism, and the paging loop tied to structuredContent.parts. The output schema already documents return shape, so the description needn't repeat it. Nothing an agent needs to call this correctly across multipart tours is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 73%, so the schema already documents most parameters well. The description adds genuine value beyond it: it clarifies the archivePath-vs-files choice ('Pass the path of a zip archive generated earlier in the conversation'), quantifies the part size (~32,000 rendered characters), and adds the 'identical other arguments' constraint for pagination. The few schema-undocumented fields (subtitle, title, path/content/language inside file objects) are self-evident from their names, so the gap is acceptable.

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?

The opening sentence states a specific verb and resource: 'Render a project's source as an interactive card with one tab per file.' It then enumerates concrete rendering features (syntax highlighting, line numbers, Raw/Code toggle, copy button) that make the tool unmistakable against the sibling card-creation tools. The markdown-handling special case further narrows the identity — this is clearly the source-code card, not a generic tab or markdown card.

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

Usage Guidelines4/5

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

The description gives explicit invocation guidance: pass a zip archive path for a 'one-call plug-n-play tour' or pass files explicitly, and it specifies the pagination protocol ('while hasMore is true ... call again with part: current + 1 and identical other arguments'). This is strong operational guidance. However, it never names sibling tools or states when NOT to use this tool (e.g., when a plain markdown card would suffice), so exclusions are left to inference.

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

Deploy Server

Other Tools