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
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
get_next_itemA

Returns the next function to fix as a work packet, the newest trusted run's worst row by crap. Use it to start a fix, list_worklist to survey the same run by risk, and get_function_brief once a function is chosen. It runs no tests, and empty true means the queue is spent, not the work, so read reasons. Filters cut before top counts: top 3 with exclude ["tests/"] returns the three worst rows outside tests, and an unknown scope name is a config error.

list_worklistA

Lists the newest trusted run's whole risk ranking, every admitted function ordered by ccn times recency-weighted churn. Use it to survey a repo or split work by file, and get_next_item for the one crap-ranked packet to fix now. It runs no tests, keeps finished rows so it never empties, and reads the churn cache, not git. scope narrows before top caps, so scope ["core"] with top 20 returns the 20 riskiest in core, an unknown scope name is a config error, and repo may be any directory under the measured checkout.

list_runsA

Lists every run in the store, oldest first by id. Use it to date the store or to see which commit the other tools answer from. Use get_trend for per-run totals and get_function_history for one function's scores per run. It reads the store only and spawns no git. repo may be any directory under the checkout, because the server walks up to the nearest crapkit.toml, and a relative path resolves from the server's start directory. No crapkit.toml above it answers an init pointer, and a checkout never scored answers a coverage pointer, both as isError true.

get_trendA

Returns per-run totals for every trusted run, oldest first, with a grade per scope. Use it for the whole repo's trajectory. Use get_function_history for one function and get_ratchet_report for marked debt. It runs no lane and spawns no git. The first call on a large store sums every run into a rollup cache and takes seconds. Later calls read the cache back. repo may be any directory under a checkout where crapkit init and crapkit coverage have run. An unmeasured one answers isError true with the setup pointer.

get_function_briefA

Returns one function's start-editing packet from the newest trusted run: scored row, uncovered lines and the refresh, test, gate and verify command lines, none of them run. Use it once a function is chosen. Skip it for picking what to fix, that is get_next_item, and for a score across runs, get_function_history. Every call shingles the repo for twins, seconds on a large corpus. name must live in path. name takes the long name, a bare identifier, a start line or NAME#2, exact match first. A miss lists the file's functions instead of erroring.

get_function_historyA

Returns one function's ccn, coverage, crap and flag in every run that measured it, oldest first, plus its ratchet mark. Use it to tell improving from decaying or regrown, and get_function_brief instead to start an edit. history true spawns git log -L capped at 10 commits, and tests true is null unless the lane recorded contexts. name resolves off the newest run that scored path, so a substring such as "eval" fans out to one entry per long name matched, and repo may be any directory under the measured checkout.

check_configA

Checks that crapkit.toml agrees with the repo: typo keys, empty scopes, missing lane cwds, runners that fail to start. Run it first when any tool answers strangely or the ranking misses a file, and list_runs when only the history is in question. It needs no run, probes each runner once, runs no lane, and any problem arrives with isError true. repo can be any directory under the checkout, and one with no crapkit.toml above it answers a pointer, never a parent's config.

list_coupled_filesA

Lists file pairs that keep landing in the same commits over the churn window, strongest first, at most 50. Use it before editing a file to learn what an edit drags along. Use list_duplicate_functions for copied code rather than co-change. It reads git log once per call, not the scored run. An empty list means no pair cleared both thresholds, not a missing run. A pair must clear both thresholds: min_support 5 needs five shared commits, min_confidence 0.5 means the rarer file moved with its partner half the time. repo defaults to the server's own root.

list_duplicate_functionsA

Lists near-duplicate function pairs in the newest run, at most 50. Use it before a refactor so twins are folded together, and get_function_brief for one function's twins. It shingles source on every call, seconds on a large repo, skips functions under 8 lines and same-file pairs, and an empty list means no pair reached similarity. similarity is shared shingles over the smaller function: 1.0 admits only a function found whole inside another, 0.8 four lines in five, and repo may be any directory under the checkout.

get_ratchet_reportA

Reports the ratchet debt burn-down: open marks with their age, repayments and policy findings. Use it to judge whether marked debt is repaid or piling up, and get_function_history for one function's mark. It reads the marks file and its git log only, ages count back from the newest commit touching that file, never the clock, and no marks file means zeros. repo can be any directory under a measured checkout, and an unmeasured one answers isError true with the setup pointer.

check_gateA

Checks whether an edited file clears the hook's commit gate: fresh ccn per changed function against its scope's ceiling less pardoned ratchet debt. Call it after an edit once get_function_brief states the rule. CLI verify gives the repo-wide verdict. It runs no tests, and a breach reads gate.ok false, not an error. path is repo-relative or absolute inside repo, outside or missing is a config error. A tracked file is judged on its diff from HEAD, an untracked one in full, an unchanged or unscoped one judges 0. repo may be any directory under the checkout.

list_claimsA

Lists open claims on queue items, oldest first. Use it when get_next_item answers empty or skipped_claimed above 0, and use get_function_brief to see one function's own attempts. No tool here writes a claim: the CLI releases a stale one with crapkit claims release PATH NAME, and verify closes one at the ceiling. repo may be any directory under the checkout, since the server walks up to the nearest crapkit.toml. No crapkit.toml above it answers an init pointer, and a checkout never scored answers a coverage pointer, both as isError true.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.9/5.0

Scored across 12 tools

Disambiguation5/5

Each tool targets a distinct operation: history, gate, next item, worklist, brief, config, ratchet, trend, claims, coupling, duplicates, and runs. Even similarly named get_function_history and get_function_brief are clearly separated by context (across-run history vs edit-start packet).

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case: get_ for single-item retrieval, list_ for enumerations, and check_ for validations. There are no mixed conventions or vague verbs.

Tool Count5/5

12 tools is well within the ideal 3-15 range. Each tool covers a distinct aspect of the code-quality analysis domain (metrics, queue, config, coupling, duplicates) with no redundancy or bloat.

Completeness5/5

The surface covers all major read-only workflows: function inspection, work selection, trend analysis, gate checks, config validation, and structural analysis (coupling/duplication). Write operations like releasing claims or running tests are intentionally CLI-side, so there are no obvious gaps for the server's role.

Maintenance

ActivityMaintained
ResponsivenessResponsive