Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

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

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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. status distinguishes actionable, uncertain, no-finding, and unavailable results. checked lists the bug categories the model reports having considered, so a clean file weighed against the whole catalogue is distinguishable from one where it stopped early; it is a self-report, and an empty list means no coverage was reported. Pass multi: true to get every finding the model can demonstrate, ranked, in a findings array instead of one verdict — experimental, and more findings per call is also more surface for false positives per call. Treat it as a defect only when actionable is true; that applies the measured score >= 0.7 precision gate. This spawns another model and takes 5-15 seconds, so only call it when you specifically want an independent second opinion. If you are yourself reviewing the code, use analyze_file and read the source instead. Reviewing several files? Pass them all as files in one call rather than calling once per file: the verdicts run concurrently, so the batch costs the same and takes about as long as a single file.

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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.4/5.0

Scored across 6 tools

Disambiguation4/5

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

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessUnresponsive