Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
--dirNoThe 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

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}

Tools

Functions exposed to the LLM to take actions

NameDescription
env_overviewA

Map every environment-variable source under a folder. Finds .env, .env.local, .env., templates (.env.example/.sample/.template), docker-compose environment:/env_file:, and CI workflow env: blocks; groups them by env root (a monorepo has several) and reports variable counts, duplicates, syntax problems, BOM/CRLF, and which framework client prefixes (VITE_, NEXT_PUBLIC_, ...) are in use. Never shows values. Start here.

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 # optional comment above a template line exempts it), duplicated names, and values whose type differs from the template's. Commented-out template lines (# NAME=) count as documented.

path: folder to scan. file / against: compare two specific env files instead (paths relative to path), for example file=".env.production", against=".env.example".

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 path).

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 git check-ignore, git ls-files and git log --all by file name only: no content is read, no history is rewritten. Also flags a template that is itself ignored. Requires git on PATH.

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 NAME= with nothing after the equals sign: no value, not even from your templates. Nothing is written to disk; paste or save the text yourself.

path: folder to scan.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.2/5.0

Scored across 6 tools

Disambiguation5/5

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.

Naming Consistency4/5

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.

Tool Count5/5

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.

Completeness5/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo recent community issues