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

Tools

Functions exposed to the LLM to take actions

NameDescription
get_answerA

Answer a how, where, or why question in one evidence-grounded call.

High confidence is content-grounded and may be used directly. Medium
confidence keeps the smallest verification evidence; low confidence leads
with an actionable local conclusion and ranked evidence. Provider keys and
network access are optional: local source, symbols, FTS, rationale, and
data-shape evidence remain usable when embeddings or synthesis fail.

Responses fit 24,000 serialized characters. Pass ``include=["evidence"]``
for the deduplicated expanded projection, capped at 32,000. Reductions carry
totals, emitted counts, reasons, and an exact one-call recovery.

Args:
    question: Developer question.
    scope: Optional repository-relative path prefix.
    repo: Usually omitted; a workspace alias when needed.
    include: Optional ``["evidence"]`` expanded projection.
get_change_riskA

Review a commit, base..head range, or uncommitted work.

Leads with ``directive`` (what to do) and ``health_delta`` (what this
change newly made worse). A finding is reported only when the diff explains
it, and each names its ``attribution`` basis; findings the change wrote
sort above pre-existing ones it only touched.

Trust ``health_delta.status``: ``partial`` means files were skipped and the
change is not cleared.

``impacted_tests`` keeps measured coverage and inferred candidates distinct.
``fix_history`` is the changed files' bug-fix record, ``overlap`` the past
fixes on these exact lines. ``branch_overlap`` names other branches editing
them. ``diff_shape`` is one line on size, not a danger verdict. An empty
diff returns ``status: "nothing_to_score"`` and names the tree it read.

Args:
    revspec: Commit or ``base..head`` range. Omit to review uncommitted
        work, or ``HEAD`` when the tree is clean.
    repo: Repository alias in workspace mode; omit for the default.
    extensions: File suffixes to count, e.g. ``[".py", ".ts"]``.
    exclude_patterns: Gitignore-style paths to omit, e.g. ``["tests/"]``.
    baseline: Recent commits sampled for percentile ranking; 0 disables it.
    include: ``"findings"`` for every change finding, ``"diagnostics"`` for
        raw score mechanics, ``"scales"`` for units. All identical on
        repeat, so ask once.
    finding_id: Expand one ``health_delta`` finding by its id.
get_contextA

Triage card for files / modules / symbols — relationships, not source bytes.

Returns title, summary, signatures with line numbers, hotspot bit, and
decision_record titles. fix_history appears only on files with counted bug
fixes (count, age, bug_magnet); hotspot is churn. Either one is a cue to
call get_risk. episodes counts the dated records bound to a target — what
happened here and why — and appears only when there is at least one;
get_why serves the bodies. A symbol target is counted as its file, and a
module aggregates everything beneath it.
Batch targets in one call. No source bytes by default: pass
include=["skeleton"] for the whole file body-elided and line-verified in
ONE call, or Read it. Do not call get_symbol per signature.

Default responses fit 24,000 serialized chars; nonempty ``include`` uses
32,000. Reductions carry counts and ``_meta.omitted`` recovery refs;
``_meta.recovery_unavailable`` names a storage failure.
Include-gated blocks are projections, not omissions.

Args:
    targets: file paths, module paths, or "path::Symbol" ids.
    include: opt-in blocks: full_doc | ownership | last_change | callers
        | callees | metrics | community | decisions | skeleton | health
        | doc_drift (documents naming this file).
        An unrecognised key is named in ignored_arguments.
    compact: default True; False adds structure+imports+docstrings.
    repo: usually omitted.
get_dead_codeA

Unused exports, unreachable files, zombie packages — tiered by confidence.

Run before a cleanup sprint, not a targeted fix. Findings tier
high/medium/low with per-directory and per-owner rollups; workspace
mode lowers confidence on findings other repos import.

Args:
    repo: usually omitted.
    kind: unreachable_file | unused_export | unused_internal | zombie_package.
        An unrecognised value is dropped and named in ignored_arguments,
        never applied as a filter that matches nothing.
    min_confidence: floor, default 0.4 (0.7 = cleanup-ready only). Also
        accepts a tier name: "high" (0.8) | "medium" (0.5) | "low" (0.0).
    safe_only: deletion-ready findings only (no runtime-load risk).
    limit: max findings per tier (clamped to 25).
    tier: "high" (>=0.8) | "medium" | "low".
    directory: path-prefix filter.
    owner: primary-owner filter.
    group_by: "directory" | "owner" rollup.
    include_internals: also scan private symbols (more false positives).
    include_zombie_packages: monorepo package findings (default true).
    no_unreachable: skip file-level reachability findings.
    no_unused_exports: skip public-export findings.
    finding_id: stable ``id`` emitted by a dead-code finding.
