AI Diagram Maker MCP Server

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 successfully discloses input handling capabilities (box-drawing characters, arrows) and explicitly states the output behavior ('Returns a link to view and edit'), compensating for the lack of 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?

Four well-structured sentences: purpose statement, usage condition, input format specifications, and output description. Every sentence earns its place with no redundancy or filler content.

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 100% schema coverage and no output schema, the description appropriately covers the tool's purpose, usage context, input expectations, and return value. Lacks only minor behavioral details like rate limits or link expiration that would be needed for a perfect score without annotations.

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 the schema already documents all parameters comprehensively. The description adds general context about accepted input formats (box-drawing, arrows) but does not add significant semantic detail beyond the schema's parameter descriptions.

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

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

The description uses specific verbs ('Convert') and clearly identifies the resource (ASCII art diagram). It specifically mentions 'ASCII art' twice, clearly distinguishing it from sibling tools that handle JSON, images, Mermaid, or plain text inputs.

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

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

Provides explicit when-to-use guidance ('Use this tool when the user has an existing ASCII art representation...'). However, it does not explicitly name alternative sibling tools for non-ASCII inputs or provide explicit when-not-to-use exclusions.

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

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

Without annotations, the description carries full burden. It successfully discloses input format constraints (public URLs or base64 data URIs) and critical output behavior (returns a link to view and edit). Could improve by mentioning error conditions for unsupported image content or data retention policies.

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 well-structured sentences: purpose statement (front-loaded), usage condition, and technical I/O details. Zero redundancy. Each sentence earns its place without repeating schema fields.

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 exists, the description appropriately explains the return value (link to view/edit). Combined with 100% schema coverage and clear behavioral constraints, the description is complete for this tool's complexity level.

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%, establishing baseline 3. The description adds contextual examples for content parameter (whiteboard, screenshot, sketch) and reinforces the base64 format syntax, but does not add semantic meaning beyond what the well-documented schema already provides.

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 the specific verb 'Convert' with clear resource 'image' (subtyped as whiteboard photo, screenshot, hand-drawn sketch) into 'clean diagram'. The suffix 'from_image' combined with siblings 'from_ascii/json/mermaid/text' provides clear differentiation from alternatives.

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 'Use this tool when the user provides an image URL or base64-encoded image and wants it converted to a proper software engineering diagram,' giving clear positive context. Lacks explicit 'when not to use' or named sibling alternatives, preventing a 5.

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

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

No annotations are provided, so the description carries the full disclosure burden. It adds critical behavioral context that it 'Returns a link to view and edit the generated diagram in the browser' rather than returning raw image data. However, it omits mutation characteristics (whether diagrams persist, are public/private), error handling for malformed JSON, or rate limit implications for a generation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Four sentences structured logically: purpose statement, usage conditions, parameter instruction, and return value. Every sentence earns its place with zero redundancy. High information density without repetition of schema details (it references 'content' by name without redefining it). Front-loaded with the core action.

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?

Appropriately complete for a 4-parameter tool with no output schema. Compensates for missing output schema by explicitly stating the return behavior (browser link). Given the well-documented input schema, the description provides sufficient high-level context without needing to replicate parameter details or explain return schema fields.

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%, establishing a baseline of 3. The description adds specific usage guidance for the 'content' parameter ('Pass the raw JSON string as `content`'), reinforcing that a stringified representation is required. It does not elaborate on 'prompt' syntax, 'diagramType' selection logic, or 'isIconEnabled' behavior beyond the schema definitions.

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

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

The description opens with the specific action 'Generate a diagram from a JSON structure', clearly identifying both the verb (generate) and resource (JSON structure). It effectively distinguishes from siblings (generate_diagram_from_text, _ascii, etc.) by enumerating specific JSON use cases like 'API responses, database schemas, dependency trees' that uniquely signal this tool's domain.

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

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

Provides clear positive guidance: 'Use this tool when the user wants to visualise JSON data such as...' followed by concrete examples. This enables correct selection when JSON is present. Lacks explicit negative constraints or direct comparison to sibling alternatives (e.g., 'use generate_diagram_from_text for natural language instead'), but the input specificity makes the boundary clear.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully explains the conversion process (Mermaid to D2), output format (PNG), and return value (link to view/edit in browser). This covers the essential behavioral traits, though it omits error handling details for invalid Mermaid syntax.

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 four-sentence structure is efficiently front-loaded: sentence 1 defines the action, sentence 2 specifies usage context, sentence 3 indicates parameter mapping, and sentence 4 explains return values. Zero redundancy; every sentence earns its place.

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 has 4 parameters with 100% schema coverage and no output schema, the description adequately compensates by explaining what the tool returns (PNG image and browser link). It covers purpose, usage, parameters, and returns sufficiently for a conversion tool, though error handling details are absent.

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%, meaning the schema fully documents all four parameters (content, prompt, diagramType, isIconEnabled). The description adds minimal semantic value beyond the schema by explicitly mapping 'Mermaid source' to the 'content' parameter, but otherwise relies on the schema's comprehensive documentation.

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 specific verbs ('Convert') and resources ('Mermaid diagram definition', 'D2 diagram', 'PNG image') to clearly state the transformation. It explicitly distinguishes from siblings by specifying Mermaid source as input, immediately signaling this is for Mermaid-to-D2 conversion rather than ASCII, JSON, or text inputs.

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

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

The description provides explicit when-to-use guidance ('when the user has existing Mermaid code... and wants it converted'). It implicitly distinguishes from siblings by specifying the Mermaid input type, though it does not explicitly name sibling tools or provide negative constraints (when NOT to use).

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

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

With no annotations provided, the description carries full burden and explicitly discloses: 'Returns a link to view and edit the generated diagram in the browser.' This reveals output format (URL), persistence (editable), and access method. Could be improved with failure mode or rate limit disclosure, but covers essential behavioral traits.

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-sentence structure logically flows: purpose → usage triggers → supported types/output. Information-dense but well front-loaded. The 'Use this tool when' sentence is lengthy but necessary for the comprehensive trigger list.

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?

Appropriately complete for a 4-parameter generation tool with no output schema or annotations. Compensates for missing output schema by describing return behavior (link), and provides sufficient context for parameter usage despite relying on schema for parameter specifics.

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%, establishing baseline 3. Description lists supported diagram types (flowchart, sequence, etc.) which reinforces the enum in schema but adds no new parameter constraints or usage patterns beyond schema definitions.

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

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

Description explicitly states 'Generate a software engineering diagram from a natural language description' — specific verb (Generate), resource (diagram), and input modality (natural language description). This effectively distinguishes it from siblings that accept ASCII, JSON, Mermaid, or image inputs.

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

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

Provides explicit 'Use this tool when:' triggers including specific phrases ('create a diagram', 'show me a flowchart'), keywords ('adm', 'ai diagram maker'), and intent indicators ('visual representation of code, systems, processes'). Lacks explicit 'when not to use' or sibling alternative references, but input modality provides implicit differentiation.

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