Skip to main content
Glama
yinnho

AginxBrowser

render_markdown

Renders Markdown documents into deterministic, self-contained HTML with inline SVG diagrams from fenced archify JSON, plus theme/preset/quality audits and optional live-session verification.

Instructions

Render a markdown document into a deterministic, self-contained HTML artifact - the document layer, so the agent never writes HTML by hand. Prose rides a plain offline shell (no fonts, no scripts); archify fenced code blocks carry typed zero-coordinate diagram JSON (sequence, workflow, architecture, dataflow, lifecycle families) and render to inline SVG via the layout engine. Same input, same bytes: the receipt carries the sha256 so determinism is verifiable. theme picks light (default) or dark; preset picks the palette family — classic (default), signal-flow, blueprint, editorial — orthogonal to theme; colors bake at generation time (presentation attributes, not CSS variables), and the receipt records both preset and theme. quality picks the composition audit profile — standard (default) or showcase, the delivery gate: the receipt's diagrams[].composition grades route crossings, ambiguous corridors, label clearance (2px standard / 4px showcase), route rhythm, and node text projected to the 930px reader width; the audit never changes the artifact bytes. Mermaid sources are the agent's job to translate, not the engine's: flowchart/graph → workflow (lanes + columns), sequenceDiagram → sequence, stateDiagram-v2 → lifecycle (bands), erDiagram/class → architecture (grid + boundaries) — read the topology and emit the matching zero-coordinate archify JSON; the engine accepts only archify JSON. A broken diagram degrades to a visible code block and lands in receipt.diagnostics; an authored route preset that cannot be honored is self-repaired to a verified semantic substitute and disclosed in receipt diagrams[].repairs - the document still renders. A fence may also carry views: [{id,label,nodes,note?}] (node ids of the active family), emitted as guided-view tabs above the diagram plus an inlined viewer script - clicking a tab lights the member nodes and the routes between them (subgraph), clicking a node lights it with its direct neighbors (ego graph), everything else dims; a view's optional note shows as a caption while it is active (the story layer). window.agxViewer in a session drives and reads the same state programmatically: {focus,view,state} as before, plus route(i,from,to) which returns and lights the shortest authored directed path between two nodes (null when unreachable, state untouched), and reach(i,id,down|up) which returns and lights the authored downstream/upstream closure ({nodes,links}); both dim the rest of the diagram. diagrams[].views in the receipt lists the tabs. motion: true bakes an entrance choreography into the artifact: pure-declarative CSS animation with zero scripts - headings split into per-glyph (CJK) / per-word (latin) spans that rise in with expo easing, prose blocks stagger up an nth-child delay ladder, diagram figures grow in with a back ease (GSAP's easing math as public cubic-bezier equivalents, nothing embedded); the diagrams themselves play a flow story on the same clock - nodes land beat by beat, solid edges draw in (dash-offset), dashed returns fade, sequence messages arrive as sent - with a timed caption strip under each figure as the subtitles, which becomes a static transcript under prefers-reduced-motion; the file itself animates in any browser and the receipt records motion plus diagrams[].story (beat times and captions - the hook for muxing voice later). With session_id the artifact is also loaded into that session (local, free) and the reply carries viewport acceptance: scroll extents measured in the live session and graded fits/tall/wide/oversized, telling the agent how to read the page back. Diagram vocabulary adapted from archify (MIT).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
themeNoColor theme: "light" (default) or "dark" — the shell background/ foreground and every SVG palette slot swap together; the receipt records which theme produced the bytes
motionNoBake the entrance choreography into the artifact (default false): pure-declarative CSS animation — headings split into per-glyph/per- word spans that rise in with expo easing, prose blocks stagger up a nth-child delay ladder, and diagram figures grow in with a back ease (GSAP's easing math as public cubic-bezier equivalents). The diagrams animate too, on one story clock: nodes pop in one beat at a time, solid edges draw themselves (dash-offset drain), dashed returns fade, sequence messages land as they are "sent", and a timed caption strip under each figure subtitles the beats — under prefers-reduced-motion the strip becomes a static transcript. Zero scripts: the file itself animates in any browser, subtitles and all; the receipt records motion (plus diagrams[].story with the beat times, the hook for muxing voice later) so a cached artifact is never mistaken for the static one
presetNoVisual preset: "classic" (default), "signal-flow", "blueprint", or "editorial" — a palette family orthogonal to theme (each preset exists in both light and dark). The receipt records preset and theme separately
qualityNoQuality profile for the composition audit: "standard" (default) or "showcase" — the delivery gate. The audit grades route crossings, corridors, label clearance, rhythm, and projected text size in the receipt (diagrams[].composition); it never changes the artifact bytes, only how findings are severity-rated
markdownYesFull markdown document. Prose rides a plain offline shell; archify fenced code blocks carry typed zero-coordinate diagram JSON and render to inline SVG.
session_idNoOptional session ID: also load the rendered HTML into that live session (local and free) so session_screenshot / session_state can verify the artifact

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.5.1
    • addedInput schema / properties / motion
      Added value: +{
      +  "description": "Bake the entrance choreography into the artifact (default false):\npure-declarative CSS animation — headings split into per-glyph/per-\nword spans that rise in with expo easing, prose blocks stagger up a\nnth-child delay ladder, and diagram figures grow in with a back\nease (GSAP's easing math as public cubic-bezier equivalents). The\ndiagrams animate too, on one story clock: nodes pop in one beat at\na time, solid edges draw themselves (dash-offset drain), dashed\nreturns fade, sequence messages land as they are \"sent\", and a\ntimed caption strip under each figure subtitles the beats — under\nprefers-reduced-motion the strip becomes a static transcript.\nZero scripts: the file itself animates in any browser, subtitles\nand all; the receipt records motion (plus diagrams[].story with\nthe beat times, the hook for muxing voice later) so a cached\nartifact is never mistaken for the static one",
      +  "type": [
      +    "boolean",
      +    "null"
      +  ]
      +}
    • removedInput schema / title
      Removed value: -"RenderMarkdownParams"
  2. Addedv0.3.0

TDQS

A3.9/5.0
Behavior5/5

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

The annotations carry only a title, so the description bears the full disclosure burden, and it delivers extensively: deterministic bytes with a sha256 receipt for verification, a fully offline shell (no fonts/scripts), graceful degradation of broken diagrams to visible code blocks with diagnostics, self-repair of unhonorable route presets disclosed in repairs, reduced-motion fallback to a static transcript, and session loading described as local/free. This far exceeds the transparency expectations for an unannotated tool.

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

Conciseness2/5

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

The first sentence is well front-loaded, but the description runs roughly 700 words and buries actionable content under implementation minutiae an agent does not need to invoke the tool: GSAP easing math as cubic-bezier equivalents, per-glyph CJK span splitting, an nth-child delay ladder, and full window.agxViewer API signatures (route(i,from,to), reach(i,id,down|up)). Much of the motion prose is duplicated nearly word-for-word in the schema's motion description, so those sentences do not earn their place.

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?

Given the tool's high complexity (6 parameters, a demanding archify JSON input contract, no output schema) and a title-only annotation, the description is exceptionally complete: it specifies defaults for every option, input format requirements, failure and repair semantics, determinism verification via the receipt, post-call viewport grading (fits/tall/wide/oversized), and even licensing provenance. An agent has everything needed to call and verify this tool correctly.

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 coverage is 100%, so the baseline is 3, and the description adds meaning above it: theme/preset are orthogonal with colors baked at generation time as presentation attributes rather than CSS variables, quality thresholds are quantified (2px standard / 4px showcase, 930px reader width), and failure/repair behavior is tied to each option. Some marginal value is lost because the schema's motion parameter description already repeats nearly the full animation behavior verbatim.

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?

The opening sentence is specific: 'Render a markdown document into a deterministic, self-contained HTML artifact - the document layer, so the agent never writes HTML by hand.' The verb (render), resource (markdown document), and output (self-contained HTML) are unambiguous. However, unlike the strongest examples, it never names its siblings render_pdf/render_video or explains the boundary between them, so the differentiation is implicit rather than explicit.

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?

The description gives strong in-tool input guidance ('Mermaid sources are the agent's job to translate, not the engine's... read the topology and emit the matching zero-coordinate archify JSON; the engine accepts only archify JSON'), which tells the agent what to feed it and what not to feed it. But there is no explicit when-to-use-this-vs-alternatives guidance for tool selection against render_pdf/render_video; the only usage framing is the implied 'use this instead of writing HTML by hand.'

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