Diagrams MCP
Server Details
Generate cloud architecture diagrams, flowcharts, and sequence diagrams.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- ByteOverDev/diagrams-mcp
- GitHub Stars
- 2
- Server Listing
- diagrams-mcp
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 9 of 9 tools scored. Lowest: 3.7/5.
Each tool has a clearly distinct purpose with no ambiguity. The tools are well-separated into equivalence mapping (find_equivalent, list_categories), node browsing (list_providers, list_services, list_nodes, search_nodes), and diagram rendering (render_diagram, render_mermaid, render_plantuml). The descriptions clearly differentiate their functions, and there's no overlap in what they accomplish.
All tools follow a consistent verb_noun naming pattern using snake_case throughout. The verbs are appropriate and descriptive: 'find', 'list', 'render', and 'search' clearly indicate the action, while nouns like 'equivalent', 'categories', 'diagram', etc., specify the target. There are no deviations in naming conventions across the toolset.
With 9 tools, the count is well-scoped for a diagrams server covering equivalence mapping, node discovery, and multiple rendering backends. Each tool earns its place by addressing a specific need in the workflow, from exploring available nodes to generating diagrams in different formats, without being overly sparse or bloated.
The tool surface is complete for the domain of diagram generation and node management. It covers the full lifecycle: discovering nodes (list_providers, list_services, list_nodes, search_nodes), understanding equivalences (find_equivalent, list_categories), and rendering diagrams in multiple formats (render_diagram, render_mermaid, render_plantuml). There are no obvious gaps, and the tools work together seamlessly as described.
Available Tools
9 toolsfind_equivalentARead-onlyIdempotentInspect
Find cross-provider equivalents for a diagram node by infrastructure role.
Given a node name (e.g. 'EC2', 'Lambda', 'ComputeEngine'), returns the infrastructure role category it belongs to and the equivalent nodes from other providers.
If a node name is ambiguous, use list_categories to see all mapped roles and pick a provider-specific node name.
Args: node: Node class name to look up (case-insensitive, e.g. 'EC2', 'lambda'). target_provider: Optional provider to filter equivalents to (e.g. 'gcp', 'azure', 'aws'). If omitted, all equivalents across all other providers are returned.
Returns: A dict with keys: category (str): Infrastructure role category name. description (str): Human-readable description of the category. source (dict): The matched node with keys node, provider, service, import. equivalents (list[dict]): Equivalent nodes, each with keys node, provider, service, import.
| Name | Required | Description | Default |
|---|---|---|---|
| node | Yes | ||
| target_provider | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only and idempotent operations, which the description does not contradict. The description adds valuable context beyond annotations: it specifies case-insensitive node lookup, optional filtering by target_provider, and details on handling ambiguous inputs, enhancing behavioral understanding.
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 core purpose, followed by usage notes, parameter details, and return format. Every sentence adds value without redundancy, making it efficient and easy to parse.
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 0% schema coverage, the description is complete: it covers purpose, usage, parameters, and return values. With an output schema present, the detailed return format explanation is helpful but not strictly necessary, ensuring full contextual understanding.
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?
With 0% schema description coverage, the description fully compensates by explaining both parameters: 'node' as a case-insensitive class name with examples, and 'target_provider' as an optional filter with examples and default behavior. This adds essential meaning beyond the bare 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 with specific verbs ('Find cross-provider equivalents') and resources ('diagram node by infrastructure role'), distinguishing it from siblings like list_categories or search_nodes by focusing on equivalence mapping rather than listing or searching.
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 is provided: use this tool to find equivalents for a node name, and if ambiguous, use list_categories to resolve. It distinguishes when to use this tool versus alternatives, with clear sibling tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_categoriesARead-onlyIdempotentInspect
List all infrastructure role categories with their mapped nodes.
Use this to browse all available equivalence mappings, or to disambiguate node names when find_equivalent reports ambiguity.
Returns a list of category dicts, each with: category (str): Category identifier (e.g. 'virtual_machine'). description (str): Human-readable description. providers (list[str]): Providers covered by this category. nodes (dict): Mapping of provider → list of node names in that category.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating a safe, repeatable read operation. The description adds valuable context beyond annotations by specifying the return format (list of category dicts with detailed structure) and clarifying its purpose for browsing and disambiguation. It doesn't contradict annotations and provides useful behavioral details about output structure.
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 perfectly front-loaded with the core purpose in the first sentence, followed by usage guidelines and detailed return format. Every sentence earns its place by providing essential information without redundancy. The structure is logical and efficiently conveys all necessary information in minimal space.
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 (0 parameters, read-only/idempotent annotations, output schema exists), the description is complete. It explains the purpose, usage guidelines, and detailed return structure, which complements the annotations and output schema. No gaps remain for an agent to understand and invoke this tool correctly.
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?
With 0 parameters and 100% schema description coverage, the baseline would be 4. The description appropriately doesn't discuss parameters since none exist, and instead focuses on output semantics, which is valuable given the tool's purpose. It effectively compensates for the lack of input parameters by detailing what the tool returns.
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 specific action ('List all infrastructure role categories with their mapped nodes'), identifies the resource ('infrastructure role categories'), and distinguishes it from siblings by mentioning its use for browsing equivalence mappings or disambiguating node names when 'find_equivalent reports ambiguity'. This provides a precise verb+resource combination and explicit sibling differentiation.
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 states when to use this tool ('Use this to browse all available equivalence mappings, or to disambiguate node names when find_equivalent reports ambiguity'), naming a specific sibling alternative ('find_equivalent') and providing clear context for its application. This offers comprehensive guidance on usage scenarios versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_nodesARead-onlyIdempotentInspect
List available node classes for a provider.service combo.
Args: provider: Provider name (e.g. 'aws', 'gcp', 'k8s'). service: Service category (e.g. 'compute', 'database', 'network').
Returns: List of nodes with keys: name, import, alias_of (optional).
| Name | Required | Description | Default |
|---|---|---|---|
| service | Yes | ||
| provider | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating a safe, repeatable read operation. The description adds valuable context by specifying the return format ('List of nodes with keys: name, import, alias_of (optional)'), which is not covered by annotations. No contradictions exist.
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 front-loaded with the core purpose, followed by well-structured sections for Args and Returns. Every sentence adds value, with no redundant information, making it efficient and easy to parse.
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 (2 parameters, read-only/idempotent annotations, and an output schema), the description is complete. It covers purpose, parameters with examples, and return format, leaving no gaps for the agent to understand and invoke the tool correctly.
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?
With 0% schema description coverage, the description fully compensates by explaining both parameters: 'provider' as 'Provider name (e.g. 'aws', 'gcp', 'k8s')' and 'service' as 'Service category (e.g. 'compute', 'database', 'network')'. It provides clear examples and meaning beyond the bare 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 specific action ('List available node classes') and target resource ('for a provider.service combo'), distinguishing it from siblings like list_providers, list_services, and search_nodes. It precisely defines the scope of what is being listed.
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 by specifying the required parameters (provider and service), but does not explicitly state when to use this tool versus alternatives like list_categories, list_providers, or search_nodes. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_providersARead-onlyIdempotentInspect
List all available diagram providers (aws, gcp, azure, k8s, onprem, etc.).
Use list_providers -> list_services -> list_nodes to browse available node types for a specific provider.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating safe, non-destructive operations. The description adds valuable context by specifying that it lists 'all available' providers and hints at a hierarchical browsing workflow, though it doesn't detail response format or pagination. No contradiction with annotations exists.
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 highly concise and well-structured: the first sentence states the purpose with examples, and the second provides clear usage guidance. Every sentence adds value without unnecessary details, making it easy to scan and understand.
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 (0 parameters, read-only/idempotent annotations, and an output schema), the description is complete. It explains what the tool does, how to use it in context, and references sibling tools, covering all necessary aspects without needing to detail outputs or parameters.
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?
With 0 parameters and 100% schema description coverage, the baseline is 4. The description reinforces this by not mentioning any parameters, which is appropriate and avoids redundancy. It focuses instead on the tool's purpose and usage context.
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 verb ('List') and resource ('all available diagram providers'), providing specific examples (aws, gcp, azure, k8s, onprem, etc.). It effectively distinguishes this tool from siblings like list_services and list_nodes by focusing on providers rather than services or nodes.
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 provides usage guidance by stating 'Use list_providers -> list_services -> list_nodes to browse available node types for a specific provider.' This outlines a workflow and positions this tool as the first step in a sequence, clearly differentiating it from alternatives like list_categories or search_nodes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_servicesARead-onlyIdempotentInspect
List service categories for a provider (e.g. 'aws' -> ['compute', 'database', ...]).
Args: provider: Provider name from list_providers (e.g. 'aws', 'gcp', 'k8s').
| Name | Required | Description | Default |
|---|---|---|---|
| provider | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating safe, repeatable operations. The description adds context about the provider parameter and example output format, but doesn't disclose additional behavioral traits like rate limits, error handling, or pagination. 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 front-loaded with the core purpose, followed by a clear 'Args:' section. Every sentence earns its place by providing essential information without redundancy, making it 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 the tool's low complexity (one parameter), annotations covering safety, and an output schema (which handles return values), the description is complete enough. It explains the input semantics and purpose, though it could benefit from more sibling differentiation or usage 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 0%, so the description carries the full burden. It adds meaning by explaining the 'provider' parameter as 'Provider name from list_providers' with examples ('aws', 'gcp', 'k8s'), which clarifies usage beyond the bare schema. With only one parameter, this is sufficient for a high score.
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 service categories for a provider' with a specific example. It distinguishes from siblings like 'list_providers' by focusing on categories, but doesn't explicitly differentiate from 'list_categories' which might be similar.
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 by referencing 'provider name from list_providers', suggesting a workflow dependency. However, it doesn't explicitly state when to use this tool versus alternatives like 'list_categories' or 'search_nodes', nor does it provide exclusions or clear context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
render_diagramARead-onlyInspect
Render a mingrammer/diagrams Python snippet to PNG and return the image.
The code must be a complete Python script using from diagrams import ... imports
and a with Diagram(...) context manager block.
Use search_nodes to verify node names and get correct import paths before writing code. Read the diagrams://reference/diagram, diagrams://reference/edge, and diagrams://reference/cluster resources for constructor options and usage examples.
Args:
code: Full Python code using the diagrams library.
filename: Output filename without extension.
format: Output format — "png" (default), "svg", or "pdf".
download_link: If True, return a temporary download URL path
(/images/{token}) that expires after 15 minutes; if
False, return inline image bytes. Defaults to True
(URL) — set DIAGRAMS_INLINE_DEFAULT=true on the
server to flip the default. SVG/PDF and PNGs larger
than the inline limit always use a download link.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| format | No | png | |
| filename | No | diagram | |
| download_link | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. The description adds details about output format options, download link behavior (including expiration and inline limit), and default switching via server config, which are behavioral traits beyond the annotation.
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 starts with a concise purpose sentence, followed by prerequisites and parameter details. Every sentence adds value without redundancy, and the structure is logical and easy to scan.
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 covers return format (image bytes or URL) and expiration. However, it could be more explicit about the exact return type (e.g., base64 bytes or a URL string) and any size limitations beyond the inline limit mention.
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 input schema has 0% description coverage, so the description bears full burden. It thoroughly explains each parameter: code (full script requirement), filename (default extension), format (enum with defaults), and download_link (default, behavior differences, and server-side override).
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 renders a mingrammer/diagrams Python snippet to PNG and returns the image. This specific verb-resource pairing distinguishes it from sibling tools like render_plantuml and render_mermaid.
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 usage context by advising to use search_nodes for node verification and to read reference resources. However, it lacks explicit when-not or comparative guidance against sibling tools, though the distinction is implicit by the library-specific focus.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
render_mermaidARead-onlyInspect
Render a Mermaid diagram definition and return the image with metadata.
The definition should be valid Mermaid syntax (e.g. flowchart, sequence, class, ER, state, or Gantt diagram).
Returns a list of content blocks: the rendered image plus a JSON text block with metadata including a mermaid.live edit link for opening the diagram in a browser editor.
Args:
definition: Mermaid diagram definition text.
filename: Output filename without extension.
format: Output format — "png" (default), "svg", or "pdf".
download_link: If True, return a temporary download URL path
(/images/{token}) that expires after 15 minutes; if
False, return inline image bytes. Defaults to True
(URL) — set DIAGRAMS_INLINE_DEFAULT=true on the
server to flip the default. SVG/PDF and PNGs larger
than the inline limit always use a download link.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | png | |
| filename | No | diagram | |
| definition | Yes | ||
| download_link | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true. Description adds details on return format (content blocks), download_link behavior (expiry, inline vs URL, server env var), and metadata. 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?
Concise yet comprehensive. Front-loaded with purpose, then parameter details. Every sentence adds value, no repetition.
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 covers return value (content blocks with image and metadata, edit link). Complete for a rendering tool with 4 parameters.
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 0%, but description fully explains each parameter: definition syntax, filename, format options, and download_link default and override. Provides context beyond 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?
Clearly states it renders a Mermaid diagram definition, distinguishing it from siblings like render_plantuml and render_diagram. Uses specific verb 'render' and specifies resource type.
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?
Explains valid diagram types and when to use. Lacks explicit when-not-to-use or comparison with siblings, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
render_plantumlARead-onlyInspect
Render a PlantUML diagram definition and return the image.
The definition should be valid PlantUML syntax wrapped in @startuml/@enduml (sequence, class, component, activity, state, deployment, etc.).
Args:
definition: PlantUML diagram definition text.
filename: Output filename without extension.
format: Output format — "png" (default) or "svg".
PDF is not supported (requires Batik/FOP).
download_link: If True, return a temporary download URL path
(/images/{token}) that expires after 15 minutes; if
False, return inline image bytes. Defaults to True
(URL) — set DIAGRAMS_INLINE_DEFAULT=true on the
server to flip the default. SVG and PNGs larger than
the inline limit always use a download link.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | png | |
| filename | No | diagram | |
| definition | Yes | ||
| download_link | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=true. Description adds valuable details: download_link expiration, inline vs download behavior, size limits, and that PDF is not supported. These go 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?
Well-structured with purpose first, then parameter descriptions in a clear list. Slightly verbose but each sentence adds value. Could be tightened.
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 explains return behavior (image URL with expiry or inline bytes) and size limits. Covers format constraints and default behavior. Lacks explicit return type, but sufficient for most use cases.
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 has 0% description coverage, so description fully explains all four parameters: definition (PlantUML syntax), filename, format (with caveat that PDF is unsupported), download_link (null defaults to URL behavior, env var to override). Adds critical meaning absent from 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?
Clearly states 'Render a PlantUML diagram definition and return the image', specifying both the action and resource. Distinguishes from sibling tools like render_mermaid by naming PlantUML.
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?
Implies usage for rendering PlantUML diagrams, but lacks explicit guidance on when to choose this tool over siblings like render_diagram or render_mermaid. Does not state prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_nodesARead-onlyIdempotentInspect
Search for diagram nodes by keyword across all providers and services.
For targeted browsing when you know the provider, use list_providers -> list_services -> list_nodes instead.
Args: query: Search term (case-insensitive substring match).
Returns: List of matching nodes with keys: node, provider, service, import, alias_of (optional). Sorted by relevance: exact match first, then prefix, then substring.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true and idempotentHint=true, indicating safe, repeatable operations. The description adds valuable behavioral context beyond annotations: it specifies the search scope ('across all providers and services'), matching behavior ('case-insensitive substring match'), and sorting logic ('exact match first, then prefix, then substring'). No contradictions 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 well-structured and front-loaded with the core purpose, followed by usage guidelines, parameter details, and return format. Every sentence adds value without redundancy, making it efficient and easy to parse.
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 moderate complexity (1 parameter, read-only/idempotent annotations, output schema exists), the description is complete. It covers purpose, usage, parameter semantics, and return format, with the output schema handling return values. No gaps are evident for effective agent use.
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 0%, so the description carries full burden. It clearly explains the single parameter 'query' as a 'Search term (case-insensitive substring match)', adding meaningful semantics about case sensitivity and matching type that aren't in the schema. This compensates well for the schema gap.
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 specific action ('Search for diagram nodes by keyword') and resource ('across all providers and services'), distinguishing it from sibling tools like list_nodes which presumably lists nodes within a specific service. It uses precise verbs and scope.
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 provides when to use this tool ('Search for diagram nodes by keyword across all providers and services') and when not to ('For targeted browsing when you know the provider, use list_providers -> list_services -> list_nodes instead'), naming the alternative workflow. This gives clear guidance on tool selection.
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!
Your Connectors
Sign in to create a connector for this server.