Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
CULPRIT_BASENoThe base branch for comparison (default: origin/main or HEAD~1).
GITHUB_TOKENNoGitHub token for authenticated API calls to raise rate limits.
GITLAB_TOKENNoGitLab token for authenticated API calls to raise rate limits.

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": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
analyzeA

Full RCA in one call: classify -> suspects (bugfix) or blast-radius (feature) -> risk score -> test impact.

Returns the complete structured result. Use the individual tools to drill into specific signals.

classify_changeC

Classify whether a change is a bugfix or a feature, with evidence.

Returns: {verdict: "bugfix"|"feature"|"unknown", evidence: [...], signals: {...}}

find_suspectsA

Find the commits most likely to have introduced a bug.

Pass trace_text (a stack trace / crash log) to run RCA from a runtime error with no diff needed. Otherwise diffs base..head to find suspects.

Returns: {suspects: [{hash, short, author, date, subject, pr_number, weight, lines}], origin_on_branch: bool, notes: [...]}

get_blast_radiusB

Map what a feature change affects: who imports the changed modules, covering tests, high-risk areas.

Returns: {dependents: {...}, covering_tests: [...], high_risk: [...], notes: [...]}

get_risk_scoreB

QA risk score for a change: 0-100 with level (low/medium/high) and contributing factors.

Combines test gap, fix completeness, hotspot recurrence, blast radius, and churn.

Returns: {score: int, level: "low"|"medium"|"high", factors: [{name, detail, points}]}

get_evolutionA

git log -L over a line range: every commit that touched those lines, oldest to newest, with per-step diffs.

Returns: {steps: [{hash, short, author, date, subject, diff}], notes: [...]}

get_intentB

Commit body + the PR it came from (title, body, url) + linked issues (Fixes/Closes/Resolves #N).

Returns: {body: str, pr: {number, title, body, url} | null, linked_issues: [...]}

check_completenessA

Is the fix complete? Find other references to changed symbols not touched by this fix.

Returns: {symbols: [...], other_call_sites: {...}, untouched_count: int, adds_test: bool, is_revert: bool, notes: [...]}

get_test_impactA

Which existing tests should be run for this change.

Walks the reverse-import graph from changed files to tests that cover them directly or transitively (up to 2 hops).

Returns: {tests: [...], by_test: {test: [reasons]}, notes: [...]}

from_traceA

RCA from a stack trace or crash log; no diff or PR needed.

Parses the stack trace, blames the crashing lines in git history, and returns the suspect set. Works for Python, JavaScript, Java, and Go stack traces.

Returns: {suspects: [...], frames: [{file, line, func}], skipped_frames: [...], notes: [...]}

verify_fixA

Check fix completeness against a raw unified diff before committing.

Runs completeness + test-impact analysis on the proposed diff and returns a verdict. Iterate until verdict == "complete" (no untouched call sites). "complete" covers the root cause but does not imply a test exists - a complete but untested fix comes back at risk_level "medium" with a note, so check risk_level/notes and add the test before committing.

Returns: {verdict: "complete"|"partial"|"risky", symbols_fixed: [...], untouched_references: [...], tests_to_run: [...], adds_test: bool, risk_level: "low"|"medium"|"high", notes: [...]}

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

B3.3/5.0

Scored across 11 tools

Disambiguation2/5

Several tool pairs have overlapping responsibilities: from_trace and find_suspects both take a stack trace and return suspects, verify_fix and check_completeness both assess fix completeness, and get_test_impact/get_blast_radius both surface covering tests. The descriptions are detailed, but an agent could easily select the wrong tool for the same underlying task.

Naming Consistency3/5

Most names are lowercase snake_case verb_noun, but the verbs are inconsistent across get_, classify_, find_, check_, verify_, and two tools break the pattern entirely: from_trace and analyze. The naming is readable but not predictable enough to be considered a consistent convention.

Tool Count4/5

Eleven tools is within a reasonable range for a change-analysis server, but the set is slightly larger than necessary because some tools duplicate or wrap each other's functionality. It is not bloated, just a bit redundant.

Completeness5/5

The tool surface covers the full RCA workflow: classify, identify suspects, map blast radius, compute test impact, score risk, verify completeness, inspect evolution, and read intent. The analyze tool also provides an orchestrated end-to-end path, while individual tools allow drilling into specific signals without obvious dead ends.

Maintenance

ActivityMaintained
ResponsivenessNo issues