Skip to main content
Glama
Sign In
codelattice

codelattice

by aiulms
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

codelattice_change_review

Read-onlyIdempotent

Assess impact before editing a symbol or path in a project root, review local diffs, flag breaking public API changes, and use job modes for large repos.

Instructions

Concrete pre/post edit review for a SINGLE project root when the target is known. Use impact before editing a symbol/path, native_review after local diffs, breaking_change for public API concerns, and job modes for large repos. If the target is unclear, use codelattice_workflow first.

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": "codelattice_change_review"
  }
}

Input Schema

NameRequiredDescriptionDefault
modeNoReview mode. job_status/job_detail use jobId and do not need root.impact
pageNojob_detail page index
rootNoAbsolute path to project root — must be a single project directory, not a workspace root. Required except for job_status/job_detail.
jobIdNoRequired for job_status and job_detail; root is not required for these modes
symbolNoTarget symbol (for impact mode)
compactNo
languageNoauto
pageSizeNojob_detail page size
directionNoboth
changedSymbolsNoChanged symbol names

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.17.0-beta.3
    • changedInput schema / properties / language / enum
      Previous value: -[
-  "rust",
-  "cangjie",
-  "arkts",
-  "typescript",
-  "javascript",
-  "c",
-  "cpp",
-  "python",
-  "shell",
-  "auto"
-]New value: +[
+  "rust",
+  "cangjie",
+  "arkts",
+  "typescript",
+  "javascript",
+  "c",
+  "cpp",
+  "python",
+  "shell",
+  "objc",
+  "auto"
+]
  2. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive behavior, and the description adds useful operational context: the root must be a single project directory, not a workspace root, and job modes are intended for large repos. It does not explain job lifecycle or output details, but the annotations reduce the burden.

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?

Three tightly written sentences, with the main purpose and root constraint front-loaded before usage routing. No sentence is wasted.

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

Completeness3/5

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

For a complex tool with 20 mode values and 10 parameters, the description gives solid high-level routing but leaves many modes and job workflows unexplained. It is adequate for common paths but not complete for the full mode surface.

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?

The description adds meaning for several mode values, especially impact, native_review, breaking_change, and job modes. However, with 70% schema description coverage and many mode enum values left unexplained in both schema and description, it only partially compensates for the remaining gaps.

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 states a specific purpose: pre/post edit review for a single project root when the target is known. It distinguishes this tool from codelattice_workflow, but the broad multi-mode nature of the review is not fully clarified.

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

Usage Guidelines5/5

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

It explicitly routes common cases: impact before editing, native_review after local diffs, breaking_change for public API concerns, and job modes for large repos. It also states the fallback to codelattice_workflow when the target is unclear.

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