Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
VERIS_STATE_DISABLEDNoSet 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

CapabilityDetails
tools
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.9/5.0

Scored across 17 tools

Disambiguation4/5

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.

Naming Consistency3/5

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.

Tool Count4/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues