Agentic Mermaid
Server Details
Render, verify, describe, and safely edit Mermaid diagrams through MCP.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.3/5 across 9 of 9 tools scored. Lowest: 3.7/5.
Each tool has a clearly distinct purpose: build creates new diagrams, mutate edits existing ones, describe provides descriptions, describe_sdk gives operation schemas, execute runs custom JS, render_* handles different output formats, and verify validates syntax. No two tools have overlapping responsibilities.
All tool names follow a consistent lowercase_snake_case convention (e.g., render_svg, describe_sdk). They use a predictable verb_noun pattern, making it easy for an agent to infer functionality from the name.
With 9 tools, the server is well-scoped for Mermaid diagram creation and manipulation. Each tool covers a distinct aspect (creation, editing, description, rendering, verification) without unnecessary duplication or bloat.
The tool surface covers the full diagram lifecycle (create, read, update, render) and provides fallback via execute for custom logic. A minor gap is the lack of a dedicated tool for raw source editing, but this is acceptable given the declarative alternatives.
Available Tools
9 toolsbuildARead-onlyIdempotentInspect
Author a new Mermaid diagram from blank by folding a list of structured ops
over an empty diagram of family. The declarative counterpart to hand-writing
source. Returns the same envelope as mutate:
{ ok, family, source, verify } or { ok:false, family, opIndex, error }.
Call describe_sdk for the family before authoring unfamiliar ops.
| Name | Required | Description | Default |
|---|---|---|---|
| ops | Yes | Ordered list of ops; each is { kind, ...fields }. | |
| family | Yes | Diagram family to author (one of: flowchart, state, sequence, timeline, class, er, journey, architecture, xychart, pie, quadrant, gantt, mindmap, gitgraph). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'Author a new Mermaid diagram' which implies a write operation, contradicting the annotations that declare readOnlyHint: true, idempotentHint: true, and destructiveHint: false. This is a severe contradiction, making the behavioral disclosure unreliable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with four short sentences, each adding essential information. It is front-loaded with the primary action and logically flows to return type and usage advice, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and lack of output schema, the description explains the return envelope and directs users to describe_sdk for op details. However, the annotation contradiction undermines completeness regarding whether the tool is truly read-only or creates new artifacts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning by specifying that ops is an ordered list of objects with { kind, ...fields } and enumerates the allowed families for the family parameter. It also advises calling describe_sdk for unfamiliar ops, which provides useful context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool authors a new Mermaid diagram from blank using a list of structured ops. It distinguishes itself as the declarative counterpart to hand-writing source and references sibling tools like mutate and describe_sdk, making its unique purpose evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains when to use the tool (to author a new diagram from blank) and provides guidance to call describe_sdk before authoring unfamiliar ops. However, it does not explicitly exclude scenarios where other tools like mutate should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
describeARead-onlyIdempotentInspect
Describe a Mermaid diagram. format=text returns { ok, text } with one or two summary sentences; format=json returns { ok, tree } with the AX tree; format=facts returns { ok, facts } with deterministic semantic fact lines for machine checking (for example edge A -> B : label, member Duck +quack()).
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | text (default), json AX tree, or facts semantic read-back. | |
| source | Yes | Mermaid source. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds detailed output shapes for each format (e.g., 'format=text returns { ok, text } with one or two summary sentences'). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, starting with the main purpose, then listing format options. Every part is essential and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but the description covers return values for each format. Parameter count is low and annotations are present. Missing error handling or prerequisites, but overall sufficient for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description adds meaning by explaining the effect of each format value and the default. It also clarifies that 'source' is Mermaid source. This goes beyond the schema's enum descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Describe a Mermaid diagram' using a specific verb and resource. It distinguishes from sibling tools like 'build', 'execute', etc., by focusing on description/analysis vs. creation/manipulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use each format (text, json, facts) but does not explicitly contrast with siblings like 'describe_sdk'. Guidance on when to use this tool vs. alternatives is implicit, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
describe_sdkARead-onlyIdempotentInspect
Return version-matched mutation operations for one diagram family. Use detail=signatures for the compact op menu or detail=fields (default) for exact field types, required flags, enum values, defaults, and constraints. Call this before build, mutate, or execute when the family schema is not already known.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | signatures for a compact menu; fields for the complete schema (default). | |
| family | Yes | Diagram family whose mutation operations are needed. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, and no destructive action. The description adds context about version-matching and being a prerequisite, but does not significantly deepen behavioral transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, front-loaded with the core purpose, and contains no redundant information. Each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately hints at the return value (mutation operations) and explains the two detail levels. For a simple 2-param tool with full schema coverage and annotations, it is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. The description adds value by clarifying the difference between 'signatures' and 'fields' detail levels and noting 'fields' is default, enhancing the agent's understanding of parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'version-matched mutation operations for one diagram family,' specifying the resource and action. It distinguishes from siblings by noting it is a prerequisite for build, mutate, or execute.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance on when to use the tool: 'Call this before build, mutate, or execute when the family schema is not already known.' It also explains the two detail levels and default behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
executeARead-onlyInspect
Run synchronous JavaScript against the mermaid SDK in an isolated sandbox. Code runs as an expression or statement body — return the final value. Promise jobs, async/await, and dynamic import are not supported. Multi-step diagram edits should be one execute() call. The SDK declaration is TypeScript-shaped for guidance; the sandbox does not transpile type annotations. Hosted note: execute runs in an on-demand isolate and costs more than the direct render_svg/render_ascii/render_png/verify/describe tools — prefer those for plain render/verify calls. For straightforward structured edits, prefer the declarative mutate/build tools; reserve execute for logic the ops don't express. Hosted mermaid.renderMermaidSVG*, renderMermaidASCII*, and layoutMermaidWithReceipt calls force security:'strict' and embedFontImport:false; caller code cannot weaken that host policy.
SDK declaration:
// Core Agentic Mermaid SDK available as global mermaid. Calls are synchronous and pure.
type DiagramKind = 'flowchart' | 'state' | 'sequence' | 'timeline' | 'class' | 'er' | 'journey' | 'architecture' | 'xychart' | 'pie' | 'quadrant' | 'gantt' | 'mindmap' | 'gitgraph'
type MutationOp = { kind: string; [field: string]: unknown }
type Result<T, E = { code: string; message: string }> = { ok: true; value: T } | { ok: false; error: E }
interface ValidDiagram { readonly kind: DiagramKind }
type ExternalFamilyId = family:${string}
interface ExtensionCompatibility {
readonly [contract: string]: string | undefined
readonly core?: string
readonly scene?: string
}
interface ExtensionProvenance { readonly owner: string; readonly source: string; readonly reference?: string }
interface ExtensionIdentity {
readonly id: ${Kind}:${string}
readonly kind: Kind
readonly version: string
readonly compatibility: ExtensionCompatibility
readonly provenance: ExtensionProvenance
}
interface SourceSpanPoint { readonly offset: number; readonly line: number; readonly col: number }
interface SourceSpan { readonly start: SourceSpanPoint; readonly end: SourceSpanPoint }
interface PreservedSourceSpans {
readonly source: SourceSpan
readonly wrapper?: SourceSpan
readonly header: SourceSpan
readonly body: SourceSpan
}
interface SourcePreservationReceipt {
readonly version: 1
readonly classification: 'unsupported' | 'inventory-only' | 'unknown'
readonly source: string
readonly header: string
readonly upstreamFamilyId?: string
readonly mermaidVersion: string
readonly spans?: PreservedSourceSpans
}
interface ParseError {
readonly code: string
readonly message: string
readonly line?: number
readonly col?: number
readonly preservation?: SourcePreservationReceipt
readonly help?: string
}
interface ExtensionValidDiagram {
readonly kind: ExternalFamilyId
readonly descriptorIdentity: ExtensionIdentity<'family'>
}
interface PreservedValidDiagram {
readonly kind: ExternalFamilyId
readonly body: {
readonly kind: 'preserved'
readonly representation: 'opaque' | 'unknown'
readonly source: string
readonly preservation: SourcePreservationReceipt
readonly spans: PreservedSourceSpans
readonly diagnostic: {
readonly code: 'UNSUPPORTED_FAMILY' | 'UNKNOWN_HEADER' | 'FAMILY_DESCRIPTOR_MISMATCH'
readonly message: string
readonly help: string
}
}
}
type ParsedDiagram = ValidDiagram | ExtensionValidDiagram | PreservedValidDiagram
interface VerifyResult { ok: boolean; warnings: unknown[]; layout: { bounds: unknown; nodes: unknown[]; edges: unknown[] } }
type CheckMermaidSpec = string[] | { include?: string[]; exclude?: string[]; exact?: boolean }
interface CheckMermaidResult { ok: boolean; missing: string[]; unexpected: string[]; facts: string[] }
type MermaidConfigScalar = string | number | boolean | null
type MermaidConfigValue = MermaidConfigScalar | MermaidConfigValue[] | { [key: string]: MermaidConfigValue | undefined }
type MermaidRuntimeConfig = { [key: string]: MermaidConfigValue | undefined }
type StyleInput = string | { [key: string]: unknown } type ArchitectureVisualOverrides = Readonly<Record<string, unknown>>
interface SharedRenderOptions { bg?:string;fg?:string;line?:string;accent?:string;muted?:string;surface?:string;border?:string;font?:string;style?:StyleInput | StyleInput[];padding?:number;nodeSpacing?:number;layerSpacing?:number;wrappingWidth?:number;componentSpacing?:number;transparent?:boolean;interactive?:boolean;shadow?:boolean;class?:{ hierarchicalNamespaces?:boolean };architecture?:{ visual?:ArchitectureVisualOverrides };timeline?:{ maxWidth?:number };journey?:{ experienceCurve?:boolean };gantt?:{ dependencyArrows?:boolean; criticalPath?:boolean };mermaidConfig?:MermaidRuntimeConfig;embedFontImport?:boolean;compact?:boolean;idPrefix?:string;security?:'default' | 'strict';ganttToday?:string;seed?:number;}
interface TerminalProjectionDiagnostic { code: string; feature: string; message: string } interface SvgRenderOptions extends SharedRenderOptions { onConfigDiagnostic?:(diagnostic: { code: 'INEFFECTIVE_CONFIG'; field: string; message: string }) => void;} interface AsciiRenderOptions extends SharedRenderOptions { useAscii?:boolean;paddingX?:number;paddingY?:number;boxBorderPadding?:number;colorMode?:'auto' | 'none' | 'ansi16' | 'ansi256' | 'truecolor' | 'html';theme?:{ fg?:string; border?:string; line?:string; arrow?:string; accent?:string; bg?:string; corner?:string; junction?:string };maxWidth?:number;targetWidth?:number;onProjectionDiagnostic?:(diagnostic: TerminalProjectionDiagnostic) => void;} interface LayoutRenderOptions extends SharedRenderOptions { debug?:boolean;regions?:boolean;actions?:boolean;}
interface RenderArtifactDiagnostic { code: string; message?: string; reference?: string; feature?: string; input?: string; canonicalId?: string; removal?: { release: string; date: string } }
interface CapabilityResolution { readonly id: ${string}:${string}; readonly range: string; readonly level: 'required' | 'preferred' | 'optional'; readonly status: 'selected' | 'unsupported' | 'incompatible'; readonly version?: string }
interface CapabilityDecision { readonly version: 1; readonly accepted: boolean; readonly resolutions: readonly CapabilityResolution[] }
interface RenderExecutionDecision { readonly family: { readonly id: string; readonly version: string };readonly backend: { readonly mode: 'scene'; readonly requestedId: string; readonly selectedId: string; readonly version: string; readonly hostPolicy: boolean } | { readonly mode: 'family-svg' };readonly digest: string;}
interface RenderRequestReceipt { version: 1; output: 'svg' | 'png' | 'ascii' | 'unicode' | 'html' | 'layout'; sharedRequestDigest: string; requestDigest: string; appearanceDigest: string; capabilityDecision?: CapabilityDecision; diagnostics?: readonly RenderArtifactDiagnostic[]; graphicalProjectionDigest?: string; executionDecision?: RenderExecutionDecision }
interface RenderedSvg { svg: string; receipt: RenderRequestReceipt } interface RenderedAscii { text: string; receipt: RenderRequestReceipt; terminalStyle: Record<string, unknown>; outputPolicy: Record<string, unknown> } interface RenderedLayoutArtifact { layout: VerifyResult['layout']; receipt: RenderRequestReceipt }
declare const mermaid: { parseMermaid(source: string): Result<ValidDiagram, ParseError[]> // Open parser for installed families; built-in authoring ops remain ValidDiagram-only. parseRegisteredMermaid(source: string): Result<ParsedDiagram, ParseError[]> createMermaid(kind: DiagramKind, opts?: { direction?: 'TD' | 'TB' | 'LR' | 'BT' | 'RL' }): ValidDiagram buildMermaid(kind: DiagramKind, ops: MutationOp[], opts?: { direction?: 'TD' | 'TB' | 'LR' | 'BT' | 'RL' }): Result<ValidDiagram, { code: string; message: string; opIndex: number }> asFlowchart(diagram: ValidDiagram): ValidDiagram | null asState(diagram: ValidDiagram): ValidDiagram | null asSequence(diagram: ValidDiagram): ValidDiagram | null asTimeline(diagram: ValidDiagram): ValidDiagram | null asClass(diagram: ValidDiagram): ValidDiagram | null asEr(diagram: ValidDiagram): ValidDiagram | null asJourney(diagram: ValidDiagram): ValidDiagram | null asArchitecture(diagram: ValidDiagram): ValidDiagram | null asXyChart(diagram: ValidDiagram): ValidDiagram | null asPie(diagram: ValidDiagram): ValidDiagram | null asQuadrant(diagram: ValidDiagram): ValidDiagram | null asGantt(diagram: ValidDiagram): ValidDiagram | null asMindmap(diagram: ValidDiagram): ValidDiagram | null asGitGraph(diagram: ValidDiagram): ValidDiagram | null mutate(diagram: ValidDiagram, op: MutationOp): Result verifyMermaid(input: ParsedDiagram | string, opts?: { suppress?: string[]; labelCharCap?: number }): VerifyResult analyzeMermaid(diagram: ValidDiagram): Record<string, unknown> analyzeMermaidSource(source: string): Result<Record<string, unknown>> describeMermaidFacts(diagram: ValidDiagram): string[] describeMermaidFactsSource(source: string): Result<string[]> checkMermaid(diagram: ValidDiagram, spec: CheckMermaidSpec): CheckMermaidResult checkMermaidSource(source: string, spec: CheckMermaidSpec): Result serializeMermaid(diagram: ParsedDiagram): string renderMermaidSVG(input: ParsedDiagram | string, opts?: SvgRenderOptions): string renderMermaidSVGWithReceipt(input: ParsedDiagram | string, opts?: SvgRenderOptions): RenderedSvg renderMermaidASCII(input: ParsedDiagram | string, opts?: AsciiRenderOptions): string renderMermaidASCIIWithReceipt(input: ParsedDiagram | string, opts?: AsciiRenderOptions): RenderedAscii layoutMermaidWithReceipt(input: ParsedDiagram | string, opts?: LayoutRenderOptions): RenderedLayoutArtifact describeOps(family: DiagramKind): Record<string, { name: string; required: boolean; type: string; note?: string }[]> opSignatures(family: DiagramKind): string[] }
// Use describe_sdk or describeOps/opSignatures for unfamiliar MutationOp shapes.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | JavaScript to execute; mermaid.* SDK is global. | |
| timeoutMs | No | Optional CPU-time budget (default 5000ms, max 30000ms). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral details beyond annotations: synchronous execution, no async/await, dynamic import restrictions, and security policy for render calls. The annotations already indicate readOnly and non-destructive, but description enriches with execution constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
While the SDK declaration is lengthy, it's relevant as a reference. The core description is front-loaded with purpose and usage guidance, making it structured and informative without superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity, no output schema, and only two parameters, the description is exceptionally complete, covering purpose, usage, behavioral details, and even providing the full SDK API for reference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds context on how to structure code (multi-step edits in one call) and the global SDK availability. This goes beyond the schema's minimal descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs synchronous JavaScript against the Mermaid SDK in an isolated sandbox, and distinguishes it from other tools like render_svg, mutate, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to prefer other tools for simple operations and to use execute only for logic not expressible by declarative tools, with cost considerations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mutateARead-onlyIdempotentInspect
Apply a list of structured edit ops to an existing Mermaid source and
return the edited diagram. This is the declarative counterpart to execute:
plain JSON in, plain JSON out, no sandbox. Prefer it for straightforward edits;
reserve execute for logic the ops don't express.
Returns { ok, family, source, verify:{ ok, warnings } } on success, or
{ ok:false, family, opIndex, error } — where error names the offending field
and lists the valid ones — when an op is malformed or cannot apply. Ops apply in
order and are all-or-nothing: the first failing op stops the batch (its position
is opIndex) and the input is left untouched.
Each op is { "kind": , …fields }. Call describe_sdk for the detected
family before authoring unfamiliar ops; it returns compact signatures or exact
field types, enum values, defaults, and constraints.
| Name | Required | Description | Default |
|---|---|---|---|
| ops | Yes | Ordered list of edit ops; each is { kind, ...fields }. | |
| source | Yes | Mermaid source to edit. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses all-or-nothing batch execution, error format with opIndex, and success return structure including verification field. Annotations already indicate read-only and idempotent behavior, and the description reinforces this without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Six sentences with no wasted words. The most important information (purpose, contrast with sibling, usage guidance) is front-loaded. Every sentence provides essential context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given sibling tools (execute, verify, describe_sdk, etc.), the description covers differentiation, usage, return types, error handling, and preprocessing advice. No output schema exists, but the description adequately describes the return format and verification sub-object.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters. The description adds value by explaining that ops are ordered edit ops with 'kind' and other fields, and references 'describe_sdk' for detailed field types, enums, and defaults—going beyond the generic schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it applies structured edit ops to Mermaid source and returns the edited diagram. It explicitly contrasts with the sibling 'execute' tool, defining itself as the declarative counterpart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use this tool vs. 'execute': prefer for straightforward edits, reserve 'execute' for logic not expressible by ops. Also advises calling 'describe_sdk' before authoring unfamiliar ops.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
render_asciiARead-onlyIdempotentInspect
Render a Mermaid source string to text. Returns { ok, text }. useAscii true → plain ASCII (+,-,|); false/absent → Unicode box drawing (┌,─,│). targetWidth sets a hard terminal display-cell bound; impossible bounds return a typed error.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | Mermaid source. | |
| options | No | Shared advanced RenderOptions object, including style/palette/config/security. | |
| useAscii | No | true = ASCII characters, false = Unicode (default). | |
| targetWidth | No | Hard maximum line width in terminal display cells. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral details: it returns { ok, text }, explains the effect of useAscii (character mapping), and notes that impossible targetWidth bounds return a typed error. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with 4 sentences, no repetition, and front-loaded with the core purpose. Every sentence provides essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (read-only, text output), the description covers all necessary aspects: input (Mermaid source), configuration (useAscii, targetWidth), return format, and one error case. No output schema exists, but the return shape is specified. It is complete for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 4 parameters. The tool description adds value by elaborating on parameter behavior: for useAscii it gives specific character examples (+,-,| vs ┌,─,│), and for targetWidth it adds the error condition. This goes beyond the schema's brief descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Render a Mermaid source string to text' and specifies the return shape { ok, text }. The verb 'render' and resource 'Mermaid source' are specific, and the tool name 'render_ascii' distinguishes it from siblings like render_png and render_svg.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the useAscii flag to choose between ASCII and Unicode output, and mentions targetWidth for terminal display bounds. However, it does not explicitly compare with render_png/svg or state when not to use this tool. The context is clear but lacks exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
render_pngARead-onlyIdempotentInspect
Rasterize a Mermaid source string to PNG. Returns { ok, png_base64 }. Hosted rendering uses resvg-wasm with bundled fonts; bytes may differ from the local napi renderer, so hosted PNG is a convenience surface, not part of the byte-determinism contract. For file/URL artifacts use the local stdio server.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | Deterministic re-roll seed for stochastic Styles. | |
| fitTo | No | Exactly one output width or height constraint. | |
| scale | No | Positive output scale used when no fitTo constraint is supplied. | |
| style | No | A registered name, inline StyleSpec, or left-to-right stack of either. | |
| source | Yes | Mermaid source. | |
| options | No | Shared advanced RenderOptions object; compatibility convenience fields above override matching values. | |
| background | No | Portable basic color or hex color painted behind the raster artifact. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the tool's safety is clear. The description adds important behavioral context: it uses resvg-wasm with bundled fonts, and bytes may differ from the local napi renderer, meaning it is not byte-deterministic. This goes beyond annotations to warn about output variability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core action and return format, followed by a caveat and alternative guidance. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and 7 complex parameters, the description covers the return format and an important behavioral nuance (byte non-determinism). It hints at alternatives but does not mention error conditions or limitations. Overall adequate for a read-only rendering tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are well-documented in the schema. The description does not add any additional parameter semantics, only mentioning the source string. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool rasterizes a Mermaid source string to PNG and returns { ok, png_base64 }. It distinguishes itself from siblings by output format (PNG vs SVG/ASCII) and mentions when not to use it (file/URL artifacts should use local stdio server).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that hosted rendering is a convenience surface and not byte-deterministic, advising use of the local stdio server for file/URL artifacts. It implicitly distinguishes from other rendering tools by format but does not explicitly list when to choose this over render_svg or render_ascii.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
render_svgARead-onlyIdempotentInspect
Render a Mermaid source string to themeable SVG. Returns { ok, svg }. Layout is deterministic: identical input produces identical geometry. The hosted boundary forces security:'strict' and embedFontImport:false.
| Name | Required | Description | Default |
|---|---|---|---|
| bg | No | Background color or CSS variable. | #FFFFFF |
| fg | No | Primary foreground and text color. | #27272A |
| seed | No | Deterministic re-roll seed for stochastic Styles. | |
| style | No | Style: a registered Look (crisp, hand-drawn, excalidraw, pen-and-ink, freehand, watercolor, blueprint, look:tufte, accessible-high-contrast, patent-drawing, status-dashboard, ops-schematic, chalkboard, risograph, architectural-plan, publication-figure), Palette (paper, dusk, zinc-light, zinc-dark, tokyo-night, tokyo-night-storm, tokyo-night-light, catppuccin-mocha, catppuccin-latte, nord, nord-light, dracula, github-light, github-dark, solarized-light, solarized-dark, one-dark, salmon, salmon-dark, palette:tufte, tufte-dark), inline record, or left-to-right stack. | |
| theme | No | Deprecated compatibility input (one of: paper, dusk, zinc-light, zinc-dark, tokyo-night, tokyo-night-storm, tokyo-night-light, catppuccin-mocha, catppuccin-latte, nord, nord-light, dracula, github-light, github-dark, solarized-light, solarized-dark, one-dark, salmon, salmon-dark, tufte, tufte-dark); use style with a Palette name. | |
| source | Yes | Mermaid source. | |
| options | No | Shared advanced RenderOptions object; compatibility conveniences override matching values. Styles accept a registered Look (crisp, hand-drawn, excalidraw, pen-and-ink, freehand, watercolor, blueprint, look:tufte, accessible-high-contrast, patent-drawing, status-dashboard, ops-schematic, chalkboard, risograph, architectural-plan, publication-figure), Palette (paper, dusk, zinc-light, zinc-dark, tokyo-night, tokyo-night-storm, tokyo-night-light, catppuccin-mocha, catppuccin-latte, nord, nord-light, dracula, github-light, github-dark, solarized-light, solarized-dark, one-dark, salmon, salmon-dark, palette:tufte, tufte-dark), inline record, or left-to-right stack. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by stating 'Layout is deterministic: identical input produces identical geometry' and 'The hosted boundary forces security:'strict' and embedFontImport:false.' These details enhance transparency beyond the annotations, though more context (e.g., error behavior) could be provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that front-load the purpose and key behavioral traits. Every sentence serves a purpose with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 params, nested options, no output schema), the description is adequate but minimal. It covers purpose and key behaviors, but lacks details on error handling, performance, supported Mermaid versions, or how to interpret the output beyond 'Returns { ok, svg }'. The rich schema compensates partially.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add any parameter-specific meaning beyond what the schema already provides. The schema descriptions are detailed, so the description's lack of parameter info does not degrade utility.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Render a Mermaid source string to themeable SVG. Returns { ok, svg }.' It uses a specific verb ('Render') and resource ('Mermaid source string to SVG'), and distinguishes from sibling tools like render_ascii and render_png by specifying the output format and the deterministic property.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., render_ascii, render_png), nor does it state prerequisites or when not to use it. The deterministic layout note is behavioral, not usage-related.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verifyARead-onlyIdempotentInspect
Parse and verify a Mermaid diagram without rendering it. Returns
{ ok, family, summary, warnings, layout: { bounds, nodes, edges } } for valid
diagrams and { ok: false, errors } for parse failures. family is the detected
diagram family and summary a one-line description — check them: ok:true only
means the diagram is structurally valid, not that it is the kind you intended.
Warnings use the layout-rubric codes.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | Mermaid source. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, idempotentHint, and destructiveHint, so the description adds value by detailing the return shape and warning that ok:true only means structural validity, not intended diagram family. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the main action. It includes necessary details but is slightly lengthy; every sentence adds value, though could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter and comprehensive annotations, the description fully covers behavior, return values, and warnings. It compensates for the lack of an output schema by detailing the return shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the 'source' parameter described as 'Mermaid source'. The tool description does not add additional semantics beyond what the schema provides, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Parse and verify a Mermaid diagram without rendering it', specifying the verb (parse/verify) and resource (Mermaid diagram), and distinguishes from rendering siblings by explicitly noting 'without rendering it'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the return structure and warns about checking ok, family, and summary, guiding the agent on when to use and how to interpret results. It implicitly distinguishes from rendering tools but lacks explicit alternative mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!