Skip to main content
Glama

vizcharter_create

Generate presentation-ready architecture diagrams, charts, KPI dashboards, and infographics from a JSON spec, with auto-layout, themes, and export to SVG, PNG, JPG, or PDF.

Instructions

Render a VizCharter diagram from a spec and export it. Returns a PNG preview (look at it and iterate!), written file paths, embed snippets, and lint findings. Spec family 'architecture': { family:'architecture', title?, subtitle?, theme? (vizcharter-light|vizcharter-dark|aws), direction? ('AUTO' default — lays out both ways and keeps the tighter canvas | 'DOWN' | 'RIGHT'), nodes:[{id, icon? (registry id, see vizcharter_icons), label, sublabel?, parent? (container id), pin?:{x,y}}], containers:[{id, type:'region'|'account'|'vpc'|'subnet'|'az'|'layer'|'group', label, parent?}], edges:[{from, to, kind?:'sync'|'async'|'config'|'data', label?}], callouts?:[{n, at}], legend?:boolean }. Layer containers auto-rotate pastel tints; edge kinds get distinct styling and an auto legend. Spec family 'chart': { family:'chart', type:'bar'|'bar-stacked'|'bar-grouped'|'line'|'area'|'donut'|'pie'|'rose'|'venn'|'kpi', title?, theme?, width?, height?, categories?+series? (axis types), slices? (donut/pie/rose), sets?+overlaps? (venn, 2-3 sets), tiles? (kpi: {label, value, delta?, sublabel?}), options?: { showValues?, showLegend?, donutLabel? } } — same design tokens as diagrams. Spec family 'canvas' (infographics/posters): { family:'canvas', theme?, page?:{width,height,background?}, template?:{name, slots} (see vizcharter_templates; auto-sizes the page), layers?:[ {kind:'text', x,y,width?,text,style?,align?} | {kind:'shape', shape:'rect'|'circle'|'line', ...} | {kind:'icon', icon,x,y,size} | {kind:'chart', x,y,spec} | {kind:'arch', x,y,scale?,spec} | {kind:'svg', x,y,content} (raw-SVG escape hatch) ] — embed full chart/architecture specs into posters. ALL families accept an optional meta footer block, rendered as an elegant hairline band: { author?, org?, project?, version?, date?, classification? (outlined chip, e.g. 'Confidential'), source? (attribution line), note? } — use it when the user asks for authorship, versioning, dates, classification, or source attribution on a deliverable. Files land in /diagrams// including the re-editable .vizc.json source.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesDiagram name — used for the output directory and file names
specYesThe diagram spec (family 'architecture')
formatsNoExport formats (default: svg, png)
out_dirNoBase output directory (default: current working directory)
png_scalesNoPNG scale factors, 0.25–4 (default: [1, 2])
preview_onlyNoRender the preview without writing any files
Behavior4/5

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

With no annotations, the description carries the behavioral burden and mostly succeeds: it discloses write side effects (files land in <out_dir>/diagrams/<name>/, including editable source), return payloads (PNG preview, paths, embed snippets, lint findings), and spec-rendering behaviors such as AUTO direction layout, auto-rotating container tints, and auto legends. It stops short of describing error/edge behavior or the exact effect of preview_only.

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?

Long, but every sentence earns its place. It front-loads the core purpose and return values, then organizes the DSL by family (architecture, chart, canvas, meta) with no repetition or filler.

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 a complex tool with nested spec families and no output schema, this description gives the agent everything needed to invoke it correctly: output behavior, file destinations, valid spec shapes, defaults, and a usage trigger for the meta block. No critical invocation detail is missing.

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

Parameters5/5

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

Schema coverage is 100%, but the schema's spec property is nearly a stub. The description adds enormous semantic value by enumerating every spec family, its fields, allowed values, defaults, and composition rules (e.g., canvas layers can embed full chart/architecture specs), going far beyond the structured schema.

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 names a concrete verb and resource: 'Render a VizCharter diagram from a spec and export it.' It is clear about what the tool does, but it does not explicitly contrast with siblings such as vizcharter_update or vizcharter_export, so an agent must infer the creation-vs-update/export boundary.

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 makes the primary use case obvious and even adds a targeted trigger for the meta footer ('use it when the user asks for authorship...'). However, it never states when not to use this tool or when a sibling (update, export, templates) would be the right choice, so the selection guidance is implied rather than explicit.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/onemorepereira/vizcharter'

If you have feedback or need assistance with the MCP directory API, please join our Discord server