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, analyze, and code_check all answer questions about code and overlap meaningfully (analyze subsumes existence-checking that code_check specializes). run_tool further muddies boundaries by bundling node_inspect, relation_trace, and change_review, which duplicate project_query and index_update concerns. Descriptions help, but an agent must reason carefully to pick the right entry point.
Names are all snake_case and readable, but the convention is mixed: project_query, index_update, and code_check use noun_verb, analyze is a bare verb, and run_tool uses verb_noun. There is no single predictable pattern, though it is far from chaotic.
Five top-level tools is a reasonable, well-scoped surface for a code-intelligence server. However, run_tool smuggles roughly twenty distinct operations (node_inspect, map_view, history_search, etc.) into a single tool, artificially compressing what is effectively a much larger toolset.
The surface covers querying, indexing, evidence-backed analysis, structure/impact/history inspection, and test tracing — solid lifecycle coverage for a read/analysis server. Gaps are minor, e.g. no direct workaround for edit application or non-listed language import checking beyond the not_checked fallback.