get_healthA

Code-health scores and findings from stored analysis.

No ``targets`` returns a dashboard; targets rank files and findings.
Never recomputes health: commit, then run ``repowise update``.
Every block and accepted value: docs/agent/MCP_TOOLS.md.

Args:
    targets: file paths or ``module:<name>``; unmatched ones land in
        ``unresolved``.
    include: ``biomarkers``|``refactoring``|``trend``|``coverage``|
        ``accuracy``|``signals``|``churn_complexity``|``doc_drift``,
        or a dimension incl. ``advisory``; ``performance`` and
        ``refactoring`` add queues.
    only: keys to keep; identity, totals, recovery survive.
        ``biomarkers``/``accuracy``/``refactoring`` alias their block key;
        ``performance``/``defect``/``maintainability``/``advisory``
        do not: they filter rows into ``unknown_only_keys``.
    repo: usually omitted.
    limit: max rows per ranked list, ``0`` for none.
    cursor: zero-based offset into a ranked list.
    finding_id/plan_id: stable ``id`` from a finding or plan.
    opportunity_id: ``perf...``/``refop...``: the unit, its steps or
        plan, evidence paged by ``only=["*_evidence"]``.
    refactoring_view: ``diversified`` (default)|``canonical``|
        ``file_spread``; _type/_confidence/_effort filter.
    performance_view/_context/_boundary/_confidence/_sort: queue
        projection and filters; the facets list them.
    scope / counts: default ``all``/``everything``. ``production`` drops
        test files; ``code_shape`` drops the git-derived half of the
        score and its findings.
get_overviewA

Architecture map for an unfamiliar repo — first call when you don't know your way around.

Returns the synthesised overview summary, key modules, entry points,
architecture layers, code health, and repo-wide git health (hotspot count,
churn trend, bus-factor distribution).
Skip this on subsequent calls — once you have the map, jump straight to
``get_context`` / ``get_answer``.

Compact by default: ``content_md`` carries only the overview essay's summary
section, and the outline, onboarding, ownership and graph blocks ship only
on request. The response's ``more`` field names them.

Defaults fit 24,000 chars; nonempty ``include`` uses 32,000. Reductions
carry counts and recovery status in ``_meta``.
Include-gated blocks are projections, not omissions.

In workspace mode:
- Omit ``repo`` for the default repo's overview plus a workspace footer.
- ``repo="all"`` returns the cross-repo topology (co-changes, package deps,
  API contracts) — no single-repo detail.
- ``repo="<alias>"`` targets one specific repo.

Args:
    repo: Repository alias, path, or ID. Use ``"all"`` for workspace overview.
    include: Opt-in extras, any combination of:
        ``"content"`` — the full overview essay instead of its summary.
        ``"outline"`` — the stored wiki page tree, two rungs deep.
        ``"tour"`` — ``guided_tour`` + ``reading_order`` onboarding walks.
        ``"decisions"`` — ``key_decisions``; ``get_why`` is richer.
        ``"graph"`` — ``community_summary``, code-community clusters.
        ``"ownership"`` — ``knowledge_map``: top owners, knowledge silos.
get_riskA

What history says about touching these files — bug fixes, churn, owners.

Fuses git temporal signals (``hotspot_score``/``owner_pct`` are 0-1; trend;
bus factor) with graph topology. ``dependents`` are directed structural
reach (source depends on target), ``consumers`` require typed contract links,
and ``co_change_partners`` are historical correlation only. Those counts
are a floor over the indexed graph. Structural reach is not proof of
runtime breakage. The response also includes security
findings. Pass changed_files for PR mode: the response leads with a
directive block (may_break, missing_cochanges, missing_tests,
tests_to_run) — read it first. Each test_recommendations row carries a
measured or inferred basis, and coverage availability is explicit. To
score a commit or ``base..head`` range instead, use ``get_change_risk``.

In PR mode ``structural_impact_score`` is an uncalibrated 0-10 structural
heuristic, never a runtime-breakage probability; ``overall_risk_score`` is
its deprecated exact alias.

Default responses fit 24,000 serialized chars; nonempty ``include`` uses
32,000. Reductions carry counts and ``_meta.omitted`` recovery refs;
``_meta.recovery_unavailable`` names a storage failure.
Include-gated blocks are projections, not omissions.

Args:
    targets: file paths to assess.
    repo: usually omitted.
    changed_files: PR-changed files for blast-radius mode.
    include: opt-in blocks - "graph", "churn", "scales" (units and
        calibration for every scalar; identical per call, so ask once).
get_symbolA

Follow-up read of one symbol whose id another response already gave you.

