Skip to main content
Glama
bill-kopp-ai-dev

Claude Code CLI MCP Server

claude_health

Validates the Claude Code CLI environment before orchestration: verifies the binary is on PATH, captures version, and reports OAuth auth status. Confirms setup is ready or flags mismatches.

Instructions

Health check for the Claude Code CLI binary.

Verifies the claude binary is on PATH, captures its --version output, and reports auth status (whether ~/.claude.json has an OAuth token). Use this as the first call in any orchestration session to validate the environment.

Optional fields: - expected_version (str): if set, returns ok=false on version mismatch

Returns: - claude_path, claude_version, ok, auth_status, notes

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
reqNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okYes
notesNo
auth_statusNo
claude_pathYes
claude_versionYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden of behavior, and it delivers: it states it verifies the binary on PATH, captures --version, inspects ~/.claude.json for an OAuth token, and reports auth_status. It also defines the effect of expected_version on ok, exceeding a typical health-check disclosure.

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?

The description is compact and logically ordered: purpose, behavior, usage timing, optional parameter, return fields. No filler sentences; every line adds necessary 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?

Given the tool's simplicity (1 optional parameter, no annotations), the description covers purpose, usage context, behavior, parameters, and return values. The output schema is said to exist, so the return field list is a bonus. An agent has everything needed to call it first and correctly.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must add meaning. It explains the sole parameter expected_version, noting it is optional and that setting it returns ok=false on mismatch — exactly what an agent needs beyond the raw anyOf schema.

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?

The description opens with a concrete verb+resource: 'Health check for the Claude Code CLI binary' and lists specific checks (PATH, --version, auth status). This clearly differentiates it from sibling task-execution tools like claude_run_task or claude_self_test.

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?

Explicitly instructs to call this 'as the first call in any orchestration session to validate the environment.' This provides clear context for when to invoke, though it does not name alternatives or exclusions, preventing a 5.

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