Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

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

CapabilityDetails
tools
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.2/5.0

Scored across 3 tools

Disambiguation4/5

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.

Naming Consistency5/5

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.

Tool Count4/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues