leveret
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LEVERET_DATA | No | Directory used for private audit trace archives. | |
| LEVERET_RUNNER | No | Custom bring-your-own-harness command to use instead of the standardized leveret-runner-pi. | |
| LEVERET_RUNNER_MODEL | No | Model used by the standardized runner. | openai/gpt-5.6-sol |
| LEVERET_RUNNER_EFFORT | No | Effort level used by the standardized runner. | high |
| LEVERET_SERENA_BUNDLE | No | Path to a pre-staged Serena LSP bundle. | |
| LEVERET_REQUIRE_INDEXES | No | Set to 0 to allow an explicitly degraded run without required indexes; fail closed by default. | 1 |
| LEVERET_RUNNER_PROVIDER | No | Provider used by the standardized runner (e.g., openai, anthropic, or a local OpenAI-compatible endpoint). |
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": true
} |
| prompts | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| scanA | Run the applicable static-analysis engines (semgrep security rules, gitleaks secrets, shellcheck, ruff, actionlint) over a change set and return normalized findings. Findings are review LEADS, not verdicts: validate each against current code. Give either base (git ref; scans base...HEAD changed files, secrets over base..HEAD commits) or an explicit files list (repo-relative). A .leveret.yml profile in the repo (or profilePath) scopes engines by path and suppresses priced rules; suppressions come back tallied with their reasons, never silently. |
| ast_searchA | Structural code search via ast-grep: match a syntax-aware pattern (metavariables like $X, $$$ARGS) instead of text. Use for 'every call site shaped like this' questions a text grep gets wrong. Returns file/line/matched text. |
| contextA | Prioritization context for reviewing a change — NOT findings: per-function cyclomatic complexity (lizard, multi-language), 12-month git churn, and last-touched date per file. High complexity in a high-churn file deserves the deepest review; use this to decide where to dig before reading code. |
| rememberA | Persist a graded verdict to the repo's review memory (.leveret/memory.jsonl) so the finding class never re-surfaces ungraded. Grades: priced-noise (true but the repo prices fixing it at zero) or false-positive (the claim is wrong). Only drops are stored — actionable findings are reported, not remembered. Give anchorFile + anchorLine to pin an instance verdict to its source line: the memory dies when that line changes. Omit the anchor for a class-wide verdict (fp may use a glob). |
| memoryA | List the repo's review-memory entries (fingerprint, grade, reason, created, lastApplied). Use lastApplied to spot dead pricing worth deleting, and repeated same-rule entries under one subtree as candidates for promotion to a glob memory or a .leveret.yml profile rule. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| review | Contract for the read-only review agent: gather scan leads, context, diff and cross-file blast radius, run every lens, emit falsifiable concerns as JSON. |
| verify | Contract for the adversarial verification agent: refute-or-evidence every concern and lead, grade actionable / priced-noise / false-positive, persist drops via remember, report only what survives. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 5 tools
Each tool serves a distinct function: context for prioritization, scan for finding issues, ast_search for syntactic search, remember for storing verdicts, and memory for listing stored verdicts. There is no overlap or ambiguity in their purposes.
Tool names are concise and lowercase, but ast_search uses an underscore while others are single words. This is a minor deviation, but the naming style is otherwise consistent and intuitive.
With 5 tools, the server is well-scoped for a code review assistant. Each tool covers a necessary step in the workflow without redundancy, and the count is neither too sparse nor excessive.
The tools cover the core review lifecycle: contextual prioritization, scanning, code search, verdict memory, and memory inspection. Minor gaps exist (e.g., no explicit update/delete for memory entries), but the surface is otherwise complete and functional.