YAMLTools
Server Details
MCP server for YAML: validate & lint, convert between 10 formats, visualize as diagrams, and create/edit your saved diagrams — from your AI editor.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.7/5 across 7 of 7 tools scored. Lowest: 3.1/5.
Each tool has a distinct and clear purpose: format conversion, diagram CRUD, validation, and visualization. No two tools overlap in functionality, making it easy for an agent to select the correct one.
All tools use a consistent snake_case verb_noun pattern (e.g., convert_yaml, create_diagram, validate_yaml). The naming is uniform and predictable.
With 7 tools, the set is well-scoped for YAML manipulation and diagram management. Each tool serves a necessary function without redundancy or excessive specialization.
The diagram tools cover create, read, list, and update but lack a delete_diagram tool, which is a notable gap for full lifecycle management. Otherwise, the set covers conversion, validation, and visualization adequately.
Available Tools
12 toolsconvert_yamlConvert YAMLAInspect
Convert between data formats (YAML, JSON, XML, TOML, TOON, CSV, TSV, INI, Properties, ENV). Source format is auto-detected by default; set from to force it.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Target format | |
| from | No | Source format. Omit to auto-detect from content. | |
| input | Yes | The content to convert |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. It discloses auto-detection behavior and ability to force format, but does not mention error handling, side effects, or return format. Adequate for a conversion tool but missing some details.
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, no unnecessary words. The primary action is front-loaded, making it immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only 3 parameters with no output schema. The description covers core functionality and configuration, but lacks details on output format, error behavior, or limitations. Sufficient for simple use but not fully comprehensive.
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% with descriptions for all 3 parameters. The description adds context about auto-detection, but does not significantly expand beyond what the schema already provides, resulting in baseline 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 converts between multiple data formats (YAML, JSON, XML, etc.), with auto-detection of source format. This distinguishes it from siblings like validate_yaml and visualize_yaml.
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 guidance on when to use the `from` parameter to force source format vs auto-detect. While not explicitly stating when not to use it, the sibling tools cover different use cases, making the conversion purpose clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_diagramCreate a diagramAInspect
Save a new diagram to the user's account. Returns its id and URL. May hit the free-plan limit (paywall). Requires a YAMLTools API key.
| Name | Required | Description | Default |
|---|---|---|---|
| yaml | Yes | YAML source to save | |
| title | No | Diagram title | |
| diagramType | No | Diagram type | TREE |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses return values (id, URL), potential paywall hit, and API key requirement. This is good behavioral context for a creation tool, though it does not mention potential duplicates 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?
Two concise sentences convey all necessary information without redundancy. Every sentence earns its place, providing purpose, return values, and constraints efficiently.
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 and no annotations, the description adequately covers return values (id, URL), constraints (free-plan, API key), and the act of creation. It could mention optional parameters, but the schema already covers that. Overall complete for a straightforward creation tool.
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% with descriptions for all three parameters. The tool description adds no additional semantic information beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Save a new diagram to the user's account', specifying the verb and resource. It distinguishes from siblings like update_diagram and get_diagram by indicating creation of a new resource.
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 context such as free-plan limit and API key requirement, which are prerequisites, but does not explicitly guide when to use this tool versus alternatives like validate_yaml or convert_yaml. Siblings are listed but no comparative guidance given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_folderCreate a folderAInspect
Create a Drive folder to organize diagrams. Folders are a Pro feature. Requires a YAMLTools API key.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Folder name | |
| parentFolderId | No | Parent folder id; omit to create at the Drive root |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description reveals permission constraints (Pro feature, API key) but does not discuss rate limits, idempotency, or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, each adding value: purpose, prerequisite, requirement. No unnecessary words.
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 simple creation tool, covers purpose, preconditions, and parameters. Lacks success response details but acceptable for a straightforward action.
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 schema already documents parameters. Description does not add extra meaning beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'create', resource 'Drive folder', and purpose 'organize diagrams'. Distinguishes from sibling tools which deal with diagrams, not folders.
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?
States preconditions: Pro feature and API key required. Provides context for when to use, though does not explicitly mention when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_diagramDelete a diagramAInspect
Permanently delete one of the user's diagrams by id. Requires a YAMLTools API key.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Diagram id to delete |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions 'permanently delete', indicating destructive and irreversible behavior. However, with no annotations provided, more details about side effects or recovery options would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no redundancy. Every part serves a purpose: what, how, and prereq.
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 1-param tool with no output schema, the description covers the action and auth requirement. It does not elaborate on return behavior, but that is acceptable given the simplicity.
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 100% description coverage for the 'id' parameter, so the description adds no extra meaning. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'permanently delete one of the user's diagrams by id', providing a specific verb and resource, and distinguishing from sibling tools like create_diagram and update_diagram.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as move_diagram or update_diagram. The only context is the API key requirement, which is authentication, not usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_diagramGet a diagramAInspect
Fetch one of the user's diagrams by id, returning its YAML source and metadata. Requires a YAMLTools API key.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Diagram id |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It reveals the action (fetch), input (id), and output (YAML source and metadata), plus the auth requirement. However, it omits details like error handling, rate limits, or size constraints.
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-load the core action and output, with no unnecessary words. Every sentence adds value.
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 tool (1 parameter, no output schema, low complexity), the description is mostly complete. It covers action, input, output, and auth. It could mention that it returns a single diagram, but that is implied.
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 schema already fully describes the single parameter 'id' with a description. The description adds no additional meaning, matching the baseline for 100% schema 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 clearly states the verb 'Fetch' and the resource 'one of the user's diagrams by id', with specific output 'YAML source and metadata'. This distinguishes it from siblings like list_diagrams (which returns all diagrams) and create_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 mentions a prerequisite (YAMLTools API key) but does not explicitly state when to use this tool vs alternatives like list_diagrams or update_diagram. Usage context is implied but not clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_diagramsList my diagramsAInspect
List the authenticated user's saved diagrams (id, title, type, visibility, updatedAt). Requires a YAMLTools API key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the basic operation and auth requirement, but does not disclose behavior such as pagination, sorting, limits, or whether it returns all diagrams. Essential behavioral traits are missing.
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 a single sentence that immediately states the purpose and lists the returned fields, followed by the auth requirement. It is extremely concise with no unnecessary words, making it easy to parse quickly.
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 list tool with no parameters and no output schema, the description is adequate but not complete. It lacks details on whether results are paginated, sorted, or limited. The returned fields are listed, but context like ordering or maximum results is missing.
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?
There are no parameters (0 required, 0 optional), and schema description coverage is 100%. The description adds no parameter details, but that is appropriate because no input parameters exist. The baseline score for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'the authenticated user's saved diagrams', and specifies the returned fields (id, title, type, visibility, updatedAt). This distinguishes it from sibling tools like get_diagram (single diagram) and create_diagram (creation).
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 mentions the prerequisite of a YAMLTools API key, which is helpful, but it does not provide guidance on when to use this tool versus alternatives (e.g., use get_diagram for a specific diagram, create_diagram for creating). No when-not-to-use context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_foldersList my foldersAInspect
List the user's Drive folders (id, name, parentFolderId). Requires a YAMLTools API key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions API key requirement but does not explicitly state read-only behavior or other side effects. Minimal behavioral info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. Key information (list, fields, auth) is front-loaded and efficient.
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, parameterless list tool, description covers purpose, return fields, and auth requirements. No output schema needed as return values are described inline.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist (0 params, 100% schema coverage), so baseline is 4. Description does not need to add parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists the user's Drive folders and specifies the fields returned (id, name, parentFolderId). Distinguishes from sibling tools like create_folder and list_diagrams.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like search_diagrams or list_diagrams. Lacks context on filtering or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
move_diagramMove a diagramBInspect
Move one of the user's diagrams into a folder, or to the Drive root (folderId = null). Requires a YAMLTools API key.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Diagram id to move | |
| folderId | Yes | Destination folder id, or null for the Drive root |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only mentions the API key requirement but lacks details on side effects, reversibility, or permissions. With no annotations, the description carries full burden but provides minimal transparency.
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 a single, efficient sentence that is front-loaded and clear. It could be slightly more structured but is sufficiently concise.
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 no output schema, the description covers the basic parameters and authentication requirement. However, it lacks information on success/failure outcomes or side effects, which would be useful for a mutation tool.
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 description adds no extra meaning beyond the schema. It restates that folderId can be null, which is already in the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (move) and the resource (diagram), specifying the two possible destinations (folder or root). It distinguishes from sibling tools like delete_diagram or create_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?
No guidance on when to use this tool versus alternatives. It does not mention when not to use it or provide comparisons to siblings like update_diagram.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_diagramsSearch my diagramsAInspect
Search the authenticated user's saved diagrams by title text. Returns matches with their folder. Requires a YAMLTools API key.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Text to match in the diagram title |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Clearly states it searches by title, returns matches and folder, and requires API key. Could mention case sensitivity or pagination but sufficient for a simple search.
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: one for purpose, one for requirement. Concise with no wasted words, though slightly more structure could improve readability.
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 single-parameter tool with no output schema, description covers purpose, return content, and authentication. Missing pagination info but not critical for this scope.
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 covers 100% with description 'Text to match in the diagram title'. Description adds only 'by title text' and return context, which is minimal. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool searches saved diagrams by title text and returns matches with folders. Distinguishes from list_diagrams (lists all) and get_diagram (by ID) among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Indicates its purpose (search by title) and requirement for API key. Does not explicitly compare to alternatives like list_diagrams, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_diagramUpdate a diagramBInspect
Update an existing diagram of the user (source, title and/or type) and save it. Requires a YAMLTools API key.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Diagram id to update | |
| yaml | No | New YAML source | |
| title | No | New title | |
| diagramType | No | New diagram type |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must fully disclose behavior. It only states it updates and saves, requiring an API key. It omits details like whether changes are overwritten or merged, error handling, and success/failure outcomes.
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 a single, clear sentence with no redundant phrases. It efficiently conveys the core functionality, though it could be slightly more 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 has 4 parameters and no output schema, the description lacks essential context such as expected return value, error conditions, and whether the diagram must exist. It is insufficient for an agent to use reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter has adequate schema documentation. The description groups parameters (source, title, type) but adds no new meaning beyond the schema's own 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 clearly states the action 'update' and the resource 'diagram', and lists the specific updatable attributes: source (yaml), title, and/or type. This effectively distinguishes the tool from sibling tools like create_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 only mentions a prerequisite (API key) but provides no guidance on when to use this tool versus alternatives. It does not specify when not to use it or suggest sibling tools for other tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_yamlValidate YAMLAInspect
Validate and lint a YAML document. Reports syntax errors with line/column, non-fatal lint warnings (tabs, implicit booleans, duplicate keys, dash-no-space) and document stats (documents, keys, max depth, bytes).
| Name | Required | Description | Default |
|---|---|---|---|
| yaml | Yes | The YAML content to validate |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behaviors: reports syntax errors with location, non-fatal lint warnings, and document stats. This sufficiently informs an agent of expected outputs and constraints.
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 a single, well-structured sentence that front-loads the core purpose and lists specific outputs. Every part adds value without redundancy.
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?
While the description covers the input and general output, it lacks explicit detail on the return format or structure. With no output schema, the agent may need to infer the response shape. Somewhat incomplete.
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 single parameter is fully described in the schema (100% coverage). The description adds no additional meaning beyond what the schema already provides for the 'yaml' parameter. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it validates and lints a YAML document, and specifies what it reports (syntax errors, lint warnings, stats). It effectively distinguishes from sibling tools like convert_yaml or visualize_yaml.
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?
No explicit when-to-use or when-not-to-use guidance is given. Usage is implied from the tool's purpose, but alternatives are not mentioned. The description could benefit from stating when validation is preferable over conversion or visualization.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
visualize_yamlVisualize YAMLBInspect
Turn YAML into a diagram. Returns Mermaid source; with an API key it also returns a public image hosted on yamltools.dev. Supports TREE (hierarchy) and FLOW (flowchart).
| Name | Required | Description | Default |
|---|---|---|---|
| yaml | Yes | The YAML content to visualize | |
| format | No | Output image format | svg |
| diagramType | No | TREE for hierarchy, FLOW for flowchart | TREE |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavior. It does mention return types (Mermaid source, optional image) and diagram type support, but omits error handling, prerequisites, or security context. Adequate but not comprehensive.
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?
Extremely concise: two sentences (effectively three clauses) that cover purpose, return value, and options. No wasted words, and the most important function is stated first.
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 3 parameters (all with schema descriptions) and no output schema, the description adequately explains return values and diagram types. It does not discuss input validation or size limits, but the schema covers those. Slightly incomplete for a complex use case but sufficient for a simple tool.
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 parameters are already documented. The description adds minor value by explaining diagram types ('TREE for hierarchy, FLOW for flowchart') which mirrors the schema enum descriptions. No additional semantics 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?
The description clearly states 'Turn YAML into a diagram' with specific verb and resource. It mentions diagram types and return values, but does not explicitly differentiate from siblings like convert_yaml or create_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?
No explicit guidance on when to use this tool versus alternatives. The description implies it is for visualizing YAML, but does not mention when not to use or point to sibling tools for other purposes.
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!