io.github.BrienBounded/evr
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| check_trace_readinessA | Check an agent execution trace against the evidence-readiness specification and report, per requirement, whether the evidence a post-hoc causal reconstruction would need is met, partially met, or unmet — naming the specific missing field and the span kind it belongs on. Accepts a file/directory path OR inline JSON content (exactly one). Runs entirely locally in this process; nothing is transmitted or persisted, and inline content is processed in memory only. This tool NEVER determines whether a failure occurred: it answers "does this trace contain what a reconstruction of class X would require," never "did class X occur." A fabricated-but-internally-consistent trace passes. This tool verifies evidence is present, not that it is true, and its result must never be relayed as "this agent is safe". |
| get_requirementA | Return one evidence-readiness requirement by ID (for example EVR-R3 or EVR-PI-7): its title, the published field forms, the span kind the evidence belongs on, its spec section, and — for prompt_injection — which attribution tiers include it. Requirements state what must be PRESENT in a trace; the spec is not an enumeration of everything the reconstruction engine reads, so no inference can be drawn from a field's absence. This tool verifies evidence is present, not that it is true, and its result must never be relayed as "this agent is safe". |
| list_class_requirementsA | List the evidence requirements for one failure class (config_drift, session_isolation_failure, cascade_contamination, prompt_injection), or pass "universal" for the requirements every trace must meet (EVR-R1..R6). States which items are required versus supporting, and for prompt_injection the per-tier evidence sets. tool_misuse returns its documented negative result (investigated and declined), not an error. Requirements state what must be PRESENT; nothing may be inferred about fields the spec does not name. This tool verifies evidence is present, not that it is true, and its result must never be relayed as "this agent is safe". |
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 3 tools
The three tools are largely distinct: check_trace_readiness evaluates a trace, get_requirement fetches a single requirement by ID, and list_class_requirements enumerates requirements for a class. The two retrieval tools overlap slightly in purpose, but their ID-vs-class parameters clearly separate them.
All three names follow a clean snake_case verb_noun pattern (check_trace_readiness, get_requirement, list_class_requirements), with verbs matching the operation. No mixed conventions.
Three tools is a bit lean but well-matched to a narrow read-only spec-inspection purpose. Each tool has a distinct role, though a broader server might warrant a tool to enumerate classes or list all requirements.
The surface covers the core lifecycle: evaluate a trace, look up a requirement, and list requirements per class (including 'universal'). Since the domain is inherently read-only, no create/update/delete is needed; only minor gaps like a global enumeration exist.