Skip to main content
Glama
cexll
by cexll

version

Retrieve version details and system information from the Codex MCP Server to verify compatibility and check current deployment status.

Instructions

Display version and system information

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • The execute function for the 'version' tool, which retrieves Codex CLI version via command, Node.js version, platform, and formats system information, with fallback if codex not available.
      execute: async (args, onProgress) => {
        try {
          const codexVersion = await executeCommand('codex', ['--version'], onProgress);
          const nodeVersion = process.version;
          const platform = process.platform;
    
          return `**System Information:**
    - Codex CLI: ${codexVersion.trim()}
    - Node.js: ${nodeVersion}
    - Platform: ${platform}
    - MCP Server: @cexll/codex-mcp-server v1.2.5`;
        } catch (error) {
          return `**System Information:**
    - Codex CLI: Not installed or not accessible
    - Node.js: ${process.version}
    - Platform: ${process.platform}
    - MCP Server: @cexll/codex-mcp-server v1.2.4
    
    *Note: Install Codex CLI with: npm install -g @openai/codex*`;
        }
      },
  • Zod schema defining empty arguments for the 'version' tool.
    const versionArgsSchema = z.object({});
  • Registers the 'versionTool' into the central toolRegistry alongside other tools.
    toolRegistry.push(
      askCodexTool,
      batchCodexTool,
      // reviewCodexTool,
      pingTool,
      helpTool,
      versionTool,
      brainstormTool,
      fetchChunkTool,
      timeoutTestTool
    );

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior4/5

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

No annotations, but description accurately indicates a read-only info retrieval. Lacks explicit mention of safety but benign nature is clear.

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?

Single sentence, no redundancy, front-loaded. Every word earns its place.

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

Completeness4/5

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

Adequate for a simple tool with no parameters or output schema. Could specify what 'system information' includes, but not essential.

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?

No parameters needed; schema coverage 100%. Baseline for 0 parameters is 4, and description correctly implies no parameters.

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

Purpose5/5

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

Clearly states verb 'Display' and resource 'version and system information', specific and unambiguous.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs siblings like Help, ping, etc. Usage context is implicit but not differentiated.

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