Skip to main content
Glama
Nieto-Tech

crew-mcp

by Nieto-Tech
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Crew diff review

crew_review_diff
Read-only

Reviews working-tree changes for bugs, security, concurrency, and data-integrity issues, separating evidence-checked findings from unverified ones before you declare work complete.

Instructions

Have a scout review the current working-tree changes (staged, unstaged and new files) for bugs, security, concurrency and data-integrity problems. Findings are split into evidence-checked (the quoted code really exists) and unverified. Run it after making changes and before saying you're done.

Input Schema

NameRequiredDescriptionDefault
baseNoGit ref to diff against (default HEAD). Use e.g. 'main' for a whole branch.
focusNoWhat to look at hardest, e.g. 'transaction boundaries'
forceNoReview even if the diff is too large for the scout (it is truncated, and may time out). Default false.
pathsNoLimit the review to these paths
workspaceNoAbsolute path of the repository. Defaults to the directory Claude Code launched the server in.
acknowledgedNoFindings from an earlier run you already fixed, rebutted or accepted, so they aren't raised again. Start each with the finding's headline file:line, then a few words, e.g. 'src/jobs/sync.ts:110 fan-out not transactional: deliberate'. Matching findings within a few lines are collapsed to one line.
includeUntrackedNoInclude new untracked files (default true). AI-tool folders like .codex/ and .claude/ are always skipped.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.4.1
    • addedInput schema / properties / acknowledged
      Added value: +{
+  "description": "Findings from an earlier run you already fixed, rebutted or accepted, so they aren't raised again. Start each with the finding's headline file:line, then a few words, e.g. 'src/jobs/sync.ts:110 fan-out not transactional: deliberate'. Matching findings within a few lines are collapsed to one line.",
+  "items": {
+    "maxLength": 300,
+    "type": "string"
+  },
+  "maxItems": 30,
+  "type": "array"
+}
  2. First observedv0.2.0

TDQS

A3.9/5.0
Behavior4/5

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

With only readOnlyHint declared, the description adds real behavioral context: findings are partitioned into evidence-checked (quoted code verified to exist) versus unverified, and AI-tool folders are skipped. It does not mention cost, latency, or what happens on a clean tree, which are the remaining gaps for a review tool.

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

Conciseness4/5

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

Three tight sentences with the most important information (what is reviewed) front-loaded, followed by output shape and timing. No filler, though the output-shape sentence could be compressed.

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?

Seven optional parameters and no output schema, so the description carries the burden of describing returns — it does this by explaining the evidence-checked/unverified split. Combined with the workflow trigger and default-HEAD implication, an agent has enough to invoke it correctly; only the 'too large / force' trade-off and expected runtime are left to the schema.

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 100%, so all seven parameters are already documented in the schema (base defaulting to HEAD, force/truncation, acknowledged matching semantics). The description adds essentially no parameter-level information beyond the schema, so the baseline 3 applies.

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?

States a specific verb and resource: reviewing working-tree changes (staged, unstaged, new files) for bugs, security, concurrency and data-integrity. The scope is precise enough to distinguish it from a general status/stats tool, but it never names or contrasts with the closest sibling (crew_second_opinion), so an agent must infer the boundary.

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?

'Run it after making changes and before saying you're done' gives a clear triggering condition in the workflow. There are no explicit exclusions or named alternatives (e.g. when to prefer crew_second_opinion instead), which keeps it below a 5.

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