mcp-json-yaml-toml
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| constraint_validateA | Validate a value against an LMQL-style constraint. Use this tool to check if a value satisfies a constraint before using it in other operations. Supports partial validation - can tell if an incomplete input could still become valid. Output contract: Returns {"valid": bool, "error": str?, "is_partial": bool?, ...}. Side effects: None (read-only validation). Failure modes: ToolError if constraint name unknown. Available constraints:
|
| constraint_listA | Return a list of all registered LMQL constraints with their metadata. Returns:
ConstraintListResponse with keys:
- "constraints": a list of constraint objects; each object includes a "name" key and the constraint's definition fields (e.g., "description", any other metadata).
- "usage": a string describing how to validate a value against a constraint (e.g., call |
| data_convertA | Convert file format. Use when you need to transform a file from one format (JSON, YAML, TOML) to another. Output contract: Returns {"success": bool, "result": str, ...} or writes to file. Side effects: Writes to output_file if provided. Failure modes: FileNotFoundError if input missing. ToolError if formats same or conversion fails. |
| data_mergeA | Merge two files into a single deep-merged configuration. Performs a deep merge where values from the second (overlay) file override or extend those in the first (base) file. If output_file is provided the merged result is written to that path; otherwise the merged content is returned in the response. Parameters: file_path1 (str): Path to the base file. file_path2 (str): Path to the overlay file whose values override the base. output_format (str | None): Desired output format: "json", "yaml", or "toml". Defaults to the format of the first file. output_file (str | None): Optional path to write the merged output. When omitted, merged content is returned. Returns: MergeResponse with "success", "file1", "file2", "output_format", and either "result" (merged content) or "output_file" (written path). Raises: ToolError: If an input file is missing, its format is not enabled, the output format is invalid, or the merge fails. |
| dataA | Get, set, or delete data in JSON, YAML, or TOML files. Use when you need to get, set, or delete specific values or entire sections in a structured data file. Output contract: Returns {"success": bool, "result": Any, "file": str, ...}. Side effects: Modifies file on disk if operation is 'set' or 'delete'. Failure modes: FileNotFoundError if file missing. ToolError if format disabled or invalid JSON. Operations:
|
| data_diffA | Compare two configuration files and return structured differences. Performs a deep comparison of two configuration files (JSON, YAML, TOML) and returns a structured diff with statistics and a human-readable summary. Supports cross-format comparison (e.g. JSON vs YAML). Output contract: Returns DiffResponse with has_differences, differences dict, statistics, and summary. Side effects: None (read-only). Failure modes: ToolError if files not found or formats disabled. |
| data_queryA | Extract specific data, filter content, or transform structure without modification. Use when you need to extract specific data, filter content, or transform the structure of a JSON, YAML, or TOML file without modifying it. Output contract: Returns {"success": bool, "result": Any, "format": str, "file": str, ...}. Side effects: None (read-only). Failure modes: FileNotFoundError if file missing. ToolError if format disabled or query fails. |
| data_schemaA | Unified schema operations tool. Actions:
Examples:
|
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| explain_config | Produce a natural-language prompt that requests an analysis of a configuration file. The generated prompt asks an assistant to: 1. Identify the file format (JSON, YAML, TOML). 2. Summarize the file's key sections and their purpose. 3. Highlight critical settings and potential misconfigurations. 4. Check adherence to an available schema, if one exists. Parameters: file_path (str): Path to the configuration file to be analyzed. Returns: prompt (str): A formatted prompt string referring to the provided file path. |
| suggest_improvements | Generate a prompt to suggest improvements for a configuration file. |
| convert_to_schema | Generate a prompt to create a JSON schema from a configuration file. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| list_all_constraints | Provide metadata and definitions for all registered LMQL constraints. Returns: A dictionary with: - "constraints": a mapping of all constraint definitions keyed by name. - "description": a short human-readable description of the constraint collection. - "usage": a brief usage note for applying these constraints in constrained generation. |
TDQS
Scored across 8 tools
Most tools are distinct, but 'data' and 'data_query' both support reading data; agents may be unsure which to use for extraction queries. Descriptions help differentiate (data for CRUD, data_query for queries/transformations), but some overlap remains.
The majority follow a consistent 'data_<verb>' pattern (convert, diff, merge, query, schema) and 'constraint_<verb>' pattern. However, the bare 'data' tool without a suffix breaks the pattern, creating a minor inconsistency.
With 8 tools covering CRUD, format conversion, diff, merge, query, schema, and constraints, the count is well-scoped for the domain. Each tool serves a clear purpose without unnecessary bloat or undercoverage.
The tool surface provides full lifecycle support for JSON/YAML/TOML files: read, write, delete, format conversion, comparison, merging, querying, and schema operations. No obvious gaps for common use cases.