predictive-debugger
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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 |
|---|---|
| map_dependenciesA | Find a file's local imports, reverse imports and tests connected by imports. Each relationship includes a source path and line as evidence. Static file relationships, not runtime callers or test coverage. Scans JavaScript/TypeScript including tests, with bounded work and explicit unresolved imports and scan limits. Deterministic; no provider call. |
| analyze_fileA | Return static complexity metrics and a heuristic risk score (0-1) for a single JavaScript or TypeScript file. Deterministic and fast — no model call. Call this when reviewing a file to find out where the structural risk sits (nested loops, long functions, async boundaries, unguarded mutation) before reading the whole file yourself. |
| scan_projectA | Walk a directory and rank its JavaScript/TypeScript files by risk density — how concentrated the failure-prone code is, not how big the file is. Test files are left out by default; pass includeTests to rank them too. Deterministic and fast — no model call. Call this at the start of a code review to decide which files are worth your attention, instead of reading the tree in arbitrary order. |
| analyze_logsA | Score a log file's lines by severity and how unusual their wording is, and return the anomalies, worst first. Deterministic — no model call, no API key. Call this when you have a log file and want the handful of lines worth reading rather than the whole file. |
| predict_failuresA | Combine static analysis with a second-opinion verdict from the signed-in Claude Code, Codex, or GitHub Copilot CLI, returning the most likely runtime failure with a line number and reason. |
| list_providersA | Report which supported CLIs (Claude Code, Codex, GitHub Copilot) are installed and signed in. Call this to diagnose why predict_failures is failing. |
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
Most tools have clearly distinct scopes: dependencies, single-file metrics, project-wide ranking, log anomaly detection, provider diagnostics, and model-backed failure prediction. The only minor overlap is between analyze_file and scan_project (both assess risk, but at different granularities) and predict_failures (which uses a model for verdicts).
All six tools follow the same verb_noun snake_case pattern: map_dependencies, analyze_file, list_providers, scan_project, analyze_logs, predict_failures. No mixed conventions, aliases, or inconsistent verb choices.
Six tools is a well-scoped size for a predictive debugger. Each tool covers a distinct part of the workflow (dependency mapping, file analysis, project scanning, log analysis, provider setup, and failure prediction) without bloat or redundancy.
The tool surface covers the full predictive debugging workflow: scan to find risky files, analyze individual file risk, map dependencies for context, read logs for runtime anomalies, and get model-backed failure predictions. Minor gaps exist—no tool to directly inspect test coverage or historical failures—but these are workable around.