CTRLRun Approval Console
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CTRLRUN_STATE | No | Path to the SQLite state database file, or a Postgres connection URL when using the Postgres backend. Used to persist reservations, receipts, and approvals. |
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": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_pending_approvalsA | Read-only. The approval requests waiting for a human, oldest first, with the action, its arguments and when the request expires. Start here: the request ids approve and deny take come from this list. |
| inspect_actionA | Read-only. One action's whole history: what was proposed, what the policy decided, which approval was involved, what happened to the effect, and the receipt. Use this when you know which action you care about; use receipts to browse, stats for totals. |
| receiptsA | Read-only. The individual receipts this store holds, as portable JSON, oldest last, one for every attempt including the refusals. Use this to read what happened; use stats for totals, and inspect_action for one action end to end. |
| effectsA | Read-only. The logical effects this store knows about, one row per effect key. Use this to find the effects whose outcome is unknown, which are the ones resolve can move on and the ones blocking a retry. |
| statsA | Read-only. One summary of what this store's receipts say over an optional window: how many actions were allowed, refused or sent to a human, and how their effects ended. Use this for totals; use receipts when you need the records themselves. |
| approveA | WRITES. Grants one pending approval request, letting the agent run that exact action once. Requires an authenticated human; the answer is recorded under their name and is visible in the receipt the action leaves. |
| denyA | WRITES. Refuses one pending approval request. Requires an authenticated human; the answer is recorded under their name. |
| resolveA | WRITES. States what actually happened to an effect whose outcome is unknown. Requires an authenticated human and a reason; the answer is recorded under that person's name, and a 'failed' resolution permits a retry that is currently blocked. |
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 8 tools
Each tool maps to a distinct resource or workflow step: pending list, approval/denial mutations, action history, raw receipts, effect states, aggregate stats, and effect resolution. No two tools are interchangeable, and the descriptions explicitly direct agents to the right one.
Names split between bare verbs (approve, deny, resolve), verb-noun read commands (list_pending_approvals, inspect_action), and bare plural nouns for data views (receipts, effects, stats). They are readable and meaningful, but the naming convention is not uniformly predictable.
Eight tools fit the approval-console domain well: write operations are covered by approve, deny, and resolve, while read-side views cover pending items, per-action history, raw receipts, effects, and statistics. No tool feels redundant or missing as filler.
The tool set covers the full workflow: identify pending requests, decide them, inspect full action history, inspect effect outcomes, and record resolutions that unblock retries. Auditing is supported through receipts and stats, so there are no obvious dead ends.