Skip to main content
Glama
Sign In
cc-code-review

cc-code-review

by KentQi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Check Claude Code Review Environment

claude_review_env

Checks Claude Code CLI, code-review skill, auth/gateway, and git/gh helper tools, and can install or uninstall the bundled code-review skill to prepare for reviews.

Instructions

Check the Claude Code CLI installation, the code-review skill, the auth/gateway setup, and helper tools (git/gh). Set installSkill=true to (re)install the bundled code-review skill into ~/.claude/skills/code-review (never overwrites a user-managed skill there). Diagnostic contract: the verdict (OK / NOT_FOUND / MISCONFIGURED) is reported in the text and in structuredContent; isError is reserved for a failure of this diagnostic itself.

Input Schema

NameRequiredDescriptionDefault
installSkillNo
uninstallSkillNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.18.9
    • addedInput schema / properties / uninstallSkill
      Added value: +{
+  "default": false,
+  "type": "boolean"
+}
  2. First observedv1.6.0

TDQS

A4/5.0
Behavior5/5

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

The description goes well beyond the annotations by disclosing the exact filesystem side effect (~/.claude/skills/code-review) and the safety guarantee that a user-managed skill is never overwritten. It also documents the diagnostic contract: verdict values live in text and structuredContent, and isError is reserved for a failure of the diagnostic itself, which prevents an agent from misreading a NOT_FOUND verdict as a tool error.

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 dense, front-loaded sentences: capability scope first, then the mutation flag, then the result contract. Every clause adds information an agent would otherwise have to guess.

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?

With no output schema and no parameter descriptions, the description does the heavy lifting well: it enumerates the verdict vocabulary, states where results appear, and defines isError semantics. The only real omission is the uninstallSkill parameter and how it interacts with installSkill.

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

Parameters3/5

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

Schema coverage is 0%, so the description must carry the parameter burden, and it explains installSkill thoroughly (reinstall semantics, target path, non-overwrite rule). However, uninstallSkill is never mentioned at all, and the interaction between the two booleans (mutual exclusion, precedence) is left unspecified.

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?

The description names a specific verb-plus-resource set: it checks the Claude Code CLI, the code-review skill, auth/gateway setup, and git/gh helpers. That is clearly a pre-flight diagnostic, which separates it in spirit from the review-execution siblings. It never explicitly contrasts itself with claude_review_status, so the differentiation is inferred rather than stated.

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

Usage Guidelines3/5

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

Usage is only implied: an agent can infer this runs before a review, and the description does specify the installSkill=true behavior. There is no explicit statement of when to call this versus claude_review_status or claude_code_review, and no guidance on when a diagnostic check is unnecessary.

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