Verinoda
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
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
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| 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
| Name | Description |
|---|---|
| review | Review the working-tree change (or the change since base): what it touches, names that do not exist, decision records, dependents. |
| onboarding | Get to know the project (or one topic in it): structure, dependencies, tests, then how it works as claims with evidence. |
| debug | Debug a failure: locate the code the symptom names, ask why, then record every fix attempt against one repro. |
| pre_merge | Check 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
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 5 tools
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.
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.
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.
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.