decisions-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DECISIONS_MODEL | No | Default decision model (any id from list_models). | typesafe/jev-1.13 |
| DECISIONS_BASE_DIR | No | What relative paths resolve against. Defaults to workspace root from MCP roots, else cwd. | |
| OPENROUTER_API_KEY | Yes | OpenRouter API key (a regular key from openrouter.ai/keys; a management/provisioning key won't work). Required. | |
| DECISIONS_MAX_FILES | No | Limits for file collection (max number of files). | 2000 |
| DECISIONS_MODELS_URL | No | Where context sizes and prices are read from. | OpenRouter decision-model catalog |
| DECISIONS_TIMEOUT_MS | No | Per-request timeout. | 120000 |
| DECISIONS_CONCURRENCY | No | Parallel requests to Jev. | 8 |
| DECISIONS_ALLOWED_ROOTS | No | Restrict reading to these directories (':'-separated). | |
| DECISIONS_ALLOW_SECRETS | No | Set to 1 to stop excluding .env, keys etc. (not recommended). | |
| DECISIONS_DECISIONS_URL | No | Decisions API endpoint. | https://openrouter.ai/api/alpha/decisions |
| DECISIONS_MAX_FILE_BYTES | No | Limits for file collection (max file bytes). | 1000000 |
| DECISIONS_FALLBACK_MODELS | No | Comma-separated backups tried in order if the primary model fails. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| locate_in_filesA | Find which files and lines most likely contain what you describe — the cause of a bug from its symptoms, the code implementing a feature, where a setting is defined. Pass 1: every file is split into chunks and ALL chunks are scored by the decision model (nothing is truncated; very cheap even for megabytes). Pass 2: the best chunks are re-scored in small line windows to pinpoint the lines. Returns ranked file:line ranges with probabilities, a per-file ranking and the code of the top locations, so you can go straight to the fix. |
| classify_filesA | Classify every file in the given paths into your labels with a decision model (one very cheap request per file, calibrated confidence). Returns files grouped by label. Good for triage: tests/configs/dead code, sorting documents by topic, flagging files about X. Label descriptions after a colon noticeably improve accuracy. |
| decide_filesA | Ask several typed questions about EACH file with a decision model: yes_no flags, one-of choices and ordered scores, with calibrated probabilities. Example: for every file decide uses_db (yes_no), layer (choice: api/domain/ui/infra), complexity (score: low/medium/high). Use only_matching to return just the files where a yes_no question is yes. |
| list_modelsA | List the decision models available on OpenRouter (id, context window, input price) and which one is the default. Pass an id as |
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 4 tools
locate_in_files and list_models are clearly distinct, but classify_files and decide_files overlap: classification is effectively a one-question decision, so an agent must read carefully to know which to pick for a single-label vs multi-question pass. The descriptions do clarify the intended boundary (grouped label output vs typed yes_no/choice/score answers), so confusion is limited rather than pervasive.
All four tools are snake_case verb-first names (classify_files, locate_in_files, decide_files, list_models) with a predictable verb + target pattern. list_models is the only one not scoped to 'files', but it follows the same convention and is semantically clear.
Four tools is a tight, well-scoped surface: three file-analysis operations plus a model-discovery utility that enables the others. Each tool has a distinct role and none feels redundant or bolted on.
The core workflow of triage (classify), structured interrogation (decide), and pinpointing (locate) is covered, with list_models to support model choice. Minor gaps exist: no direct way to inspect raw file contents outside results, no aggregation/summary across the outputs of multiple passes, and no mechanism to persist or reuse a named question set.