Skip to main content
Glama
Sign In
codex-mcp

codex-mcp

by anhnguyen0905
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Check Codex CLI health

codex_health

Check Codex CLI version and login status, and optionally run a read-only probe to reveal quota or model outages that login status alone misses.

Instructions

Report installed Codex CLI version and login status. With deep=true, also run one bounded read-only Codex exec probe to detect quota/model outages that login status cannot see.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "codex_health"
  }
}

Input Schema

NameRequiredDescriptionDefault
deepNoAlso run one bounded read-only `codex exec` probe and report execProbe/execProbeMessage (default: false)

Output Schema

NameRequiredDescriptionDefault
versionYes
authModeYes
loggedInYes
execProbeNo
loginProbeYes
redactionsNo
loginStatusYes
execProbeMessageNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.25.0
    • addedInput schema / properties / deep
      Added value: +{
+  "description": "Also run one bounded read-only `codex exec` probe and report execProbe/execProbeMessage (default: false)",
+  "type": "boolean"
+}
    • addedOutput schema / properties / authMode
      Added value: +{
+  "enum": [
+    "chatgpt",
+    "apikey",
+    "unknown"
+  ],
+  "type": "string"
+}
    • addedOutput schema / properties / execProbe
      Added value: +{
+  "enum": [
+    "ok",
+    "quota",
+    "model",
+    "error",
+    "skipped"
+  ],
+  "type": "string"
+}
    • addedOutput schema / properties / execProbeMessage
      Added value: +{
+  "type": "string"
+}
    • addedOutput schema / properties / redactions
      Added value: +{
+  "type": "number"
+}
    • changedOutput schema / required
      Previous value: -[
-  "version",
-  "loggedIn",
-  "loginProbe",
-  "loginStatus"
-]New value: +[
+  "version",
+  "loggedIn",
+  "loginProbe",
+  "loginStatus",
+  "authMode"
+]
  2. Addedv0.16.0
  3. Removedv0.15.1
  4. Changed1 schema field changedv0.13.0
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "loggedIn": {
+      "type": "boolean"
+    },
+    "loginProbe": {
+      "enum": [
+        "ok",
+        "failed",
+        "timeout"
+      ],
+      "type": "string"
+    },
+    "loginStatus": {
+      "type": "string"
+    },
+    "version": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "version",
+    "loggedIn",
+    "loginProbe",
+    "loginStatus"
+  ],
+  "type": "object"
+}
  5. First observedv0.2.0

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full behavioral burden. It usefully discloses that deep mode runs one bounded, read-only Codex exec probe, which communicates safety and limits. It also explains why deep mode matters by mentioning quota/model outage detection, though it does not detail potential latency, failure semantics, or network dependencies beyond the output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two focused sentences with no filler. The main output is stated first, and the optional deep behavior is clearly introduced second. Every phrase earns its place, including 'bounded' and 'read-only,' which carry important safety information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple: one optional boolean parameter, an output schema, and no nested structures. The description fully covers its purpose, the deep-mode extension, and the rationale for using it. Nothing needed for selecting or invoking the tool correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining why deep=true is useful—detecting quota/model outages that login status cannot see—rather than just restating the parameter's mechanics. This helps an agent decide whether to set deep=true.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool reports installed Codex CLI version and login status, and optionally runs a health probe. This is a specific verb-resource pairing that makes the core purpose obvious, though it does not explicitly differentiate itself from sibling tools like codex_metrics or codex_sessions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The main purpose is clear: use this when you need CLI version, login status, or health-related outage detection. The deep=true behavior is explicitly tied to detecting quota/model outages that login status cannot see, providing a clear reason to enable it, but no direct comparisons or exclusions against sibling tools are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools