Skip to main content
Glama
verax-ai

Verax

Official

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
memory.getA

Reads one memory item this tenant stored earlier with memory.put, by its id. Use it to recall a fact, a setting or a note before acting on it; nothing is written. Like every call it passes the policy gate and leaves a signed decision record; an id that belongs to another tenant is answered with a signed deny. Returns the stored item as JSON: {id, body, source, validFromMs, validUntilMs, versionHash}. Outside the validity window the body is withheld: {stale: true, id, validUntilMs} after it, {notYetValid: true, id, validFromMs} before it. An unknown id answers {error: "not-found", id}.

memory.putA

Writes one memory item for this tenant, or replaces the item with the same id, in the body's state directory on this machine. Use it to keep a fact for a later memory.get together with where it came from and how long it holds, so a stale fact is not served later. The call passes the policy gate and is recorded; the record carries the item's versionHash, a SHA-256 over id, body and validity window. Returns {ok: true, id, versionHash}. A missing source answers {error: "source-required"}, a missing validUntilMs {error: "validUntilMs-required"}, a malformed id {error: "id-invalid"}.

audit.explainA

Reads one decision back from the signed ledger by its ref and explains it. Use it to check what the body decided about an earlier call and whether the recorded effect matched, before repeating a call or reporting on it; read-only, and the lookup itself is recorded too. Returns JSON with record (the signed decision's claims: tool, verdict, policy hash, timestamps), effect (the reconciled effect row), finding (match, mismatch or missing), witnessClass, guarantee, warnings, trustRoot (which key verified the signatures), and for a held call pair with its defer and resolution records. A ref that does not exist, or belongs to another tenant, is answered with the same signed deny, so neither case reveals the other.

message.readA

Reads this tenant's inbox, the messages placed for it in the body's state directory on this machine, and returns them as a JSON array in arrival order, oldest first. Use it to see what has arrived before deciding what to answer. Takes no arguments; read-only; the call is recorded like every other. An empty or absent inbox answers [].

message.sendA

Queues one message in this tenant's outbox on this machine for the delivery step the operator runs; this call opens no network connection and nothing leaves the body from it. Use it to hand off a message, not to deliver one. Like every call it passes the policy gate and leaves a signed decision record. The gate reads the host after the last '@' in to and allows it only when it is on the policy's egress allow-list; otherwise the call is refused with denied:egress-blocked, or denied:egress-host-missing when no host can be read. A policy rule in approve mode holds the call for an operator instead and answers deferred:approval-required:. Returns {queued: true, ref}, where ref is the decision reference for audit.explain.

spendA

Asks the body to authorize a payment and records the decision; the body never moves money, so authorized: true is a signed permission for a later payment step, not a transfer. Use it before any payment so that amount, currency, payee and reference are checked against the policy: the one currency the policy names, a cap per call, a payee list and a daily limit. A call outside those bounds is refused with a signed deny naming the bound: denied:spend-cap, denied:spend-payee, denied:spend-currency or denied:spend-daily. A call within them is held for an operator on this machine and answers deferred:approval-required:; once that ref is approved (verax approve, or the panel), resending the same call with the same _ref answers allowed:, and the authorization is recorded as {authorized: true, ref, amountMinor, currency, payee, reference}. Without a spend rule in the policy every call answers denied:spend-not-wired.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.4/5.0

Scored across 6 tools

Disambiguation5/5

Each tool has a clear, distinct purpose: memory.get/put for storage, audit.explain for decision lookup, message.read/send for messaging, and spend for payment authorization. There is no overlap or ambiguity; an agent can confidently select the right tool for a task.

Naming Consistency4/5

Most tools follow a consistent 'domain.verb' pattern (memory.get, memory.put, audit.explain, message.read, message.send), but 'spend' is a lone verb without a domain prefix, creating a minor deviation. The overall style is uniform and readable.

Tool Count5/5

With 6 tools, the surface is well-scoped for the domains covered (memory, messaging, audit, spending). Each tool serves a distinct operational need, and the count is neither sparse nor bloated.

Completeness4/5

Core operations are covered: memory supports get and put (including replace), messaging supports read and send, audit supports explain (though no list), and spend supports authorization. Minor gaps exist, such as no explicit delete for memory or messages and no audit listing, but these are not critical for the intended workflows.

Maintenance

ActivityMaintained
ResponsivenessNo issues