Veris
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| VERIS_STATE_DISABLED | No | Set to 1 to skip all .veris/state.db writes (zero-retention mode). |
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| analyze_repositoryA | Parses the git-tracked TypeScript and JavaScript files in the current repository via ts-morph and returns a structural summary: file, class, method, function and exported-function counts, a per-file breakdown (capped at 100 files, ranked by declaration count), and call-resolution statistics showing how many call sites the TypeScript checker resolved exactly versus left ambiguous. Untracked and ignored files are excluded. Results are cached until a source file changes on disk. |
| export_behavioral_graphA | Exports the behavioral graph as JSON. Nodes are classes, methods, constructors, accessors and top-level functions, each tagged with its inferred workflow domain; edges are DependsOn (containment and imports) and Invokes (call targets). Every edge carries a 'resolution' field: 'resolved' means the TypeScript checker identified the target, 'heuristic' means exactly one declaration matched by name, 'structural' means containment or import. Calls whose target is ambiguous produce no edge at all. Returns full counts plus up to 500 nodes and 1000 edges, with a 'truncated' field when the graph is larger. |
| analyze_pr_behaviorA | Computes a behavioral diff between the working tree and the merge-base of HEAD with a base ref, using a detached git worktree. Returns added, removed and modified node counts (modified = same declaration, changed body hash — a rewrite that keeps its name and callees), the affected workflows with narratives, and the top 25 nodes by risk. Reports whether the working tree was dirty, since that makes the result non-reproducible from commits alone. Requires a git repository with a resolvable base ref: if none exists the call returns an error rather than a fabricated baseline. Base ref defaults to origin/main, then origin/master, main, master, HEAD~1. |
| generate_verification_planA | Generates a tiered verification plan for every impacted node. Tier 1 is structural (lint, schema, types), Tier 2 behavioral (contracts, integration boundaries), Tier 3 adversarial (concurrency, idempotency, retries, replay, partial failure). Directives are templates parameterized by node id — for concrete failure scenarios use generate_adversarial_probes instead. Returns tier counts plus up to 200 targets ranked by node risk, with a 'truncated' field when there are more. |
| identify_unverified_behaviorsA | Returns verification coverage: how much of the planned work has supporting execution evidence, weighted by tier, decayed by age, and weighted by trust class (agent-asserted evidence counts for half). Also returns the count of failing and flaky targets, the highest single impacted-node risk, and the specific unverified assumptions (capped at 20). 'overallConfidence' is an alias of coverage retained for compatibility — it measures evidence, not the probability that the code is correct, and is not calibrated against observed outcomes. Coverage is reported as unknown, not 100%, when nothing was planned. |
| list_workflowsA | Groups repository nodes into semantic domains (Authentication, Payments, Webhooks, Caching, Queue and 20 more) and returns per-workflow member counts, impact counts, risk aggregates, narrative and runtime-risk hypotheses. Classification is a weighted keyword vote over directory segments, import specifiers and symbol names — it does not traverse the call graph, so a workflow is a labelled set of declarations rather than an execution path. Nodes matching no rule are grouped as Uncategorized. Returns up to 50 workflows. |
| analyze_workflowA | Deep-dive on one workflow by id: member nodes (up to 500), the inference signals that placed each member there with their weights, the top 5 members by risk with full score breakdowns, and runtime-risk hypotheses. Use after list_workflows identifies the workflow you care about. |
| detect_driftA | Compares current workflow fingerprints against those from prior runs in .veris/state.db. A fingerprint is the SHA-256 of the workflow's sorted member ids, its internal edge signatures, and each member's normalized body hash — so a rewritten function body is detected even when its name and call targets are unchanged. Member ids are repository-relative, so renaming a directory does not register as drift. Surfaces added, removed, expanded, contracted and silently-rewritten workflows, and distinguishes a first observation from an absence of drift. Persists the current fingerprints for future comparisons. |
| generate_adversarial_probesA | Returns concrete Tier-3 failure scenarios for the affected workflows, each paired with the invariant that must hold — for example 'submit charge twice with the same idempotency key inside 500ms; exactly one ledger entry'. Probes are selected from a curated per-domain library (concurrency, idempotency, retry storms, replay, partial failure, cache stampede, ordering); they are not generated from your code, so they name the failure mode rather than the specific call site. Returns up to 100. |
| allocate_budgetA | Given a time budget in minutes, greedily selects the highest-leverage subset of verification targets that fits, ranked by (tier leverage x workflow criticality x node risk) / estimated cost. Returns the selected targets in execution order (up to 200), the counts selected and skipped, estimated seconds and coverage. The skipped list itself is not returned — it is the complement of the selection and can be the entire plan. |
| what_if_revertA | Counterfactual: removes the named nodes from the head graph, recomputes the diff and risk against the real baseline, and reports what changes. Answers 'what recovers if I revert this?'. Models deletion only — it cannot model reverting a modified body back to its prior form. Requires a resolvable baseline; returns an error rather than a fabricated one. |
| report_executionA | Posts verification results back to Veris. Evidence is append-only and hash-chained: a later record for the same target is added alongside the earlier one, never replacing it, so a failure cannot be overwritten by a subsequent pass. Each record carries a trust class — 'agent-asserted' (default; the caller's own claim, counts at half weight), 'harness-observed' (an external runner observed it), or 'veris-derived' — and a producer identity. Accepts a batch, written in one transaction: if any entry is invalid, none are recorded. |
| confidence_historyA | Returns verification-coverage and execution-depth values across recent runs recorded in .veris/state.db, newest first. Defaults to 30 runs, capped at 100. Returns an empty trend with stateEnabled:false when persistence is disabled (VERIS_STATE_DISABLED=1). |
| node_historyA | Timeline for one node: its risk and blast-radius values across previous runs, plus every execution-evidence record posted against it with result, tier, trust class, producer and timestamp. Use for forensics ('this function broke production — what does its history look like?') or to check whether a high-risk node has accumulated trustworthy passing evidence. |
| export_onboardingA | Writes a workflow-first onboarding package under veris-reports/onboarding/: one markdown file per workflow describing its purpose, members, risks and suggested first reads, plus a README.md index. Returns the output directory and the paths written. |
| cross_repo_snapshotA | Reads the last recorded run for each repository registered in ~/.veris/registry.json and returns their coverage values, weakest first. Reports repositories that have no Veris state yet as 'no data' rather than analyzing them — this tool reads existing state and never runs an analysis or writes to a registered repository. |
| register_repoA | Adds a repository to the user-level registry at ~/.veris/registry.json so cross_repo_snapshot includes it. The path must exist, be a directory, and contain a .git directory. Setup-time call, typically run once per repository. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 17 tools
Tool purposes are mostly distinct and clearly described, with analyze_* and generate_* prefixes differentiating targets. A few names like cross_repo_snapshot vs analyze_repository could require reading descriptions, but overlap is minimal.
Most tools follow a verb_noun pattern (register_repo, analyze_repository, list_workflows), but several are noun phrases (cross_repo_snapshot, confidence_history, node_history) and one is a question phrase (what_if_revert). The pattern is readable but not fully consistent.
At 17 tools, the surface is slightly above the typical 3-15 range, but each tool addresses a distinct part of the verification workflow. The count feels a bit heavy yet justifiable for the domain.
The toolset covers setup, analysis, planning, reporting, history, and onboarding comprehensively. It lacks an obvious direct 'execute verification' tool, but the server appears focused on planning, analysis, and evidence recording rather than test execution.