Skip to main content
Glama
Sign In

YAMLTools

by dev.yamltools
OverviewDiscussionsAdmin

Analyze a configuration file

analyze_config

Review a configuration file the way a DevOps engineer would. Detects the technology (Docker Compose, Kubernetes manifests, Helm charts, GitHub Actions, GitLab CI, OpenAPI/Swagger and Ansible; otherwise generic YAML/JSON) and returns JSON with: the detected technology and alternatives, diagnostics validated against the official JSON Schema plus technology rules (line, column, severity, code, plain-English message, and a mechanical fix when one exists), security and reliability risks with their remediation (privileged containers, :latest images, plaintext secrets, missing limits or healthchecks, unpinned actions…), and a one-line summary. Use it before committing or reviewing a config, or when the user asks "what is wrong with this file" or "what are the risks". Prefer it over validate_yaml for any of these technologies.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "content": "<content>"
    },
    "name": "analyze_config"
  }
}

Input Schema

NameRequiredDescriptionDefault
techNoForce the technology instead of auto-detecting it
contentYesThe full text of the configuration file (YAML or JSON)
filenameNoFile name or path, e.g. "docker-compose.prod.yml" or ".github/workflows/ci.yml". Improves detection; pass it whenever you know it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses auto-detection with alternatives, that diagnostics come from the official JSON Schema plus technology rules, and that findings include line/column/severity/code/message/fix. It never explicitly says the tool is read-only and non-mutating, and omits the 200k character input cap, but the 'review/analysis' framing makes the safe nature evident.

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

Conciseness4/5

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

One dense paragraph, but it is front-loaded with the action and the technology list, then the return contract, then the routing rule. The parenthetical risk examples add useful concretization; a bit of tightening in the returned-JSON sentence would make it a 5.

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?

There is no output schema, so the description takes on return-value explanation itself and does it thoroughly: detected technology plus alternatives, diagnostics fields, risk findings with remediation, and a one-line summary. For a three-parameter analysis tool this is complete enough to call correctly without opening anything else.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

Schema coverage is 100%, so the schema already documents content, filename, and the tech enum with its 'force instead of auto-detect' semantics. The description mentions detection and alternatives but adds no per-parameter guidance (e.g., when to override tech) beyond what the schema states, so baseline 3 applies.

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 states a specific verb and resource ('Review a configuration file'), enumerates the exact technology set it handles, and names the concrete outputs (diagnostics, risks, summary). It is immediately distinguishable from siblings like validate_yaml or convert_config.

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?

It gives explicit trigger conditions ('before committing or reviewing a config', 'what is wrong with this file') and an explicit alternative with a routing rule: 'Prefer it over validate_yaml for any of these technologies.' When-to-use, when-not, and the alternative are all present.

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

All YAMLTools toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources