Skip to main content
Glama
coffeecoproject

LayerMap

by coffeecoproject
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

What uncommitted changes affect (LayerMap)

project_check_changes
Read-onlyIdempotent

Check uncommitted changes to list affected entry points, HTTP routes, jobs, commands and related tests before reporting work done.

Instructions

Use this once the edits are done, before reporting the work done: it lists what the uncommitted changes affect, from the changed functions up to the HTTP routes, jobs and commands that reach them, plus the existing tests related to them. Compares the working tree with a commit (HEAD by default, so uncommitted and untracked changes), finds the declarations the diff changed, removed or renamed, and follows their callers up to 8 levels. It reports, conclusion first: AFFECTED ENTRY POINTS reached through resolved calls, each route with its HTTP methods and full path and the chain to the change; POSSIBLY AFFECTED ones reached only through a call on an interface or base member; REQUESTED BY, the code and templates outside the tests that request the path of a route whose handler the change reaches or a route it removed, found by text; EXISTING TESTS CHANGED, the tests that existed before the diff and whose code it changed or removed; SHARED BY, when tests reach the changed code through more than one area (package or module), so a change meant for one feature may change others; NAMES STILL USED ELSEWHERE, environment variables and configuration keys the diff removed from a file that other files still read or set, found by text; NEW MODULE DEPENDENCIES, imports between the modules of the project overview that the base did not have, and those that make two modules depend on each other, for you to judge against the project's layers; EXISTING CODE LIKE THE NEW CODE, declarations the diff adds whose code reads almost the same as code the project already has; LEFT WITHOUT CALLERS, declarations whose last callers outside the tests the diff removed or changed, and that nothing extends, implements, overrides or wires with a decorator; CHECK BY HAND for what a static map cannot follow (changed configuration, templates, migrations or dependency files, changed route registrations, declarations with no callers, calls by name on receivers of unknown type); and RELATED TESTS, the existing test files that call the changed code, import a changed file or sit beside it; given tests, NOT REACHED BY THE GIVEN TESTS, the changed declarations none of them calls or requests through a route, with the entry points above them. It does not run or write tests: run the related ones if the change needs verifying; a failing or rewritten test of a feature the request is not about means the change leaked, so restore the test and narrow the change; a new dependency that runs against the layers or closes a cycle means moving what both modules need down rather than importing upward; new code like existing code means using the existing code, or removing the old if the new replaces it; code left without callers means deleting it, with the tests that only test it, when the change replaced it; call it once when the edits are done; and confirm the entry points in source, since an empty list does not prove a change safe.

Input Schema

NameRequiredDescriptionDefault
baseNoCommit, branch or tag to compare the working tree with (HEAD, so the uncommitted changes, by default; main for a whole branch).HEAD
pathNoA file or directory in the repository to check, when the session works in more than one; the check covers that repository's whole working tree.
testsNoTest files that should cover the change, such as the ones you wrote for it, as paths are given to the other tools: the report then adds NOT REACHED BY THE GIVEN TESTS, the changed declarations none of them calls or requests through a route, with the entry points above them.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.1.31
    • addedInput schema / properties / path
      Added value: +{
+  "description": "A file or directory in the repository to check, when the session works in more than one; the check covers that repository's whole working tree.",
+  "type": "string"
+}
    • addedInput schema / properties / tests
      Added value: +{
+  "description": "Test files that should cover the change, such as the ones you wrote for it, as paths are given to the other tools: the report then adds NOT REACHED BY THE GIVEN TESTS, the changed declarations none of them calls or requests through a route, with the entry points above them.",
+  "items": {
+    "maxLength": 1000,
+    "minLength": 1,
+    "type": "string"
+  },
+  "maxItems": 200,
+  "type": "array"
+}
  2. Addedv0.1.17

TDQS

A4.3/5.0
Behavior5/5

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

Annotations only say readOnly/idempotent/non-destructive; the description adds substantial context beyond that: it never runs or writes tests, defaults to HEAD and includes untracked files, follows callers only 8 levels, uses text matching for REQUESTED BY and NAMES STILL USED ELSEWHERE, and explicitly lists what static analysis cannot follow (config, templates, migrations, unknown receiver types). This is exactly the kind of limitation disclosure an agent needs.

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

Conciseness3/5

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

It is front-loaded with the trigger and the report sections are capitalized, giving it a navigable structure. But it is one very long, comma-chained sentence with visible repetition ('NOT REACHED BY THE GIVEN TESTS' defined twice, 'call it once when the edits are done' echoing the opening), which harms scannability.

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?

There is no output schema, so the description carries the burden of explaining return values — and it does, defining every report section and how findings should be acted on (restore leaked tests, move shared dependencies, delete uncalled code). Nothing an agent needs to interpret the result is missing.

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 description coverage is 100%, so all three parameters are already documented in the schema. The description restates the same semantics (HEAD default, path scoping, tests adding NOT REACHED BY THE GIVEN TESTS) without adding syntax or format detail, so the baseline of 3 applies.

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?

States a specific verb and resource: it lists what uncommitted changes affect, tracing changed declarations up to entry points and related tests. The enumerated report sections (AFFECTED ENTRY POINTS, POSSIBLY AFFECTED, REQUESTED BY, etc.) make it unmistakable against siblings like project_find_references or project_search_map, which locate code rather than assess change impact.

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?

Gives an explicit trigger ('once the edits are done, before reporting the work done') and reinforces it with 'call it once when the edits are done', plus a caution that an empty list does not prove a change safe. It does not name or exclude sibling tools, so the alternative-selection dimension is left implicit, keeping 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