Skip to main content
Glama
bitflight-devops

mcp-json-yaml-toml

by bitflight-devops
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

Stop AI coding tools from breaking your data files. No more grep guesswork, hallucinated fields, or non-schema-compliant data added to files. This MCP server gives AI assistants a strict, round-trip safe interface for working with structured data.

The Problem

AI coding tools often destroy structured data files:

  • They grep through huge json, yaml, and toml files (like json logs, or AI transcript files) and guess at keys.

  • They hallucinate fields that never existed.

  • They use sed and regex that leave files in invalid states.

  • They break YAML indentation and TOML syntax.

  • They can't validate changes before writing.

Related MCP server: MCP Filesystem Agent v3

The Solution

mcp-json-yaml-toml provides AI assistants with proper tools for structured data:

  • Token-efficient: Extract exactly what you need without loading entire files.

  • Schema validation: Enforce correctness using SchemaStore.org or custom schemas.

  • Safe modifications: Enforced validation on write; preserve comments and formatting.

  • Multi-format: JSON, YAML, and TOML through a unified interface.

  • Directive-based detection: Support for # yaml-language-server, #:schema, and $schema keys in all formats.

  • Constraint-based guided generation: Native LMQL support for proactive validation of partial inputs.

  • Local-First: All processing happens locally. No data ever leaves your machine.

  • Transparent JIT Assets: The server auto-downloads yq if missing and fetches missing schemas from SchemaStore.org for local caching.

NOTE

JSONC Support: Files with .jsonc extension (JSON with Comments) are fully supported for reading, querying, and schema validation. However, write operations will strip comments due to library limitations.

Getting Started

Prerequisites

  • Python ≥ 3.11 installed.

  • An MCP-compatible client (Claude Code, Cursor, Windsurf, Gemini 2.0, n8n, etc.).

Installation

The server uses uvx for automatic dependency management and zero-config execution.

AI Agents & CLI Tools

uvx mcp-json-yaml-toml

Claude Code (CLI)

claude mcp add --scope user mcp-json-yaml-toml -- uvx mcp-json-yaml-toml

Other MCP Clients

Add this to your client's MCP configuration:

{
  "mcpServers": {
    "json-yaml-toml": {
      "command": "uvx",
      "args": ["mcp-json-yaml-toml"]
    }
  }
}
TIP

Seedocs/clients.md for detailed setup guides for Cursor, VS Code, and more.

Schema Discovery & Recognition

The server automatically identifies the correct JSON schema for your files using multiple strategies:

  1. Directives: Recognizes # yaml-language-server: $schema=... and #:schema ... directives.

  2. In-File Keys: Detects $schema keys in JSON and YAML (also supports quoted "$schema" in TOML).

  3. Local IDE Config: Discovers schemas from VS Code/Cursor extension settings and caches.

  4. SchemaStore.org: Performs glob-based auto-detection against thousands of known formats.

  5. Manual Association: Use the data_schema tool to bind a file to a specific schema URL or name.

LMQL & Guided Generation

This server provides native support for LMQL (Language Model Query Language) to enable Guided Generation. This allows AI agents to validate partial inputs (e.g., path expressions) incrementally before execution.

  • Incremental Validation: Check partial inputs (e.g., .data.us) and get the remaining pattern needed.

  • Improved Reliability: Eliminate syntax errors by guiding the LLM toward valid tool inputs.

  • Rich Feedback: Get suggestions and detailed error messages for common mistakes.

TIP

See theDeep Dive: LMQL Constraints for detailed usage examples.

Available Tools

Tool

Description

data

Get, set, or delete values at specific paths

data_query

Advanced yq/jq expressions for transformations

data_schema

Manage schemas and validate files

data_convert

Convert between JSON, YAML, and TOML

data_merge

Deep merge structured data files

constraint_validate

Validate inputs against LMQL constraints

constraint_list

List available generation constraints

NOTE

ConversionTO TOML is not supported due to yq's internal encoder limitations for complex structures.

Development

Setup

git clone https://github.com/bitflight-devops/mcp-json-yaml-toml.git
cd mcp-json-yaml-toml
uv sync

Testing

ash

Run all tests (coverage included)

uv run pytest


### Code Quality

The project uses `prek` (a Rust-based pre-commit tool) for unified linting and formatting. AI Agents MUST use the scoped verification command:

