envdoctor-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| --dir | No | The path to the project directory the server is allowed to read. The server can read nothing outside it. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Diagnose environment-variable problems in a project. Read-only, and values are never shown: you get variable names, line numbers, lengths and type guesses. Start with env_overview, then compare_env (.env vs .env.example), find_usage (which variables the code reads, and which are undocumented), validate_env (placeholders, bad URLs/ports, whitespace and quoting mistakes, secrets exposed to the browser), check_gitignore (is .env ignored, tracked, or in history) and generate_example (a safe .env.example proposal as text). All paths are relative to the server's --dir sandbox.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| env_overviewA | Map every environment-variable source under a folder. Finds .env, .env.local,
.env., templates (.env.example/.sample/.template), docker-compose
path: folder to scan, relative to the server's --dir sandbox (default: the whole sandbox). |
| compare_envA | Compare .env with its template (.env.example/.sample/.template) in every env root.
Reports names missing from .env, extra names the template does not document, variables
empty in .env but required by the template (a path: folder to scan. file / against: compare two specific env files instead (paths
relative to |
| find_usageA | Scan source code for environment reads and cross-check them with the templates. Understands process.env.X / process.env["X"] / destructuring, import.meta.env.X, Deno.env.get, os.environ[...] / os.environ.get / os.getenv, ENV['X'] / ENV.fetch, std::env::var / env!, os.Getenv / os.LookupEnv, System.getenv, Environment.GetEnvironmentVariable, getenv / $ENV / Laravel env(), System.get_env, Prisma env(), and ${X} in compose files. Reports variables used in code but undocumented in the template (with file:line), documented but never read, and client-exposed secret-looking names. Ambient variables (PATH, HOME, NODE_ENV, GITHUB*) are ignored. It is a text scan: reads inside comments count, dynamic names (process.env[name]) are invisible. path: folder to scan, relative to the sandbox. |
| validate_envA | Check env files for mistakes, from names and shapes only (no value is ever printed). Flags: placeholders (changeme, your_key_here), empty values, trailing whitespace, unquoted spaces, CRLF, a BOM, values wrapped in literal quotes, undefined ${REF}s, duplicates, syntax errors; names that promise a type but disagree (*URL not a URL, *PORT out of range, booleans, integers, emails, JWTs, *PATH that does not exist); localhost URLs in production files; real-looking secrets inside a template; and secret-looking names with a browser-exposed prefix (VITE, NEXT_PUBLIC, REACT_APP, ...). path: folder to scan. file: validate only this env file (relative to |
| check_gitignoreA | Is each real env file safe from git? For every .env/.env.* file (templates excluded) says
whether it is ignored, tracked, or present in any commit on any branch, and lists env files
that were committed once and deleted (still in history). Uses path: folder inside the repository to check. |
| generate_exampleA | Propose a safe .env.example as text (one section per env root). It lists every variable
seen in env files, templates and source code, each with a type hint, whether it looks
secret, where the code reads it, and a warning if a secret would be exposed to the browser.
Every line is path: folder to scan. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Each tool has a clearly distinct role: overview, template comparison, source-code usage scanning, validation, git safety, and example generation. Overlap in reported issues is minimal and the descriptions make boundaries explicit, with env_overview marked as the starting point.
All names use consistent snake_case and are readable. Most follow an action_object pattern, though env_overview is noun-based rather than verb-based, a minor deviation.
Six tools is well-scoped for an environment-file auditing server. Each tool covers a distinct workflow and none feels redundant or missing from the core purpose.
The surface covers discovery, template comparison, code usage cross-checking, validation, gitignore safety, and safe example generation. For a read-only env auditing tool, this is a complete lifecycle without obvious dead ends.