codex-quota-guard-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CODEX_QUOTA_GUARD_CONFIG | No | Path to an absolute JSON configuration file conforming to examples/config.schema.json. Defaults require no configuration. | |
| CODEX_QUOTA_GUARD_STATE_DIR | No | Overrides the default state directory for SQLite cache/lease/backoff storage. |
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 |
|---|---|
| quota_statusA | Read the shared adaptive Codex quota snapshot. The server enforces cache TTL, lease, and backoff; callers cannot force refresh. |
| job_preflightB | Call before a costly boundary such as a long build, test, deploy, migration, training, or packaging job. Obey defer decisions. |
| checkpoint_createA | Persist a redacted, resumable checkpoint in shared local state. Do not include credentials, full prompts, or full responses. |
| checkpoint_getA | Read a specific checkpoint or the latest checkpoint for a workspace/task. |
| defer_until_resetB | Create a checkpoint and prepare a same-task Codex heartbeat automation prompt for the five-hour reset. The caller must create the automation. |
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 action: reading quota status, preflight-gating expensive jobs, persisting checkpoints, reading checkpoints, and handling deferral. quota_status and job_preflight both relate to quota state, but their roles as snapshot reader versus execution gate are clear from the descriptions.
All names are lowercase snake_case and readable, but they mix conventions: quota_status and job_preflight are noun_noun, checkpoint_create and checkpoint_get are noun_verb, and defer_until_reset is a verb phrase. The inconsistency is noticeable but not chaotic.
Five tools is well-scoped for a quota-guard server. Each tool covers a necessary part of the workflow without redundancy, and the count feels appropriately minimal rather than padded.
The core lifecycle is covered: status checking, preflight gating, checkpoint persistence/retrieval, and deferral handling. Minor gaps like checkpoint deletion/update, listing checkpoints, or an explicit reset/release action are absent, but they are not essential to the server's stated purpose.