Skip to main content
Glama

List Architecture Diagrams

diagrams_list
Read-onlyIdempotent

List PlantUML and Mermaid diagram files in the project's diagrams directory. Filter by diagram type and page through results to find existing diagrams.

Instructions

List all PlantUML and Mermaid diagram files stored under the project's diagrams directory.

This tool scans the configured diagrams root recursively and returns every file with a recognized diagram extension (.puml, .plantuml, .mmd, .mermaid). It does NOT create, modify, or render diagrams — read-only.

Args:

  • type_filter ('plantuml' | 'mermaid' | 'all'): Restrict results to one diagram type (default: 'all')

  • offset (number, optional): Zero-based number of matching diagrams to skip (default: 0)

  • limit (number, optional): Maximum diagrams to return (1-500). Omit to return every remaining match

Returns: JSON with schema: { "diagrams_root": string, // absolute path being scanned "count": number, // number of diagrams in this page "total": number, // number of diagrams matching type_filter, before paging "offset": number, // effective offset of this page "limit": number, // effective limit of this page (requested limit, or remaining count when omitted) "has_more": boolean, // true when diagrams after this page remain "diagrams": [ { "relative_path": string, // path to use with diagrams_get / diagrams_update "type": "plantuml" | "mermaid", "title": string | null, // best-effort extracted title "size_bytes": number, "modified_at": string // ISO 8601 timestamp } ] }

Pagination is explicit: omitting offset/limit returns every match with has_more=false. Nothing is ever silently dropped — has_more tells the caller when to request the next page with offset=<offset+count>.

Examples:

  • Use when: "What diagrams exist for this project?" -> type_filter="all"

  • Use when: "Show me all the Mermaid diagrams" -> type_filter="mermaid"

  • Use when: "List diagrams ten at a time" -> limit=10, then offset=10 for the next page

  • Don't use when: You already know the exact path and just need its content (use diagrams_get instead)

Error Handling:

  • Returns an empty "diagrams" array if the diagrams directory doesn't exist yet or is empty (this is not an error)

  • Returns an empty page (count 0, has_more=false) when offset is past the end of the matches

  • Returns "Error: Invalid pagination: ..." if offset is negative/non-integer or limit is outside 1-500

  • Unexpected internal failures return a generic "Error: Unexpected internal error ..." with isError:true and are logged to stderr without source, paths, or secrets

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of diagrams to return (1-500). Omit to return every remaining match.
offsetNoZero-based number of matching diagrams to skip before the returned page (default: 0).
type_filterNoRestrict results to a single diagram type, or 'all' for both.all

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

The annotations already indicate readOnly, idempotent, and non-destructive behavior, and the description adds substantial context: recursive scanning, no create/modify/render side effects, explicit pagination semantics, empty-directory behavior, out-of-range offset behavior, and error message shapes. There is no contradiction with 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well-structured and front-loaded with the core purpose. Every section (args, return schema, pagination, examples, error handling) earns its place since there is no output schema or separate documentation to carry that information.

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

Completeness5/5

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 specifies the return JSON structure, pagination flags, field meanings, and error behavior. It also covers the main sibling-tool distinction and edge cases like empty directories and invalid offsets, 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.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, so the baseline is 3. The description adds value beyond the schema by explaining the pagination contract (has_more, offset=offset+count, nothing silently dropped) and giving concrete examples for using limit and offset together. It somewhat restates the schema defaults, which prevents a higher score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource: it scans the diagrams directory and lists PlantUML/Mermaid files. It also explicitly differentiates itself from siblings by stating it does NOT create, modify, or render diagrams, and by referring to diagrams_get when the exact path is already known.

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

Usage Guidelines5/5

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

The description gives concrete 'Use when' examples for all filters and pagination scenarios, and a 'Don't use when' case naming diagrams_get as the alternative. This is explicit routing guidance that leaves no ambiguity about when to select this tool over siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mohammad-emad-dev/diagrams-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server