Rein
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| REIN_AGENT_ID | Yes | Rein agent id (agt_...) | |
| REIN_ENGINE_URL | Yes | Policy engine base URL | |
| REIN_ENGINE_API_KEY | No | Engine bearer key |
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| rein_fetchA | HTTP fetch with x402 payments governed by Rein. If the resource is behind a paywall, the payment is checked against policy BEFORE any money moves: allowed payments are settled and receipted, denied ones never happen, and payments past an envelope are escalated to a human for a signed approval. Use this instead of a plain fetch for any request that might be paid. Returns the response plus what Rein decided. |
| rein_statusA | The rules this agent is subject to and its standing against them: engine posture, agent status, the policies that apply, spend-breaker counters (how close this agent is to tripping an envelope), and liveness. Read it before a large or unusual payment, or after a denial, to find out what the limits actually are. |
| rein_receiptsA | This session's Rein receipts (every payment decision this server made, allowed or not) plus reconciliation: which allowed payments actually settled and which are still outstanding. Use it to check whether a payment really went through. |
| rein_escalationsA | Payments by this agent that policy escalated rather than allowed or denied. Each is waiting for a human to sign an approval and expires into a denial if nobody does. READ-ONLY: an approval is a cryptographic signature by a registered approver, and nothing callable here can grant, deny or extend one. |
| rein_heartbeatA | Tell Rein this agent is still working, for dead-man monitoring. Only needed when the agent is running but not buying anything -- every rein_fetch is already a sighting. Refused when no activity expectation is declared for this agent. |
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 5 tools
Each tool targets a distinct concern: rein_fetch acts, rein_status reads rules/standing, rein_receipts reads decision history, rein_escalations reads the pending-approval queue, and rein_heartbeat signals liveness. The only mild overlap is that escalations are a subset of the payments tracked in receipts, but the descriptions explicitly separate the two.
All five tools share a consistent 'rein_' prefix, giving a predictable namespace. The only deviation is rein_fetch, a verb-action tool among otherwise noun/resource-oriented names (escalations, heartbeat, status, receipts).
Five tools is well-scoped for a focused payment-governance server; each maps to a real need (pay, check status, review receipts, review escalations, signal liveness). It sits at the low end, but nothing feels redundant.
The surface covers the core agent lifecycle: making governed payments, inspecting rules/standing, verifying settlement, tracking escalations, and heartbeat monitoring. Minor gaps exist — no callable approve/deny action (deliberately out of scope, since approvals are external signatures) and no tool to declare the activity expectation that heartbeat requires.