Proximo
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PROXIMO_AUDIT_KEYED | No | Defaults to on; set to 'off' to disable HMAC-SHA256 keying of the audit ledger. | 1 |
| PROXIMO_ENABLE_EXEC | No | Opt-in: enables near-root LXC exec via SSH. Off by default. | 0 |
| PROXIMO_CT_ALLOWLIST | No | Comma-separated list of CTIDs allowed for exec (fail-closed). | |
| PROXIMO_ENABLE_AGENT | No | Opt-in: enables qemu-guest-agent operations inside VMs. Off by default. | 0 |
| PROXIMO_LEDGER_REDACT | No | If set to '1', record fingerprint instead of SQL body/command argv in ledger (privacy). | 0 |
| PROXIMO_A2A_TOKEN_FILE | No | Path to a file containing the bearer token for A2A server (non-localhost bind requires this). | |
| PROXIMO_AGENT_ALLOWLIST | No | Comma-separated list of VMIDs allowed for agent operations (fail-closed). | |
| PROXIMO_AUDIT_EXPECTED_HEAD | No | Expected head hash for audit verification (off-box anchor against tail truncation/forgery). |
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
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| proximo_findA | READ-ONLY: search every API address the planes publish, in plain words ('list datastores', 'guest status'). A verb picks the method; other words match the path, the vendor's description, parameter names. 5 by default. Returns access and the authored blast-radius tier. |
| proximo_planA | READ-ONLY: the governed verdict for one address and the vendor's published parameters. Mutates nothing. A mutation's plan also reads the target (one governed read, receipted): current, change (from/to per argument), noop. Run before proximo_call. path may be words: one match is planned, several come back to pick from. |
| proximo_readA | READ-ONLY: run any GET the plane publishes, by path. Rows come back LEAN with a total (names, states, ids) unless fields='all' or fields='name,status'. Over the cap: counts per state and the odd rows; fields= gets rows. since='24h' (30m, 7d): what changed, from the door's own snapshots, no vendor call. Credentials come back withheld. wait=N on a .../tasks/{upid}/status address waits up to N s (max 600) for the task's end. diagnose=true on a node or guest path: its health reads and advisory flags, one call. |
| proximo_callA | MUTATION: run a governed POST/PUT/DELETE. Dry-run by default: without confirm=true it returns the plan (verdict, consent id, current, change) and mutates nothing. Refused unless the operator is armed AND the address carries an authored blast-radius tier. Every call, refused or executed, is receipted. A task-backed call is waited on (wait=N s, default 60, max 600; 0 submits only) and reports finished, failed or timed out under 'task'. method=undo with path=<undo.id> puts that receipt's capture back through the vendor's PUT, plan first; withheld or unpublished keys come back as skipped. |
| audit_entriesB | READ-ONLY: read the PROVE ledger back, newest first, bounded, rows with ids; says when it truncated. |
| audit_verifyA | READ-ONLY: walk the chain and report the first break; expected_head catches a cut tail; path= verifies a sealed archive beside the ledger. |
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
The four Proximo tools have reasonably distinct roles: find discovers addresses, plan previews/verdicts a specific address, read executes GETs, and call performs governed mutations. There is some conceptual overlap between plan and read because plan includes a governed read of the target, but the descriptions clarify when each should be used.
All names are snake_case and readable, and the core API tools consistently use the proximo_ prefix with action verbs. The audit tools use a separate audit_ prefix and noun-style names, which is a minor convention split rather than a major inconsistency.
Six tools is well-scoped for a governed API gateway: discovery, planning, read, mutation, and two audit operations. Each tool appears to earn its place without redundant surface area.
The surface covers the main lifecycle: discovering addresses, planning changes, executing reads and mutations, undoing via receipts, and reading/verifying the audit ledger. Minor gaps around explicit arm/status administration may exist, but core governed API workflows are covered.