CodePic
Server Details
AI agent draws editable hand-drawn diagrams (flowchart, ER, architecture) via MCP, not static images
- 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.5/5 across 6 of 6 tools scored.
Each tool has a clearly distinct purpose: create from description vs template, get state, get shape docs, list templates, and update. The descriptions include strict usage rules to avoid confusion even between similar creation tools.
All tool names follow a consistent verb_noun pattern using snake_case: create_diagram, create_from_template, get_diagram, get_shape_docs, list_templates, update_diagram.
With 6 tools covering creation, retrieval, reference, and update, the count is well-scoped for a diagramming server. Each tool serves a necessary function without redundancy.
Core create, get, and update operations are present, but there is no delete tool or tool to list user's own diagrams, which are notable gaps. Templates are supported but user diagram management is incomplete.
Available Tools
6 toolscreate_diagramCreate DiagramAInspect
Create a custom CodePic hand-drawn style diagram by specifying nodes and edges. Requires API Key authentication. Returns a public view URL.
THIS IS THE DEFAULT TOOL FOR ANY USER-DESCRIBED DIAGRAM. Whenever the user describes a diagram they want ("draw an A/B test flowchart", "帮我画一个登录流程", "a system architecture with a load balancer and 3 servers", etc.), build it here from their description. Do NOT fall back to create_from_template / list_templates unless the user explicitly asked for a template.
When responding to the user, present the returned URL as a clickable markdown link (e.g. [Open in CodePic →](URL)) so the user can click it directly in their AI client (Cursor / Claude / etc.).
Container nesting (IMPORTANT — use whenever possible):
Set
parentIdon a node to nest it inside another node. ANY node type can be a container.The parent automatically becomes draggable-as-a-group and users can keep dropping elements into it.
Good container types:
frame(clean group box),rect/rounded-rect(module boundary),package(UML package),swimlane(process lane).Use absolute canvas coordinates for all nodes — child coordinates are auto-converted to parent-relative.
Rule: whenever 2+ nodes logically belong to the same module / component / region, create a container node first and set
parentIdon each child.
Design tips for beautiful diagrams:
Use semantic types:
button-primaryfor CTA buttons (auto blue),diamondfor decisionsPick a color palette and apply it consistently — light fill + darker stroke of the same hue: • Blue: fillColor #e3f2fd / #bbdefb, strokeColor #1565c0, fontColor #1565c0 (or #ffffff on dark fill) • Green: fillColor #e8f5e9 / #c8e6c9, strokeColor #2e7d32, fontColor #1b5e20 • Purple: fillColor #f3e5f5 / #e1bee7, strokeColor #6a1b9a, fontColor #4a148c • Neutral: fillColor #f8fafc / #f1f5f9, strokeColor #475569, fontColor #1e293b
Each semantic group (decisions, processes, I/O) should share a fill color to create visual hierarchy
Dark fill (e.g. #1565c0, #ef4444) → fontColor #ffffff; light fill → fontColor #111827
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Document name | |
| edges | No | Array of connector edges between nodes | |
| nodes | Yes | Array of shape nodes to place on the canvas | |
| backgroundColor | No | Canvas background color (default: '#f8f9fa') |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses authentication requirements ('Requires API Key authentication'), output format ('Returns a public view URL'), and nesting behavior (parentId auto-converts coordinates, parent becomes containable). While it doesn't detail error handling or rate limits, it provides sufficient behavioral context for a creation tool.
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 with clear sections, bold headers, and front-loaded purpose. While it is verbose, every sentence adds value—from authentication to design tips to nesting rules. It could be slightly more concise but remains efficient for the tool's complexity.
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 (many node types, styling options, nesting) and lack of output schema, the description is remarkably complete. It covers authentication, output, design best practices, and references 'get_shape_docs' for deeper details. An agent can successfully use this tool with the provided context.
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%, but the description adds substantial value beyond the schema. It explains the purpose of node types with examples (e.g., 'button-primary=blue CTA'), provides design color palettes, and gives detailed usage for fields like 'data' and 'parentId' with when-to-use instructions. This goes well beyond the schema definitions.
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 action: 'Create a custom CodePic hand-drawn style diagram by specifying nodes and edges.' It also explicitly marks itself as the default tool for user-described diagrams, distinguishing it from siblings like 'create_from_template' and 'list_templates'.
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 explicit guidance: 'THIS IS THE DEFAULT TOOL FOR ANY USER-DESCRIBED DIAGRAM... Do NOT fall back to create_from_template / list_templates unless the user explicitly asked for a template.' It also advises on container nesting and design tips, covering when to use specific features.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_from_templateCreate from TemplateAInspect
Create a new CodePic diagram from a predefined template. Requires API Key authentication. Returns a public view URL and edit URL.
STRICT USAGE RULE — READ BEFORE CALLING: Only call this tool when the user has explicitly asked to use a template. Explicit signals include phrases like: "use a template", "from template", "用模板", "从模板创建", "list templates and pick one", or the user directly naming/selecting a template slug.
If the user merely describes a diagram they want (e.g. "draw an A/B test flowchart", "帮我画一个登录流程", "给我做一个系统架构图"), DO NOT call this tool. Call create_diagram instead and build the diagram from the user's description. Never silently substitute a template for a described diagram — the user will get a generic result that does not match what they asked for.
When responding to the user, present the returned URL as a clickable markdown link (e.g. [Open in CodePic →](URL)) so the user can click it directly in their AI client (Cursor / Claude / etc.).
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Document name (defaults to template name) | |
| slug | Yes | Template slug (e.g. 'flowchart', 'erd', 'kanban'). Call list_templates to see all. | |
| locale | No | Language for template content (default: en) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses authentication requirements ('Requires API Key authentication'), return values (public view URL and edit URL), and the critical behavioral constraint of when the tool should be invoked. Missing details on error handling or rate limits, but acceptable for this tool.
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 relatively long but well-structured with a bolded usage rule section. It is front-loaded with purpose. However, it could be more concise by omitting the redundant 'e.g.' examples in the strict rule and merging the URL presentation note.
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 explains return values (public view URL and edit URL). It covers authentication, usage context, and parameter defaults. It is complete for a tool with 3 simple parameters and a clear sibling tool for comparison.
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 the baseline is 3. The description adds modest value by providing an example slug and noting defaults for name and locale, but does not elaborate beyond the schema definitions. No additional parameter semantics are needed.
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 'Create a new CodePic diagram from a predefined template', specifying the verb (create), resource (CodePic diagram), and method (from template). It distinguishes from sibling tool create_diagram by implying templates are a separate input method.
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 explicit 'STRICT USAGE RULE' with clear examples of when to call this tool (user explicitly asks for template) vs when to use create_diagram (user describes a diagram). It also lists anti-patterns and exceptions, making it very helpful for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_diagramGet DiagramAInspect
Fetch the current state of an existing CodePic diagram. Returns a compact summary of all elements with their IDs, types, positions, and parent-child relationships. Use this before update_diagram when you need to: add nested children to existing containers, make targeted edits to specific elements, or understand the current structure. Requires API Key authentication.
| Name | Required | Description | Default |
|---|---|---|---|
| documentId | Yes | Document ID to fetch |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses auth requirement ('Requires API Key authentication') and describes return content (compact summary, element details). Does not mention rate limits or performance, but adequate for a read operation.
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?
Three sentences, front-loaded with purpose, then return content, then usage context and auth. No unnecessary words, efficient and well-structured.
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 it's a simple fetch operation with one parameter and no output schema, the description covers all essential aspects: purpose, return content, usage context, and auth requirement. Feels 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 coverage is 100%, so baseline is 3. Description adds minimal value beyond schema for the single parameter 'documentId' (only 'current state' hint). Parameter semantics are adequate but not enhanced.
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 'Fetch the current state of an existing CodePic diagram' with specific verb and resource, and details the return content (IDs, types, positions, parent-child). It distinguishes from siblings like create_diagram and update_diagram.
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 says to use before update_diagram for adding nested children, making targeted edits, or understanding structure. Implies when not to use (e.g., for creating new diagrams), but does not list all siblings explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_shape_docsGet Shape DocsAInspect
Return the full CodePic shape reference — all element types, their fields, data payloads, and JSON examples. Call this before create_diagram or update_diagram whenever you need to use an unfamiliar shape type or set type-specific data fields (e.g. select options, triangle direction, callout tail). No authentication required.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description adds transparency by stating 'No authentication required'. It implies the tool is read-only and returns static data, though could be more explicit about having no side effects.
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?
Two sentences with no superfluous text. Front-loaded with the return value, followed by usage context and authentication note.
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?
The description is self-contained: it specifies what the tool returns, when to use it, and that no authentication is needed. No output schema or parameters require elaboration.
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?
No parameters exist, so the description does not need to add parameter information. Baseline score of 4 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 returns the full CodePic shape reference with element types, fields, data payloads, and JSON examples. It distinguishes itself from sibling tools like create_diagram and update_diagram by being a static reference.
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 says 'Call this before create_diagram or update_diagram whenever you need to use an unfamiliar shape type or set type-specific data fields', providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_templatesList TemplatesAInspect
List all available CodePic diagram templates. Use this ONLY when the user has explicitly asked to browse, list, or pick from templates (e.g. "show me templates", "列出模板"). Do NOT call this as a preparatory step when the user just described a diagram they want — in that case go straight to create_diagram. Discovering slugs here is only meaningful before a user-confirmed create_from_template call.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Filter by category |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description bears full burden. It correctly implies a read-only listing operation without stating it explicitly, which is sufficient. No mention of auth or rate limits, but not required for this simple tool.
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?
Two sentences, each serving a clear purpose: first states the function, second provides critical usage guidance. No superfluous text, perfectly front-loaded.
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?
Lacks explicit description of return value structure (e.g., what fields are returned for each template), which is important for a listing tool. However, the context of sibling tools implies slugs are returned, making it mostly complete for its simplicity.
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?
The single optional parameter 'category' is fully documented in the input schema with enum values and description. The description adds no additional information beyond the schema, leading to a baseline score of 3.
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 lists all CodePic diagram templates. It distinguishes from siblings by specifying it should only be used when the user explicitly asks to browse/list templates, not as a preparatory step for other tools.
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 when-to-use (user asks to browse, list, or pick templates) and when-not-to-use (user describes a diagram they want, go to create_diagram). Also mentions that slug discovery is only meaningful before create_from_template.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_diagramUpdate DiagramAInspect
Update an existing CodePic diagram. You can rename it, replace all nodes/edges, or add/remove individual nodes and edges. Requires API Key authentication.
When responding to the user, present the returned URL as a clickable markdown link (e.g. [Open in CodePic →](URL)) so the user can click it directly in their AI client (Cursor / Claude / etc.).
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | New document name | |
| edges | No | Full replacement of all edges | |
| nodes | No | Full replacement of all nodes. If provided, replaces the entire canvas content. | |
| addEdges | No | Edges to add | |
| addNodes | No | Nodes to add (without replacing existing ones) | |
| documentId | Yes | Document ID to update (from a previous create call) | |
| removeEdgeIds | No | IDs of edges to remove | |
| removeNodeIds | No | IDs of nodes to remove | |
| backgroundColor | No | New canvas background color |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and covers key behaviors: mutation (update, rename, replace/add/remove), authentication requirements, and instructs how to present the returned URL. However, it doesn't disclose idempotency or side effects beyond the described modifications.
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?
Two concise paragraphs: first describes core functionality, second adds user-facing output instruction. Every sentence is purposeful, no redundancy, and the key information is front-loaded.
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?
For a 9-parameter tool with no output schema, the description effectively explains update modes and authentication. However, it fails to describe what the tool returns (presumably a URL) and doesn't cover response structure. Minor gap for completeness.
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 the description adds significant value by explaining the distinction between `nodes` (full replacement) and `addNodes`/`removeNodeIds` (add/remove), referencing `documentId` from a previous create call, and providing the markdown link instruction. This goes beyond the schema 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 the action ('Update an existing CodePic diagram') and the resource, with specific operations like rename, replace nodes/edges, or add/remove individual elements. It distinguishes itself from sibling tools such as `create_diagram` and `get_diagram`.
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 mentions 'Requires API Key authentication' and implies use when modifying an existing diagram. While it doesn't explicitly state when not to use or compare with alternatives, the context from sibling tool names and the clear purpose provide adequate guidance.
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!