Verax
OfficialServer 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 |
|---|---|
| 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
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
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.
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.
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.
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.