```bash
# Recommended: Verify only touched files
uv run prek run --files <file edited>
IMPORTANT

Avoid--all-files during feature development to keep PR diffs clean and preserve git history.

Project Structure

mcp-json-yaml-toml/
├── packages/mcp_json_yaml_toml/  # Core logic
│   ├── server.py                 # MCP implementation
│   ├── yq_wrapper.py             # Binary management
│   ├── schemas.py                # Schema validation
├── .github/                      # CI/CD and assets
├── docs/                         # Documentation
└── pyproject.toml                # Project config
# Run all tests (coverage included)
uv run pytest

Code Quality

The project uses prek (a Rust-based pre-commit tool) for unified linting and formatting. AI Agents MUST use the scoped verification command:

# Recommended: Verify only touched files
uv run prek run --files <file edited>
IMPORTANT

Avoid--all-files during feature development to keep PR diffs clean and preserve git history.

Project Structure

graph TD
    Repo[mcp-json-yaml-toml]
    Repo --> Packages[packages/mcp_json_yaml_toml]
    Repo --> Github[.github]
    Repo --> Docs[docs]
    Repo --> Config[pyproject.toml]

    subgraph "Core Logic"
        Packages --> Server[server.py<br/>MCP Server & Tools]
        Packages --> Schemas[schemas.py<br/>Schema Validation]
        Packages --> Constraints[lmql_constraints.py<br/>LMQL Constraints]
        Packages --> YQ[yq_wrapper.py<br/>Binary Manager]
        Packages --> YAML[yaml_optimizer.py<br/>YAML Anchors]
        Packages --> TOML[toml_utils.py<br/>TOML Utils]
        Packages --> Conf[config.py<br/>Config Manager]
    end

    style Packages fill:#f9f,stroke:#333,stroke-width:2px
    style Repo fill:#eee,stroke:#333,stroke-width:4px

Token Efficiency Experiment

Two identical Claude Code sub-agents were given the same task: read ~/.claude.json and report every MCP server listed, including command, args, and env vars.

Setup

  • Agent A — standard prompt, used the built-in Read tool

  • Agent B — same prompt with one line appended: You must use the mcp__json-yaml-toml for all file interactions.

Both agents used the sonnet model.

Prompts

Agent A prompt:

Read the file ~/.claude.json and report back:
1. Every MCP server listed in the mcpServers section
2. For each server: the command, args, and any env vars configured

Just report the raw findings. Do not summarize or interpret.

Agent B prompt:

Read the file ~/.claude.json and report back:
1. Every MCP server listed in the mcpServers section
2. For each server: the command, args, and any env vars configured

You must use the mcp__json-yaml-toml for all file interactions.

Just report the raw findings. Do not summarize or interpret.

Results

Both agents returned identical findings (8 MCP servers with correct configs).

Metric

Agent A (Read tool)

Agent B (mcp-json-yaml-toml)

Total tokens

37,119

28,734

Tool uses

4

2

Duration

29.3s

12.7s

Agent B used 22.6% fewer tokens and completed in 43% of the time with half the tool calls.

Why

The Read tool loads the entire file into context. ~/.claude.json is a large file — the agent had to consume all of it to find the mcpServers section. The MCP server's data_query tool extracted just the mcpServers section directly, keeping the context window small.

Available Tools

8 tools
constraint_listA
Read-onlyIdempotent

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 constraint_validate(constraint_name, value)).

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
usageNo
constraintsNo

TDQS

A4.3/5.0
Behavior3/5

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

Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the agent knows it's a safe read operation. The description adds return format details but no extra behavioral context beyond what annotations convey.

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?

Short paragraph front-loads purpose and uses bullet-like structure for output keys. Every sentence is informative with no fluff.

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?

Given the tool's simplicity (no params, output schema detailed in description), the definition is complete. Annotations cover safety, and description covers return format. No gaps.

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?

Input schema has no parameters (100% coverage), so description cannot add parameter info. However, it thoroughly explains the output structure, which is helpful for the agent to understand what the tool returns.

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 clearly states it returns a list of registered LMQL constraints with metadata, using specific verb+resource. It distinguishes from siblings like constraint_validate, which validates a value against a constraint.

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

Usage Guidelines4/5

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

The description implies usage for retrieving constraints with their metadata, but does not explicitly state when to use this tool vs alternatives like constraint_validate. However, the context is clear and no exclusions are needed.

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

constraint_validateA
Read-onlyIdempotent

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:

  • YQ_PATH: Valid yq path (e.g., '.users[0].name')

  • YQ_EXPRESSION: Valid yq expression with pipes (e.g., '.items | length')

  • CONFIG_FORMAT: Valid format ('json', 'yaml', 'toml', 'xml')

  • KEY_PATH: Dot-separated key path (e.g., 'config.database.host')

  • INT: Valid integer

  • JSON_VALUE: Valid JSON syntax

  • FILE_PATH: Valid file path syntax

ParametersJSON Schema
NameRequiredDescriptionDefault
valueYesValue to validate
constraint_nameYesName of the constraint to validate against (e.g., 'YQ_PATH', 'CONFIG_FORMAT', 'INT')

Output Schema

ParametersJSON Schema
NameRequiredDescription
hintNo
errorNo
validYes
valueNo
constraintNo
is_partialNo

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive behavior. The description adds significant value: explicit side effects (none), failure modes (ToolError for unknown constraint), output contract (valid, error, is_partial), and a comprehensive list of available constraints with examples. No contradictions with 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 concise and well-structured: purpose, usage guidance, output contract, side effects, failure modes, and constraint list. Every sentence is informative with no redundancy or unnecessary words.

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?

Given the tool's simple validation purpose, the description covers all necessary aspects: when to use, output structure, available constraints, side effects, and failure modes. Annotations safely cover behavioral traits, and the implied output schema complements the description. No gaps for an effective invocation.

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?

Schema coverage is 100% and its parameter descriptions are decent, but the description enriches the constraint_name parameter with a full list of constraints and examples (e.g., 'YQ_PATH: Valid yq path (e.g., ".users[0].name")'). This adds meaning beyond the schema's brief example list.

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 clearly states the tool validates a value against an LMQL-style constraint, with a specific verb and resource. It distinguishes from siblings like constraint_list (which lists constraints) by focusing on validation. The context 'before using it in other operations' further clarifies purpose.

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

Usage Guidelines4/5

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

The description provides explicit guidance on when to use this tool: to check validity before other operations. It also mentions partial validation support. However, it does not explicitly state when not to use it or list alternatives, which would improve differentiation.

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

dataA
DestructiveIdempotent

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:

  • get: Retrieve data, schema, or structure

  • set: Update/create value at key_path (always writes to file)

  • delete: Remove key/element at key_path (always writes to file)

ParametersJSON Schema
NameRequiredDescriptionDefault
valueNoValue to set as JSON string (required for operation='set')
cursorNoPagination cursor
key_pathNoDot-separated key path (required for set/delete, optional for get)
data_typeNoType for get: 'data', 'schema', or 'meta' (server info)data
file_pathYesPath to file
operationYesOperation: 'get', 'set', or 'delete'
value_typeNoHow to interpret the value parameter for SET operations. 'string': treat value as literal string (no JSON parsing). 'number': parse value as JSON number. 'boolean': parse value as JSON boolean. 'null': set to null/None (value parameter ignored). 'json' or None (default): parse value as JSON (current behavior, maintains backward compatibility).
return_typeNoReturn type for get: 'keys' (structure) or 'all' (full data)all
output_formatNoOutput format
document_indexNoOptional YAML document index for multi-document files (0-based)

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds valuable behavioral details: side effects ('Modifies file on disk if operation is 'set' or 'delete''), failure modes ('FileNotFoundError if file missing'), and output contract. This goes beyond the annotations without contradicting them.

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 well-structured and concise: a one-line summary, usage guidance, then structured sections for output contract, side effects, failure modes, and operation bullets. Every sentence adds value without redundancy.

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

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (10 parameters) and the presence of an output schema, the description covers output contract, side effects, failure modes, and operations. It is comprehensive, though it could briefly mention parameter interactions (e.g., required parameters per operation) to reach full completeness.

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?

The input schema has 100% description coverage, so the baseline is 3. The description does not add additional meaning beyond the schema; it only reiterates operation semantics. No parameter-specific clarification is provided that isn't already in the schema.

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 clearly states the tool's purpose: 'Get, set, or delete data in JSON, YAML, or TOML files.' It uses specific verbs and resource types, and the bullet list of operations further clarifies. The description distinguishes this tool from siblings like data_query and data_convert by focusing on basic file CRUD operations.

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

Usage Guidelines4/5

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

The description includes a direct usage statement: 'Use when you need to get, set, or delete specific values or entire sections in a structured data file.' This provides clear context. However, it does not explicitly exclude alternative tools or specify when not to use it, so it lacks full comparative guidance.

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

data_convertA
Read-onlyIdempotent

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYesPath to source file
output_fileNoOptional output file path (if not provided, returns converted content)
output_formatYesTarget format to convert to

Output Schema

ParametersJSON Schema
NameRequiredDescription
fileNo
resultNo
messageNo
successYes
input_fileNo
output_fileNo
input_formatNo
output_formatNo

TDQS

A4.8/5.0
Behavior5/5

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

The description discloses side effects ('Writes to output_file if provided'), output contract, and failure modes, adding context beyond annotations. It is consistent with idempotentHint and destructiveHint, though readOnlyHint is contradicted (see below).

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 concise with 4 sentences, front-loading the action ('Convert file format') and using structured sections for output contract, side effects, and failure modes, with no wasted words.

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?

The description covers the conversion use case, all parameters, side effects, failure modes, and output contract. Given the output schema exists, no further detail is needed.

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

Parameters5/5

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

Schema coverage is 100%, and the description adds meaning by explaining the dual behavior (return string vs. write to file) based on output_file parameter, and implicitly confirms output_format via listed formats.

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 starts with 'Convert file format' and specifies the supported formats (JSON, YAML, TOML), clearly stating the tool's function. It is distinct from siblings like data_diff and data_merge, which do not perform format conversion.

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

Usage Guidelines4/5

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

The description explicitly states 'Use when you need to transform a file from one format (JSON, YAML, TOML) to another,' providing clear usage context. However, it lacks explicit when-not-to-use guidance or alternatives, though siblings do not compete.

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

data_diffA
Read-onlyIdempotent

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
file_path1YesPath to first file (base)
file_path2YesPath to second file (comparison)
ignore_orderNoIgnore list/array ordering in comparison

Output Schema

ParametersJSON Schema
NameRequiredDescription
fileNo
file1No
file2No
successYes
summaryNo
statisticsNo
differencesNo
file1_formatNo
file2_formatNo
has_differencesNo

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable context: side effects (none), failure modes (ToolError for missing files or disabled formats), and output contract (DiffResponse with has_differences, differences, statistics, summary). No contradictions.

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 concise with four sentences, each serving a purpose: purpose, details, output contract, side effects/failures. No redundant information.

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

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of output schema and annotations, the description adequately covers purpose, supported formats, output structure, and failure modes. It could mention performance but is sufficient for typical use.

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% with all three parameters described. The description adds overall context (e.g., cross-format comparison) but does not enhance individual parameter meanings beyond 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.

Purpose5/5

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

The description clearly states the verb 'compare' and the resource 'configuration files', and specifies the output 'structured differences'. It distinguishes from sibling tools like data_merge or data_convert by focusing on diffing.

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

Usage Guidelines4/5

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

The description indicates when to use the tool: for deep comparison of configuration files in JSON, YAML, TOML, including cross-format. It does not explicitly mention when not to use it or provide alternatives among siblings, 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.

data_mergeA
Read-onlyIdempotent

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
file_path1YesPath to first file (base)
file_path2YesPath to second file (overlay)
output_fileNoOptional output file path (if not provided, returns merged content)
output_formatNoOutput format (defaults to format of first file)

Output Schema

ParametersJSON Schema
NameRequiredDescription
fileNo
file1No
file2No
resultNo
messageNo
successYes
output_fileNo
output_formatNo

TDQS

A4.7/5.0
Behavior5/5

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

The description fully discloses the deep merge behavior, override semantics, and output options (file vs. response). Annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false) are consistent and complemented by the description's details on return values and errors.

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 well-structured with a summary, detailed parameter list, return info, and error notes. It is concise yet comprehensive, using clear sections without unnecessary words.

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?

Given the tool's complexity (4 parameters, 2 required), full schema coverage, and presence of output schema, the description covers all necessary aspects: behavior, parameters, return values, and error conditions. No gaps identified.

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?

Schema coverage is 100%, but the description adds meaning: it explains that file_path2 values override file_path1, clarifies default format behavior, and describes the conditional return structure. This adds value beyond the schema.

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 clearly states it merges two files into a deep-merged configuration. It uses specific verbs ('Merge') and resources ('two files', 'deep-merged configuration'), distinguishing it from sibling tools like data_diff or data_convert.

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

Usage Guidelines4/5

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

The description explains the general usage (merge two files with overlay semantics). It does not explicitly state when not to use it or list alternatives, but the sibling tool names provide context that this is for merging, not diffing or converting.

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

data_queryA
Read-onlyIdempotent

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
cursorNoPagination cursor from previous response (omit for first page)
file_pathYesPath to file
expressionYesyq expression to evaluate (e.g., '.name', '.items[]', '.data.users')
output_formatNoOutput format (defaults to same as input file format)
document_indexNoOptional YAML document index for multi-document files (0-based)

Output Schema

ParametersJSON Schema
NameRequiredDescription
fileNo
formatNo
resultNo
successYes
advisoryNo
paginatedNo
nextCursorNo
schema_infoNo
structure_summaryNo

TDQS

A4.5/5.0
Behavior5/5

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

Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds output contract format, confirms no side effects, and lists failure modes (FileNotFoundError, ToolError). No contradiction with 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 concise with three clear sections: purpose, usage, and contract/behavior. Every sentence adds value, no fluff. Front-loaded with primary purpose.

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?

Given the tool's complexity (5 params, 2 required, output schema present), the description fully covers purpose, usage, output contract, side effects, and failure modes. No gaps remain.

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% with detailed parameter descriptions. The description does not add significant meaning beyond the schema (e.g., mentions 'yq expression' and supported formats). 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 clearly states the tool extracts, filters, or transforms data without modification, using a specific verb and resource. It distinguishes from siblings like data_convert or data_merge by emphasizing read-only querying on JSON, YAML, TOML files.

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

Usage Guidelines4/5

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

The description explicitly states when to use the tool (extracting/filtering/transforming without modification) and provides output contract and failure modes. It lacks explicit when-not-to-use or alternative tools, 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.

data_schemaA
Idempotent

Unified schema operations tool.

Actions:

  • validate: Validate file syntax and optionally against schema

  • scan: Recursively search for schema directories

  • add_dir: Add custom schema directory

  • add_catalog: Add custom schema catalog

  • associate: Bind file to schema URL or name

  • disassociate: Remove file-to-schema association

  • list: Show current schema configuration

Examples:

  • action="validate", file_path="config.json"

  • action="associate", file_path=".gitlab-ci.yml", schema_name="gitlab-ci"

  • action="disassociate", file_path=".gitlab-ci.yml"

  • action="list"

ParametersJSON Schema
NameRequiredDescriptionDefault
uriNoCatalog URI (for add_catalog action)
nameNoCatalog name (for add_catalog action)
pathNoDirectory path (for add_dir action)
actionYesAction: validate, scan, add_dir, add_catalog, associate, disassociate, or list
file_pathNoPath to file (for validate/associate/disassociate actions)
max_depthNoMax search depth (for scan action)
schema_urlNoSchema URL (for associate action)
schema_nameNoSchema name from catalog (for associate action)
schema_pathNoPath to schema file (for validate action)
schema_pathsNoOptional per-document schema file paths for multi-document YAML (for validate action)
search_pathsNoPaths to scan (for scan action)
document_indexNoOptional YAML document index for validate action in multi-document files (0-based)

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4/5.0
Behavior3/5

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

Annotations provide readOnlyHint=false, openWorldHint=true, idempotentHint=true, destructiveHint=false, which convey basic safety profile. The description adds the fact that the tool performs schema operations but does not elaborate on behavioral details such as side effects of adding directories/catalogs, error handling, or permissions. It complements but does not significantly extend beyond 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 well-structured with a concise summary, a bullet list of actions, and clear examples. Every sentence is informative and earns its place. The front-loaded format allows quick comprehension of the tool's purpose and capabilities.

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

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (7 actions, 12 parameters) and the presence of an output schema, the description sufficiently covers each action's purpose and provides illustrative examples. It could be more complete by explaining when to use each action (e.g., prerequisites for add_dir vs. add_catalog) but is not missing critical information for typical usage.

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?

Input schema covers all 12 parameters with descriptions (100% coverage), so baseline is 3. The description adds value by providing concrete examples showing parameter combinations for specific actions (e.g., 'action="validate", file_path="config.json"'), which helps understand typical usage beyond the schema's individual parameter descriptions.

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 clearly states it is a 'Unified schema operations tool' and enumerates all seven specific actions (validate, scan, add_dir, add_catalog, associate, disassociate, list). Each action has a brief purpose, and the examples solidify understanding. The tool is well differentiated from siblings, which cover constraints, data manipulation, and queries rather than schema operations.

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

Usage Guidelines3/5

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

The description lists actions and provides examples, but does not explicitly state when to use this tool versus alternatives. Sibling tools are conceptually distinct (e.g., constraint_validate vs. schema validation), but the description offers no exclusions or context for choosing this tool. Usage is implied but not explicit.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 8 tool updatesv0.10.0
    • Changedconstraint_list4 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • removedOutput schema / additionalProperties
        Removed value: -true
      • addedOutput schema / description
        Added value: +"Response for constraint_list tool."
      • addedOutput schema / properties
        Added value: +{
+  "constraints": {
+    "default": [],
+    "items": {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    "type": "array"
+  },
+  "usage": {
+    "default": "",
+    "type": "string"
+  }
+}
    • Changedconstraint_validate4 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • addedOutput schema / description
        Added value: +"Response for constraint_validate tool.\n\nDoes NOT inherit ToolResponse -- different shape from the validation API.\nUses ``extra=\"allow\"`` so dynamic fields from ``ValidationResult.to_dict()``\n(e.g. ``suggestions``, ``remaining_pattern``) are preserved."
      • addedOutput schema / properties
        Added value: +{
+  "constraint": {
+    "default": "",
+    "type": "string"
+  },
+  "error": {
+    "anyOf": [
+      {
+        "type": "string"
+      },
+      {
+        "type": "null"
+      }
+    ],
+    "default": null
+  },
+  "hint": {
+    "anyOf": [
+      {
+        "type": "string"
+      },
+      {
+        "type": "null"
+      }
+    ],
+    "default": null
+  },
+  "is_partial": {
+    "anyOf": [
+      {
+        "type": "boolean"
+      },
+      {
+        "type": "null"
+      }
+    ],
+    "default": null
+  },
+  "valid": {
+    "type": "boolean"
+  },
+  "value": {
+    "default": "",
+    "type": "string"
+  }
+}
      • addedOutput schema / required
        Added value: +[
+  "valid"
+]
    • Changeddata8 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • changedInput schema / properties / data_type / description
        Previous value: -"Type for get: 'data' or 'schema'"New value: +"Type for get: 'data', 'schema', or 'meta' (server info)"
      • changedInput schema / properties / data_type / enum
        Previous value: -[
-  "data",
-  "schema"
-]New value: +[
+  "data",
+  "schema",
+  "meta"
+]
      • addedInput schema / properties / document_index
        Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Optional YAML document index for multi-document files (0-based)"
+}
      • removedOutput schema / additionalProperties
        Removed value: -true
      • addedOutput schema / properties
        Added value: +{
+  "result": {
+    "anyOf": [
+      {
+        "additionalProperties": true,
+        "description": "Response for data GET and data_query returns.",
+        "properties": {
+          "advisory": {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ],
+            "default": null
+          },
+          "file": {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ],
+            "default": null
+          },
+          "format": {
+            "default": "",
+            "type": "string"
+          },
+          "nextCursor": {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ],
+            "default": null
+          },
+          "paginated": {
+            "default": false,
+            "type": "boolean"
+          },
+          "result": {
+            "default": null,
+            "title": "Result"
+          },
+          "schema_info": {
+            "anyOf": [
+              {
+                "properties": {
+                  "name": {
+                    "type": "string"
+                  },
+                  "source": {
+                    "type": "string"
+                  },
+                  "url": {
+                    "type": "string"
+                  }
+                },
+                "required": [
+                  "name",
+                  "url",
+                  "source"
+                ],
+                "type": "object"
+              },
+              {
+                "type": "null"
+              }
+            ],
+            "default": null
+          },
+          "structure_summary": {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ],
+            "default": null
+          },
+          "success": {
+            "type": "boolean"
+          }
+        },
+        "required": [
+          "success"
+        ],
+        "type": "object"
+      },
+      {
+        "description": "Response format for schema retrieval.\n\nMoved from server.py -- preserves the alias for 'schema' field\nto match the existing API contract.",
+        "properties": {
+          "file": {
+            "type": "string"
+          },
+          "message": {
+            "type": "string"
+          },
+          "schema": {
+            "anyOf": [
+              {
+                "additionalProperties": true,
+                "type": "object"
+              },
+              {
+                "type": "null"
+              }
+            ],
+            "default": null
+          },
+          "schema_file": {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ],
+            "default": null
+          },
+          "schema_info": {
+            "anyOf": [
+              {
+                "properties": {
+                  "name": {
+                    "type": "string"
+                  },
+                  "source": {
+                    "type": "string"
+                  },
+                  "url": {
+                    "type": "string"
+                  }
+                },
+                "required": [
+                  "name",
+                  "url",
+                  "source"
+                ],
+                "type": "object"
+              },
+              {
+                "type": "null"
+              }
+            ],
+            "default": null
+          },
+          "success": {
+            "type": "boolean"
+          }
+        },
+        "required": [
+          "success",
+          "file",
+          "message"
+        ],
+        "type": "object"
+      },
+      {
+        "additionalProperties": true,
+        "description": "Response for data SET/DELETE operations.",
+        "properties": {
+          "file": {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ],
+            "default": null
+          },
+          "message": {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ],
+            "default": null
+          },
+          "optimized": {
+            "default": false,
+            "type": "boolean"
+          },
+          "result": {
+            "default": "",
+            "type": "string"
+          },
+          "schema_info": {
+            "anyOf": [
+              {
+                "properties": {
+                  "name": {
+                    "type": "string"
+                  },
+                  "source": {
+                    "type": "string"
+                  },
+                  "url": {
+                    "type": "string"
+                  }
+                },
+                "required": [
+                  "name",
+                  "url",
+                  "source"
+                ],
+                "type": "object"
+              },
+              {
+                "type": "null"
+              }
+            ],
+            "default": null
+          },
+          "success": {
+            "type": "boolean"
+          }
+        },
+        "required": [
+          "success"
+        ],
+        "type": "object"
+      },
+      {
+        "additionalProperties": true,
+        "description": "Response for data_type='meta' server info requests.",
+        "properties": {
+          "file": {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ],
+            "default": null
+          },
+          "start_time_epoch": {
+            "default": 0,
+            "type": "number"
+          },
+          "success": {
+            "type": "boolean"
+          },
+          "uptime_seconds": {
+            "default": 0,
+            "type": "number"
+          },
+          "version": {
+            "default": "",
+            "type": "string"
+          }
+        },
+        "required": [
+          "success"
+        ],
+        "type": "object"
+      }
+    ]
+  }
+}
      • addedOutput schema / required
        Added value: +[
+  "result"
+]
      • addedOutput schema / x-fastmcp-wrap-result
        Added value: +true
    • Changeddata_convert4 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • addedOutput schema / description
        Added value: +"Response for data_convert tool."
      • addedOutput schema / properties
        Added value: +{
+  "file": {
+    "anyOf": [
+      {
+        "type": "string"
+      },
+      {
+        "type": "null"
+      }
+    ],
+    "default": null
+  },
+  "input_file": {
+    "default": "",
+    "type": "string"
+  },
+  "input_format": {
+    "default": "",
+    "type": "string"
+  },
+  "message": {
+    "anyOf": [
+      {
+        "type": "string"
+      },
+      {
+        "type": "null"
+      }
+    ],
+    "default": null
+  },
+  "output_file": {
+    "anyOf": [
+      {
+        "type": "string"
+      },
+      {
+        "type": "null"
+      }
+    ],
+    "default": null
+  },
+  "output_format": {
+    "default": "",
+    "type": "string"
+  },
+  "result": {
+    "anyOf": [
+      {
+        "type": "string"
+      },
+      {
+        "type": "null"
+      }
+    ],
+    "default": null
+  },
+  "success": {
+    "type": "boolean"
+  }
+}
      • addedOutput schema / required
        Added value: +[
+  "success"
+]
    • Addeddata_diff
    • Changeddata_merge4 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • addedOutput schema / description
        Added value: +"Response for data_merge tool."
      • addedOutput schema / properties
        Added value: +{
+  "file": {
+    "anyOf": [
+      {
+        "type": "string"
+      },
+      {
+        "type": "null"
+      }
+    ],
+    "default": null
+  },
+  "file1": {
+    "default": "",
+    "type": "string"
+  },
+  "file2": {
+    "default": "",
+    "type": "string"
+  },
+  "message": {
+    "anyOf": [
+      {
+        "type": "string"
+      },
+      {
+        "type": "null"
+      }
+    ],
+    "default": null
+  },
+  "output_file": {
+    "anyOf": [
+      {
+        "type": "string"
+      },
+      {
+        "type": "null"
+      }
+    ],
+    "default": null
+  },
+  "output_format": {
+    "default": "",
+    "type": "string"
+  },
+  "result": {
+    "anyOf": [
+      {
+        "type": "string"
+      },
+      {
+        "type": "null"
+      }
+    ],
+    "default": null
+  },
+  "success": {
+    "type": "boolean"
+  }
+}
      • addedOutput schema / required
        Added value: +[
+  "success"
+]
    • Changeddata_query7 fields changed
      • removedInput schema / $defs
        Removed value: -{
-  "FormatType": {
-    "description": "Supported file format types for yq operations.",
-    "enum": [
-      "json",
-      "yaml",
-      "toml",
-      "xml",
-      "csv",
-      "tsv",
-      "props"
-    ],
-    "type": "string"
-  }
-}
      • addedInput schema / additionalProperties
        Added value: +false
      • addedInput schema / properties / document_index
        Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Optional YAML document index for multi-document files (0-based)"
+}
      • changedInput schema / properties / output_format / anyOf
        Previous value: -[
-  {
-    "$ref": "#/$defs/FormatType"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "description": "Supported file format types for yq operations.",
+    "enum": [
+      "json",
+      "yaml",
+      "toml",
+      "xml",
+      "csv",
+      "tsv",
+      "props"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • addedOutput schema / description
        Added value: +"Response for data GET and data_query returns."
      • addedOutput schema / properties
        Added value: +{
+  "advisory": {
+    "anyOf": [
+      {
+        "type": "string"
+      },
+      {
+        "type": "null"
+      }
+    ],
+    "default": null
+  },
+  "file": {
+    "anyOf": [
+      {
+        "type": "string"
+      },
+      {
+        "type": "null"
+      }
+    ],
+    "default": null
+  },
+  "format": {
+    "default": "",
+    "type": "string"
+  },
+  "nextCursor": {
+    "anyOf": [
+      {
+        "type": "string"
+      },
+      {
+        "type": "null"
+      }
+    ],
+    "default": null
+  },
+  "paginated": {
+    "default": false,
+    "type": "boolean"
+  },
+  "result": {
+    "default": null,
+    "title": "Result"
+  },
+  "schema_info": {
+    "anyOf": [
+      {
+        "properties": {
+          "name": {
+            "type": "string"
+          },
+          "source": {
+            "type": "string"
+          },
+          "url": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "name",
+          "url",
+          "source"
+        ],
+        "type": "object"
+      },
+      {
+        "type": "null"
+      }
+    ],
+    "default": null
+  },
+  "structure_summary": {
+    "anyOf": [
+      {
+        "type": "string"
+      },
+      {
+        "type": "null"
+      }
+    ],
+    "default": null
+  },
+  "success": {
+    "type": "boolean"
+  }
+}
      • addedOutput schema / required
        Added value: +[
+  "success"
+]
    • Changeddata_schema3 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • addedInput schema / properties / document_index
        Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Optional YAML document index for validate action in multi-document files (0-based)"
+}
      • addedInput schema / properties / schema_paths
        Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Optional per-document schema file paths for multi-document YAML (for validate action)"
+}
  2. 7 tool updatesv1.0.0
    • First observedconstraint_list
    • First observedconstraint_validate
    • First observeddata
    • First observeddata_convert
    • First observeddata_merge
    • First observeddata_query
    • First observeddata_schema
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0
Disambiguation4/5

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.

Naming Consistency4/5

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.

Tool Count5/5

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.

Completeness5/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • daimonos

    beardfaceguy
    A
    license
    B
    quality
    A
    maintenance
    Agent-optimized MCP server that replaces built-in file, search, exec, and git tools with compact, structured JSON equivalents. Benchmarked 20–45% token savings for AI coding agents.
    20
    2
    MIT

  • localllm-MCP

    tsxk1san
    F
    license
    Not graded
    quality
    B
    maintenance
    MCP server that enables AI to read, search, and edit local files securely without external data exposure, using local LLMs via Ollama and integrating with Open WebUI or Claude Desktop.
    -

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/bitflight-devops/mcp-json-yaml-toml'

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