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.2/5 across 6 of 6 tools scored.
Each tool has a clearly distinct purpose: creating diagrams (two methods), fetching diagram state, updating diagrams, listing templates, and fetching shape documentation. No overlap or ambiguity.
Mostly consistent snake_case verb_noun pattern. Minor deviation: 'create_from_template' includes a preposition, and 'get_shape_docs' uses an abbreviation. Still readable and predictable.
6 tools is well-scoped for a diagramming service. Each tool serves a necessary function without bloat or redundancy.
The tool set lacks delete and list-all-diagrams operations, which are significant gaps for full diagram lifecycle management. Agents cannot clean up or discover existing diagrams without external knowledge.
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.
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 requirement, output type (public view URL), and detailed behavioral rules for container nesting (parentId auto-conversion, group dragging). It does not mention rate limits, error handling, or idempotency, but covers many operational details that aid an AI agent.
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 somewhat long but well-structured with clear sections: purpose, authentication, container nesting (marked IMPORTANT), and design tips. Every sentence adds value with specific examples or rules. Minor redundancy in color tips could be reduced, but overall efficient for the 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, no output schema), the description covers essential usage patterns: container nesting, styling, and referencing get_shape_docs for further details. It does not describe error scenarios or the exact structure of the returned URL, but provides enough for an AI agent to use effectively. Missing a sample response or pagination note, but adequate.
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 baseline is 3. The description adds significant meaning beyond the schema: container nesting best practices, design tips with color palettes, and examples for node types and data fields. This compensates for the schema's compact descriptions, earning a 4.
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 custom CodePic hand-drawn style diagram by specifying nodes and edges.' This specifies the verb (create), resource (diagram), and style (hand-drawn custom). It distinguishes from sibling tools like create_from_template by emphasizing 'custom' and not mentioning templates. The authentication requirement and output URL are also stated, reducing ambiguity.
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 does not explicitly differentiate this tool from siblings. It mentions 'custom' but does not say 'use this when you want to create a diagram from scratch, not from a template.' The container nesting advice gives usage guidance within the tool, but no external comparison. Usage context is implied rather than direct.
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.
| 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 provided, so description carries full burden. It discloses authentication requirement and return values (public view URL and edit URL). Does not cover idempotency or rate limits, but key traits are addressed.
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 sentences: first states action and resource, second adds auth and output. No redundant 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?
No output schema, but description mentions return URLs, which is essential. Auth requirement is noted. Could mention error handling or limits, but covers primary needs.
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 description adds minimal value. It reiterates 'from predefined template' which relates to slug parameter but does not add new meaning beyond 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?
Description clearly states verb 'Create' and resource 'new CodePic diagram from a predefined template'. It distinguishes from sibling tools like create_diagram (likely creates from scratch) and list_templates (lists 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?
Mentions 'Requires API Key authentication' as prerequisite, implying secure usage context. Does not explicitly state when to use vs. create_diagram, but context from sibling names suggests template-based creation.
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 to discover template slugs before calling create_from_template.
| 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 are provided, so the description carries the full burden. It describes a read-only listing operation with no side effects, which is transparent enough. However, it could explicitly state that it is non-destructive or requires no special permissions.
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 earning its place: the first states the core purpose, the second provides a practical usage tip. No wasted words, 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 simple listing tool with one optional parameter, the description covers purpose and usage. It does not describe the return format (e.g., list of template objects with slugs), but the absence of an output schema makes this a minor gap.
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% and the single parameter 'category' is well-defined with an enum and description. The description adds workflow context ('template slugs') but does not add new semantic detail about the parameter 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's purpose ('List all available CodePic diagram templates') and specifies its role in the workflow ('Use this to discover template slugs before calling create_from_template'), distinguishing it from siblings.
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 explicitly advises when to use this tool (before create_from_template), providing clear context. It does not mention exclusions or alternatives, but the guidance is direct and useful.
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.
| 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 provided, the description bears full responsibility for behavioral disclosure. It mentions the need for API Key authentication and outlines the core operations (rename, replace, add/remove). However, it does not discuss potential side effects, idempotency, failure modes, or what happens when parameters are omitted, leaving some ambiguity.
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 two sentences that front-load the core purpose and actions. It avoids fluff and directly communicates the tool's capabilities. Minor room for improvement could include a more streamlined second sentence.
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 tool with 9 parameters and no output schema, the description covers the main operations (rename, replace, add/remove) and references get_shape_docs for node details. It provides sufficient context for an agent to understand the tool's purpose and capabilities, though the return value is not mentioned.
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?
Given 100% schema description coverage, the baseline is 3. The description summarizes parameter groups (rename, replace, add/remove) but does not add new meaning beyond what the schema already provides. It reiterates the parameter purposes without deeper semantic enrichment.
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 'Update an existing CodePic diagram' and lists specific actions: rename, replace all nodes/edges, add/remove individual nodes/edges. It effectively distinguishes the tool from siblings like create_diagram and get_diagram by focusing on modification of existing diagrams.
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 implies usage context ('Update an existing diagram') but does not explicitly state when to prefer this tool over alternatives, nor does it provide exclusions or conditions. While the intended use is clear, the lack of explicit guidance on tool selection reduces the score.
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!