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
project_queryA

Where is X / what handles Y: ranked code locations as plain text (path:lines headers, call outlines, numbered source lines; up to 6000 chars, truncation stated). format='json' for programs. Hits are leads, not verified claims.

index_updateA

Re-index after editing files (on a folder never scanned: the first scan); claims whose files changed become stale. mode: noop | incremental | full | first_scan.

analyzeA

Answer a question as claims with evidence: one verdict per sub-question, claims with file:line, unknowns with next steps, and the passages. needs_clarification is a normal result (ask the user). run_tests / observe also run or trace the tests that reach the answer (isolated copy). Re-indexes first if the tree changed.

code_checkA

Python, Java, Kotlin, TS/JS imports; other languages: not_checked (exit 4). For code you wrote or edited: do the modules, names, methods, arguments and keys it uses exist in the project and its environment? Input: paths, diff (a revision; nothing: changes against HEAD), or snippet + as_path. Each site: exists | absent (nearest names) | unknown | not_installed | guarded; exit 3 = absent.

run_toolB

Run one more Verinoda tool (name, arguments). node_inspect {name}: a symbol's definition and edges with file:line; relation_trace {source, target, mode?: flow|any}: call paths between symbols; map_view {view: hierarchy|dependencies|dataflow|config|tests|history|impact|cycles|outline|dead|hotspots|sides|repo|saved, targets?}; claim_list {status?}, claim_inspect {claim_id}, evidence_inspect {evidence_id}: earlier claims, evidence re-checked; change_review {targets?, change?: body|signature|remove} before editing, {since_last?} after: what it touches; history_search {text, regex?, path?}: when text came/went; {symbol}: its commits; {message?, author?, since?, until?, diff?, path?}: commits; {base, head?}: compare.

Prompts

Interactive templates invoked by user choice

NameDescription
reviewReview the working-tree change (or the change since base): what it touches, names that do not exist, decision records, dependents.
onboardingGet to know the project (or one topic in it): structure, dependencies, tests, then how it works as claims with evidence.
debugDebug a failure: locate the code the symptom names, ask why, then record every fix attempt against one repro.
pre_mergeCheck a branch before merging into base: commits and files it adds, what they touch, names, dependencies, decision records, cycles.

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.6/5.0

Scored across 5 tools

Disambiguation3/5

project_query and analyze both answer code questions, with project_query focused on ranked locations and analyze on claims/evidence, but the boundary is not always clear. The run_tool meta-tool bundles many sub-operations that overlap with top-level tools, increasing misselection risk. Descriptions help somewhat but overlap remains.

Naming Consistency3/5

Names use snake_case consistently, but the word order and verb style are mixed: index_update and run_tool are verb_noun, project_query and code_check are noun_verb/noun phrases, and analyze is a bare verb. This is readable but not a predictable pattern.

Tool Count5/5

Five top-level tools is well within the typical 3-15 range and each covers a distinct core workflow: indexing, querying, analysis, checking, and extended operations. The meta-tool run_tool keeps the surface scoped while still exposing many capabilities.

Completeness4/5

The set covers indexing, code location search, evidence-based analysis, code existence checking, and a broad set of secondary operations via run_tool. Minor gaps exist in top-level access to symbol-level inspection and project overview, but these are reachable through run_tool.

Maintenance

ActivityMaintained
ResponsivenessUnresponsive