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
check_typesA

Return TypeScript compiler diagnostics for selected JavaScript/TypeScript files. Uses the full local project's declarations and settings, but reports selected files only. No model, emit, plugins or project code execution. Without a config, uses inferred null checking with JS checking. Reports skipped files, incomplete context and limits; no diagnostics is not proof of runtime safety.

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. actionable applies the measured score >= 0.7 precision gate. uncertain names a candidate the reviewer could not confirm: read its cited lines before dismissing it, and report it only if you confirm it yourself. 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: small files share bounded model calls to reduce repeated CLI context. Groups run concurrently, with individual verdicts and explicit failures.

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 7 tools

Disambiguation5/5

Each tool targets a distinct granularity or data source: check_types (compiler diagnostics), analyze_file (single-file metrics), scan_project (whole-tree ranking), map_dependencies (import graph), analyze_logs (log lines), list_providers (environment probe), and predict_failures (model verdict). The descriptions explicitly clarify the boundary between analyze_file and predict_failures, and between scan_project and analyze_file, removing overlap.

Naming Consistency5/5

All seven tools follow a consistent snake_case verb_noun pattern (check_types, map_dependencies, analyze_file, scan_project, analyze_logs, list_providers, predict_failures). Verbs are predictable and nouns name the resource clearly.

Tool Count5/5

Seven tools is well-scoped for a predictive debugging server, covering static analysis, dependency mapping, logs, environment probing, and model-based prediction without redundancy. Each tool earns its place with a clear role in the workflow.

Completeness4/5

The surface covers the debugging lifecycle well: project triage, per-file analysis, dependency context, logs, provider diagnostics, and independent failure prediction. Minor gaps exist, such as no way to read raw file content or validate configuration directly, but agents can work around these with standard file access.

Maintenance

ActivityActive
ResponsivenessUnresponsive