Skip to main content
Glama
xiaohuxi

Config Drift Guard MCP

by xiaohuxi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Config Drift Guard MCP

A read-only Model Context Protocol server for comparing environment configuration without exposing detected secrets.

Capabilities

  • Parse .env, YAML, JSON, and Java Properties files.

  • Normalize nested configuration into stable key paths.

  • Detect added, removed, type-changed, value-changed, and secret-changed entries.

  • Mask likely credentials, private keys, bearer tokens, and credential-bearing URLs.

  • Restrict file access to explicitly allowed directories.

  • Run entirely locally without network requests.

Related MCP server: vault-kv-mcp

Tools

inspect_config

Parse one file and return normalized entries, value types, warnings, and protected values.

compare_configs

Compare a baseline file with a target file and return drift items with risk levels.

scan_secrets

Find likely plaintext secrets while returning only masks and SHA-256 fingerprints.

Install

npm install
npm run build

Node.js 20 or later is required.

Configure

Set CONFIG_DRIFT_ALLOWED_ROOTS to one or more directories. Use the operating system path delimiter (; on Windows, : on Linux and macOS).

# Windows PowerShell
$env:CONFIG_DRIFT_ALLOWED_ROOTS='D:\configs\dev;D:\configs\prod'
node dist/index.js
# Linux or macOS
CONFIG_DRIFT_ALLOWED_ROOTS=/srv/config/dev:/srv/config/prod node dist/index.js

If the variable is omitted, only the current working directory is allowed.

MCP Client Configuration

{
  "mcpServers": {
    "config-drift-guard": {
      "command": "node",
      "args": ["/absolute/path/config-drift-guard-mcp/dist/index.js"],
      "env": {
        "CONFIG_DRIFT_ALLOWED_ROOTS": "/absolute/path/configs"
      }
    }
  }
}

Example

The repository includes examples/dev.yaml and examples/prod.yaml.

compare_configs({
  "baselineFile": "/absolute/path/examples/dev.yaml",
  "targetFile": "/absolute/path/examples/prod.yaml"
})

The result distinguishes missing keys, type drift, ordinary value drift, and secret fingerprint changes. Detected secret plaintext is never returned.

Paired Skill

skills/config-drift-remediation converts MCP evidence into:

  • Expected-environment differences.

  • Prioritized defects.

  • Secret-rotation recommendations.

  • Key-level patch guidance.

  • A post-change verification checklist.

Security Model

  • Read-only tools.

  • No network access.

  • No expression or script execution.

  • Maximum input file size of 5 MiB.

  • Allowed-directory enforcement.

  • Secret masks and one-way fingerprints only.

  • No configuration plaintext logging.

Development

npm test
npm run build
npm pack --dry-run

License

MIT

Available Tools

3 tools
compare_configsCompare configurationsA
Read-onlyIdempotent

Compare two local config files and classify added, removed, type, value, and secret drift.

ParametersJSON Schema
NameRequiredDescriptionDefault
targetFileYesAbsolute path to the target config file
baselineFileYesAbsolute path to the baseline config file

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds detail on drift types, but doesn't disclose other behaviors like file access scope or error handling.

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?

Single sentence packs key information, but could benefit from a structured breakdown. No wasted words; however, front-loading is adequate.

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

Completeness3/5

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

With no output schema, description partially explains output (drift types) but lacks details on format. Parameters are well-covered. Sibling tools are listed but no guidance on selection.

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 clear parameter descriptions. The description adds the context of comparison and drift classification, but does not provide additional semantic details 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 the tool compares two local config files and classifies drift types (added, removed, type, value, secret). It distinguishes from siblings (scan_secrets, inspect_config) by focusing on comparison and drift classification.

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?

No explicit guidance on when to use this vs alternatives. The usage is implied from the description, but no when-not-to-use or context for choosing between siblings.

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

inspect_configInspect configurationA
Read-onlyIdempotent

Parse and normalize a local config file while masking detected secrets.

ParametersJSON Schema
NameRequiredDescriptionDefault
filePathYesAbsolute path to a .env, YAML, JSON, or Properties file

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is clear. The description adds that it normalizes and masks secrets, which is useful but not extensive. No contradiction.

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 a single, front-loaded sentence that conveys the core function without any superfluous words.

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 only one parameter and no output schema, the description is mostly complete. It could optionally mention the return format or error conditions, but it adequately covers the tool's purpose.

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% and the description of filePath is already detailed in the schema. The tool description does not add any additional semantics 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 the verb (parse and normalize), resource (local config file), and additional action (masking secrets). It distinguishes from siblings: scan_secrets (scanning) and compare_configs (comparing).

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 implies use for parsing configs, but does not explicitly state when to use or when to avoid, nor does it mention alternative tools. The context from sibling names provides some distinction, but the description could be more directive.

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

scan_secretsScan configuration secretsA
Read-onlyIdempotent

Find likely plaintext credentials and private keys without returning their plaintext values.

ParametersJSON Schema
NameRequiredDescriptionDefault
filePathYesAbsolute path to a local config file

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating a safe read operation. The description adds the crucial behavioral fact that plaintext values are not returned, which is beyond what annotations provide.

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?

Extremely concise single sentence with no superfluous words. The key information is front-loaded and every word earns its place.

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

Completeness3/5

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

With no output schema, the description should indicate the format of the results (e.g., list of matches, line numbers). It only states that plaintext values are not returned, leaving the output format ambiguous.

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% for filePath, with a clear description of 'Absolute path to a local config file'. The tool description does not add any additional meaning 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 the tool's purpose: finding likely plaintext credentials and private keys. It uses a specific verb ('find') and resource ('likely plaintext credentials and private keys'), which distinguishes it from siblings like compare_configs and inspect_config.

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

Usage Guidelines2/5

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 does not mention context, prerequisites, or when not to use it.

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.

  1. 3 tool updatesv1.0.0
    • First observedcompare_configs
    • First observedinspect_config
    • First observedscan_secrets
Deploy Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Scored across 3 tools

Disambiguation5/5

Each tool targets a distinct operation: scanning for secrets, comparing config files, and inspecting a single config. There is no overlap in their purposes, making it easy for an agent to select the correct tool.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (scan_secrets, compare_configs, inspect_config) using snake_case. This predictable structure aids in tool discovery and understanding.

Tool Count5/5

With 3 tools, the server is tightly scoped to config drift detection and secret scanning. Each tool serves a clear, essential function without excess or deficiency for the stated purpose.

Completeness5/5

The tool set covers the core workflow: scanning secrets, comparing two configs, and inspecting a single config. No obvious gaps exist for the read-only analysis focus of the server.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • vault-kv-mcp

    elisjetmax
    F
    license
    A
    quality
    C
    maintenance
    A read-only MCP server that provides tools to read, list, and inspect secrets from HashiCorp Vault's KV secrets engine (versions 1 and 2) using a Vault token.
    5
    -

  • system-monitor

    2428424081cn
    F
    license
    A
    quality
    C
    maintenance
    A secure, read-only MCP server for AI-powered system monitoring. It provides real-time OS metrics, config discovery, and safe log tailing to enable autonomous infrastructure audits without shell access risks.
    4
    1
    -

  • filesystem-mcp-local-test

    seokmogu
    F
    license
    Not graded
    quality
    C
    maintenance
    This MCP server provides read-only access to a single allowed local directory through a secure HTTP gateway, enabling remote MCP clients to read files without syncing them to cloud storage.
    -