Skip to main content
Glama
Sign In
ChartQuery MCP Server

ChartQuery MCP Server

by chartquery
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Diagram AI

diagram_ai
Read-only

Generate rendered diagrams from plain-English descriptions. Specify diagram type, entities, and relationships to receive SVG, PNG, JPEG, or PDF output.

Instructions

Diagram AI. Describe a diagram in plain English via GET and get a rendered image back. Powered by AI. Credit cost: 10 credits per call.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "prompt": "<prompt>"
    },
    "name": "diagram_ai"
  }
}

Input Schema

NameRequiredDescriptionDefault
shareNoSet share=true to persist the config and receive JSON instead of an image: { id, render_url, view_url, embed_url, expires_in }. Free plan: 3-day expiry. Paid plan: 6-month expiry. Default: false.
fieldsNoComma-separated list of fields to keep in the response, with dot notation for nested fields (e.g. name,location.city). Does not change the credit cost.
promptYesDescribe your diagram in plain English (max 1000 chars). Be specific: mention the diagram type, key entities, and relationships.
diagram_typeNoPreferred diagram language. AI chooses if omitted. Examples: "mermaid", "d2", "plantuml", "graphviz". Allowed values: mermaid, d2, plantuml, graphviz. Default: "mermaid".
output_formatNoOutput format. Default: "svg". Allowed values: svg, png, jpeg, pdf. Default: "svg".

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, matching the described read-only GET behavior, so no contradiction exists. The description adds genuinely useful behavioral context not in annotations: a fixed cost of 10 credits per call, which lets the agent reason about call frequency. It omits error behavior, rate limits, and the fact that share=true changes the response shape, but the schema covers the latter.

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?

Four short sentences, front-loaded with the core action, and no padding beyond the redundant title echo and the vague 'Powered by AI' line. Every other clause carries information the agent can act on, notably the per-call credit cost.

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

Completeness4/5

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

For a five-parameter generative tool with full schema coverage, rich annotations, and no output schema, the description covers the essentials: what it produces, that it is a plain-English GET, and what it costs. The remaining gaps, such as that share=true returns JSON URLs instead of an image, are documented in the parameter schema rather than the description.

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 description coverage is 100%, and each of the five parameters (prompt, share, fields, diagram_type, output_format) has a detailed inline description including defaults and allowed values, so the schema carries the semantic load. The description adds only the implicit constraint that the prompt should be plain-English prose, which the schema already states. Baseline 3 applies when the schema does the heavy lifting.

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 second sentence states a concrete verb and resource: describe a diagram in plain English and get a rendered image back, which tells the agent it is a generative image tool rather than a static renderer. It never names or contrasts with siblings such as diagram, diagram_render, or chart_ai, so the agent cannot distinguish this from similar tools without opening other schemas. The leading title restatement ('Diagram AI.') adds nothing beyond the name.

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

Usage Guidelines2/5

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

Usage is only implied by the phrase 'Describe a diagram in plain English' – there is no explicit when-to-use, no when-not-to-use, and no routing to diagram, diagram_render, or chart_ai even though several siblings overlap heavily. The credit-cost note hints that calls are costly, but the description never says when a cheaper alternative should be preferred.

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