Generate cloud architecture diagrams, flowcharts, and sequence diagrams.
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.
Average 4.6/5 across 9 of 9 tools scored.
Each tool serves a distinct purpose: browsing (list_providers, list_services, list_nodes, search_nodes), equivalence lookup (find_equivalent, list_categories), and rendering in three different syntaxes (render_diagram, render_mermaid, render_plantuml). No two tools overlap in function, and descriptions clearly differentiate when to use each.
All tool names follow a consistent verb_noun pattern with lowercase snake_case: list_* for browsing, render_* for output generation, find_equivalent, and search_nodes. The pattern is predictable and aids agent understanding.
With 9 tools, the server is well-scoped: 4 browsing tools, 2 equivalence tools, and 3 rendering tools cover the diagram creation workflow without bloat. Each tool earns its place.
The tool surface supports the full workflow: discover providers/services/nodes, search for equivalent roles, and render diagrams in Python, Mermaid, or PlantUML. No obvious gaps exist for the stated purpose.
find_equivalentAFind 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 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint. The description adds valuable behavioral context: case-insensitive matching, default behavior when target_provider is omitted, and the exact structure of the returned dictionary. It does not contradict the 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-organized with clear sections (purpose, ambiguity note, Args, Returns). Every sentence adds useful information without redundancy. It is appropriately sized 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?
Despite the tool having an output schema, the description provides a thorough explanation of inputs, outputs, and edge cases. It covers all necessary context for an agent to invoke the tool correctly, including optional filtering and return structure.
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 the 'node' parameter with examples and case-insensitivity, and the 'target_provider' parameter with valid values and default behavior. This adds meaning well beyond the raw 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: 'Find cross-provider equivalents for a diagram node by infrastructure role.' It uses a specific verb and resource, and it distinguishes itself from the sibling list_categories by providing equivalents rather than just categories.
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 gives explicit usage guidance: it explains when to use the tool (to get equivalents) and provides an alternative when names are ambiguous ('use list_categories to see all mapped roles and pick a provider-specific node name'). It also clarifies the optional target_provider filter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_categoriesAList 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 | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds value by explaining the return structure in detail (category, description, providers, nodes) and the specific use case of disambiguation. This goes beyond what annotations provide, though it doesn't mention potential real-world behaviors like ordering or error cases, which are likely minimal for a list 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?
The description is well-structured: it opens with the core purpose, then provides usage guidance, and finishes with a detailed return format. It is slightly longer than necessary, but the return format list is valuable and the formatting makes it scannable. Every sentence contributes meaning.
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?
Despite having an output schema, the description still explains the return format, which is helpful. It covers purpose, usage, and output details, and references a sibling for disambiguation. For a zero-parameter, read-only listing tool, the description is complete and leaves no obvious gaps.
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 tool has zero parameters, so the baseline is 4. The description doesn't need to explain parameters, and the schema is empty. The description adds contextual semantics about the output, which compensates for the lack of parameters to describe.
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 infrastructure role categories with their mapped nodes.' It uses a specific verb ('List') and resource ('infrastructure role categories'), and distinguishes itself from siblings by mentioning equivalence mappings and its role in disambiguating node names when find_equivalent reports 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 explicitly states when to use the tool: 'Use this to browse all available equivalence mappings, or to disambiguate node names when find_equivalent reports ambiguity.' It provides clear context and references a specific sibling (find_equivalent), giving the agent actionable guidance on selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_nodesAList 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 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description isn't burdened with safety disclosure. It adds value by documenting the return structure ('List of nodes with keys: name, import, alias_of (optional)') and giving concrete examples for both parameters. This is richer than the TDQS 3 baseline for annotated tools, though it stops short of covering edge cases or error behavior.
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 compact and well-structured: a one-sentence purpose statement, an Args list, and a Returns list. Every sentence conveys necessary information with no filler or repetition of the schema. The front-loaded main clause immediately tells the agent what the tool does.
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 required params, no enums, no nested objects), the description covers all essentials: what it lists, how to specify provider/service, and what the return looks like. The sibling context is addressed through the explicit 'node classes' scope. There's no missing information that would leave an agent guessing.
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%, yet the description fully compensates by explaining each parameter with type, examples, and meaning: 'provider: Provider name (e.g. 'aws', 'gcp', 'k8s')' and 'service: Service category (e.g. 'compute', 'database', 'network')'. This transforms what would be bare strings into actionable guidance, exceeding the baseline required for low coverage.
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 starts with a specific verb+resource+scope: 'List available node classes for a provider.service combo.' This clearly distinguishes it from sibling tools like list_providers, list_services, and list_categories, which focus on other entity types. The phrase 'node classes' also clarifies the output granularity.
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 when to use this tool by specifying the 'provider.service combo' scope and listing examples, but it does not explicitly name alternative tools or state when not to use it. That said, the context is clear enough that an agent can infer usage, so it earns a 4 rather than a 3.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_providersAList 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 | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No contradiction with the readOnlyHint and idempotentHint annotations; the description reinforces a safe read operation. It adds the workflow context and the 'all available' scope, but does not disclose further behavioral traits such as response format or ordering, though that burden is reduced given the annotations and output schema.
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, front-loaded with the core purpose followed by a helpful usage chain. No redundant phrasing or filler, earning a top score.
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 zero-parameter signature, strong annotations (read-only, idempotent), presence of an output schema, and a concise workflow hint, the description provides all necessary context for an agent to select and invoke this tool safely. No significant gaps remain.
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 tool takes zero parameters, and the schema is fully self-contained with no description coverage needed. Since there are no inputs to explain, the description's silence on parameters is appropriate; baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'List all available diagram providers,' which clearly states the action (list) and resource (diagram providers) with concrete examples. It distinguishes this tool from siblings like list_nodes and list_services by establishing the provider-level scope and the browsing chain. This is a specific, non-tautological purpose statement.
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 a navigation path: 'Use list_providers -> list_services -> list_nodes to browse available node types for a specific provider.' This tells the agent when to invoke this tool (as the entry point) and how it fits with related tools, though it does not state exclusions or when to prefer list_categories.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_servicesAList 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 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, covering the safety profile. The description adds value by showing a sample return format and the dependency on list_providers, providing behavioral context beyond the 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 extremely concise—two sentences plus an Args line—with the core purpose front-loaded. Every element (purpose, example, parameter documentation) earns its place, and there is no wasted wording.
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 tool with one parameter and an output schema present, the description covers the tool's purpose, the parameter's provenance, and the expected output format via example. This is sufficient for an agent to select 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?
The input schema only specifies 'provider' as a string with 0% description coverage, but the description fully documents the parameter: it explains what the value represents (provider name), where to obtain it (list_providers), and gives example values ('aws', 'gcp', 'k8s'). This completely compensates 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 tool lists service categories for a provider, with a concrete example ('aws' -> ['compute', 'database', ...]). However, it does not explicitly distinguish from the sibling tool 'list_categories', so the distinction is implicit.
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 after list_providers by specifying that the provider name comes from list_providers, which is a useful prerequisite. However, it offers no explicit guidance on when not to use the tool or mentions any alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
render_diagramARender 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses critical behavior: the code must be a complete script with a context manager, output format options and defaults, and the download_link behavior including expiration and size limits. This extra context helps the agent anticipate side effects and output characteristics.
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 a concise opening, a prerequisite paragraph, and a clear Args list. Every sentence provides necessary information; no filler. It is appropriately sized for a tool with 4 parameters and no schema descriptions.
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 lack of an output schema, the description adequately explains return values (inline bytes vs. download URL) and includes references for construction options. It covers prerequisites, defaults, and edge cases (SVG/PDF always use download link), making it complete for an agent to invoke 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?
Despite 0% schema description coverage, the Args section fully explains each parameter: code (complete Python script), filename (no extension), format (enum with default), and download_link (behavior, default, env-var override). This adds significant meaning beyond the raw 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 opens with a specific verb+resource: 'Render a mingrammer/diagrams Python snippet to PNG and return the image.' This clearly distinguishes it from sibling render tools like render_mermaid and render_plantuml by specifying the exact library and output format.
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 clear guidance on prerequisites ('must be a complete Python script using from diagrams import ...'), suggests using search_nodes to verify node names, and points to reference resources. It does not explicitly state when NOT to use this tool versus alternatives, but the context is clear from the library-specific wording.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
render_mermaidARender 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=true, but the description adds substantial behavioral detail: it returns a list of content blocks (image + JSON metadata), includes a mermaid.live edit link, explains the download_link parameter's default behavior, the temporary URL expiry (15 minutes), inline image bytes alternative, and the environment variable that flips the default. 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 well-structured with a clear opening summary followed by a detailed Args section, but it is somewhat lengthy. While every sentence adds useful information, the env var configuration detail and the inline limit could be seen as extra; however, they contribute to completeness. It is not overly verbose, but not as tightly concise as the two-sentence get_calls example.
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 four parameters, no output schema, and no nested objects, the description covers everything needed: the return format (content blocks with metadata), parameter defaults and alternatives, and the download_link behavior. It even mentions edge cases (SVG/PDF always use download link). The description is fully adequate for an agent to invoke the tool correctly without further 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%, and the description fully compensates by explaining each parameter: definition (diagram text), filename (output filename without extension), format (png/svg/pdf with default), and download_link (boolean, default behavior, and inline vs URL logic). This goes far beyond the schema's property names and types.
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 Mermaid diagram definition and returns the image with metadata. It specifies the resource (Mermaid diagram) and the verb (render), and the mention of Mermaid syntax (flowchart, sequence, etc.) distinguishes it from siblings like render_plantuml and render_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 clearly indicates the tool is for rendering Mermaid diagrams and lists supported diagram types, implying it is the right choice for Mermaid definitions. It does not explicitly mention alternatives or exclusions, but the context is sufficient for an agent to select it over render_plantuml or render_diagram.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
render_plantumlARender 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses download link expiration (15 minutes), inline vs. download behavior, default download_link value, and server-side environment variable influence. This gives significant behavioral context, though it does not cover error handling.
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 purpose, uses a clean Args structure, and every sentence conveys necessary details without fluff. It is appropriately sized 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?
With no output schema, the description fully covers return formats (image bytes or download URL), defaults, and exceptions (inline limit). It provides enough information for an agent to invoke the tool correctly without ambiguity.
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?
Despite 0% schema description coverage, the Args section explains each parameter in detail, including format enum semantics (PDF unsupported) and download_link behavior (URL vs bytes, defaults, and server configuration).
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 opens with a clear verb+resource: 'Render a PlantUML diagram definition and return the image.' It also enumerates supported diagram types (sequence, class, component, activity, state, deployment), making it distinct from sibling 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 implies usage for PlantUML syntax (wrapped in @startuml/@enduml) but does not explicitly compare against sibling render_mermaid or render_diagram. It notes that PDF is unsupported, providing a limitation, but no alternative tool is suggested.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_nodesASearch 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 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses search behavior (case-insensitive substring match), result ordering (exact match, prefix, substring), and return keys. Annotations already cover read-only and idempotent hints, so this extra behavioral detail is valuable and not redundant.
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 for the main behavior, usage guidance, parameter, and return value. No sentence is wasted, and the length is appropriate for the information conveyed.
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 simple one-parameter tool, the description covers purpose, usage, parameter semantics, and return format. It is fully sufficient for an agent to select 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?
Schema coverage is 0%, so the description compensates fully by defining the query parameter as a 'case-insensitive substring match,' adding meaning beyond the bare string type in 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 uses a specific verb 'Search' and clearly identifies the resource ('diagram nodes') and scope ('across all providers and services'). It distinguishes itself from sibling tools like list_nodes by emphasizing cross-provider search.
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 states when to use an alternative: 'For targeted browsing when you know the provider, use list_providers -> list_services -> list_nodes instead.' This clearly contrasts the search tool with the targeted browsing workflow.
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.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.