**Not an entry point.** ``get_answer`` already ships ``symbol_bodies``, and
for a whole file ``get_context(include=["skeleton"])`` or a plain Read is
one call instead of many. Reach here for a body that was elided, or for a
``continuation`` / omission ref. Never walk a file symbol by symbol.

Returns verified, line-numbered source for one indexed symbol, live range,
or omission ref. Ambiguity returns every candidate; an index miss returns
live fallback lines. A truncated result carries the exact continuation to
pass straight back.

Args:
    symbol_id: "path/to/file.py::Name", "path/to/file.py:140-180" for a
        live range, or an omission ref.
    context_lines: extra lines before/after (0-50).
    repo: usually omitted.
    query: omission refs only, regex/substring filter on lines.
    id: accepted alias for ``symbol_id``.
    depth: 1 (default) is this symbol alone; 2-3 also returns the bodies
        it calls, transitively, in ``callee_bodies``.
    reference: structured source reference emitted by this tool. Its id
        and repository are accepted together without caller translation.
get_whyA

Why this code is shaped this way — decision records + evidence commits.

Call before refactors or pattern divergences. Query modes: a question
("why is auth using JWT?"), a file path (governing decisions + origin
story + alignment score), a question anchored to targets, or no query
(decision health dashboard). Falls back to git archaeology when no
decisions exist for a path — never empty. Evidence-bearing rows carry an
explicit ``provenance`` and self-contained ``evidence_refs``; matching ids
mean shared evidence, not independent corroboration. Every decision row
carries ``authority``: ``accepted`` means somebody signed it, ``candidate``
means nobody has yet. ``answer_basis`` names the strongest lane the response
rests on (decision, episode, rationale, archaeology, documentation,
candidate); only ``decision`` is a ruling, and ``candidate`` is the weakest
-- it means nothing cleared that bar.

Args:
    query: question, file/module path, or omit for the dashboard.
    targets: optional file paths to anchor the search, or to ask about on
        their own when there is no query.
    repo: usually omitted.
    id: decision or ``ev_...`` evidence id emitted by this or another tool.
    reference: structured evidence reference. Its id and repository are
        accepted together without caller translation.
search_codebaseA

Find code by concept, symbol, or path — hybrid codebase search.

For QUESTIONS ("how does X work", "where is Y handled", "why is Z like
this"), call get_answer instead: it runs this same hybrid retrieval
internally and synthesizes a cited answer, so searching first is a wasted
round-trip. Use this tool when you want the raw ranked hits themselves —
enumerating matches, resolving an identifier to a symbol_id, or scoping a
later get_context call.

mode="auto" (default) routes the query: identifier-shaped queries search
the indexed symbols (returns symbol_id/file/line bounds — pipe into
get_symbol), path-shaped queries resolve files (pipe into get_context),
and conceptual queries run wiki-semantic search. Mixed queries run hybrid,
symbol hits first. Decision records rank below file pages unless the query
is why-shaped.

`candidates` lists up to `limit` distinct openable file paths, best first.
Some results are pages, not files; this is what to Read.

Args:
    query: identifier, path, or natural-language query.
    limit: max results (default 5).
    page_type: restrict to one page type. Common: file_page (per-file
        docs, always present) or module_page (subsystem/concept pages).
        Any stored type filters (repo_overview, layer_page, scc_page,
        api_contract, infra_page, symbol_spotlight).
    kind: implementation | test | config | doc (concept/symbol modes).
    repo: alias, or "all" for workspace-wide.
    mode: auto | concept | symbol | path | hybrid.
    symbol_kind: filter symbol hits by kind (function|class|method|...).

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.6/5.0

Scored across 10 tools

Disambiguation5/5

Each tool targets a distinct analytical concern: health scores, change risk, context triage, decision rationale, question answering, dead code, overview, history risk, symbol bodies, and raw search. Where overlap exists (get_answer vs get_why vs search_codebase, get_health vs get_risk), the descriptions explicitly carve out boundaries and direct callers to the right tool.

Naming Consistency4/5

Nine of ten tools follow a consistent get_<subject> pattern, making the set predictable and easy to navigate. search_codebase breaks the pattern slightly, though it is still readable and uses a clear verb-object structure.

Tool Count5/5

Ten tools is well-scoped for a code intelligence and health analysis server. Each tool covers a distinct capability with no obvious redundancy, and the count is squarely in the comfortable range for an MCP server.

Completeness5/5

The surface covers the full read-only exploration lifecycle: orient with get_overview, search with search_codebase, answer questions with get_answer, drill into context/symbols, assess health/risk/dead code, and understand rationale with get_why. There are no obvious dead ends, and the tools are designed to chain together coherently.

Maintenance

ActivityActive
ResponsivenessResponsive