
Envspeak
io.github.PatrizzosPublished by GitHub account Patrizzosv0.1.0Updated Oct 24, 2026
MCP server and CLI that resolves config/env-var cascade across .env, docker-compose, and Kubernetes
Overview
Local MCP server and CLI that resolves which config source wins for an environment variable across .env files, Docker Compose and Kubernetes, and explains why.
- What you can do
- Resolve a single variable to its effective value and identify the winning source file or layer, with a confidence level and caveat string when static analysis cannot be certain. Trace every place a variable is set across files, environments and services. Preview the downstream impact of changing a value in one file, including what is shielded by a higher-precedence source and Kubernetes values frozen at pod start. Produce a whole-project manifest of variables, their sources and risk hotspots such as secrets in tracked files or variables read in code with no source. Diff the resolved configuration of two environments, services or workloads.
- When to use it
- Useful when an assistant edits or reviews application configuration and needs to know what a variable actually evaluates to at runtime, which layer wins, or what breaks if a value changes. Also handy for auditing environment differences and spotting secrets or unset variables before deployment.
- Requirements
- Runs as a local process over stdio; install the npm package @patrizzos/envspeak globally and register the envspeak command. Reads .env files, Compose files and Kubernetes manifests under a project root, auto-discovered by default or scoped with a files list. No accounts, API keys or environment variables declared.
Installation
In SourceWeft
- Open Envspeak in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
README
EnvSpeak
MCP server and CLI that resolves config/env-var cascade across .env files, Docker Compose, and Kubernetes — tells AI agents (and you) what a variable actually evaluates to at runtime, and why.
Same problem shape as CSS cascade — several sources, non-obvious precedence rules, and a value that "wins" only because of where it's defined — applied to application configuration instead of stylesheets. A sibling project to stylesafe and stylespeak, which do the same thing for CSS.
The problem
A real app's config comes from .env, .env.local, .env.production, docker-compose.yml (environment: vs env_file:), Kubernetes ConfigMap/Secret objects, and hard-coded fallbacks in code — five-plus layers, each with its own precedence rules that don't compose the way you'd guess. The best-known gotcha: a plain .env.local overrides .env.production unless you also have a .env.production.local — because "local" outranks "environment-specific" in the conventional dotenv cascade. An agent editing config has no way to know what a variable actually resolves to, or what breaks if it changes one layer.
Tools
resolve_variable— what doesDATABASE_URLactually evaluate to, and which file wins?trace_variable— every place this variable is set, across every domain and environment.impact_preview— if I change this value in this file, what actually changes downstream — and what's shielded by something higher-precedence?config_manifest— a compressed, whole-project summary: every variable, its sources, and risk hotspots (secrets sitting in a tracked file, variables read in code with no fallback and no source anywhere).diff_environments— resolve every variable under two environments/services/workloads and see what's actually different between them.
Install
As an MCP server
As a CLI
If --files is omitted, envspeak auto-discovers .env*, Compose, and Kubernetes manifest files under --projectRoot (default: current directory). Pass --files a,b,c to scope it explicitly — recommended for MCP calls, so the agent controls exactly what's read.
Precedence conventions encoded
dotenv (Next.js/Vite-style, the de facto standard): process.env (shell) > .env.[env].local > .env.local > .env.[env] > .env > code fallback (process.env.X || 'default'). Note .env.local outranks .env.[env] — the gotcha above.
Docker Compose: docker compose run -e (CLI) > environment: > env_file: (last file in the list wins on conflicts) > Dockerfile ENV (not analyzed).
Kubernetes: inline env: always overrides envFrom: (bulk ConfigMap/Secret import; last entry in the list wins among those). Env values are frozen at pod start — editing a referenced ConfigMap/Secret does not reach a running pod without a restart or rollout. impact_preview flags this.
Every result includes a confidence level and a caveat string, because a shell-exported or CLI-passed override is always possible and never visible to static analysis — envspeak says so explicitly rather than pretending certainty it doesn't have.
Security
- Zero runtime dependencies. The YAML subset parser used for Compose/Kubernetes files is hand-written rather than pulled in from npm, so there's no third-party supply-chain surface.
npm auditis clean by construction. - Path-traversal guarded. File reads are resolved against
projectRootand refuse to escape it, even if a tool call is given a crafted relative path. - Prototype-pollution guarded. Object keys parsed from YAML content (
__proto__,constructor,prototype) are never used for property assignment. - Secrets are redacted by default. Kubernetes
Secretvalues are shown only asab***yz, never in full, regardless of which tool surfaces them. - Secret-likelihood heuristics. Variable names and value shapes (AWS keys, GitHub tokens, PEM blocks, high-entropy credential-shaped strings) are flagged, cross-referenced against
.gitignore, and surfaced as asecretFlag/ risk hotspot rather than silently passed through. - Bounded, non-backtracking regexes. Pattern matching used for code-default scanning caps match length and avoids nested quantifiers to avoid ReDoS on large files.
- Regardless of these guards, envspeak reads whatever files you point it at — scope the
fileslist an agent can pass, the same way you'd scope any tool with filesystem access.
Development
License
MIT
Source: README.md at commit e35621e
Tools
0Version history
1- v0.1.0LatestSep 16, 2026
Score
50% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 days25 pts
Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.
- Auth declared10 pts
Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts