Solumbe

Overview Schema Source Related Servers Discussions Admin

Change Impact

change_impact

Read-only

Ranks files likely to own a plain-English change request, with risk flags, suggested tests, and an implementation plan; optionally validates predictions against a git diff and companion repos.

Instructions

Given a plain-English change request, rank the files most likely to own the change, with risk flags, suggested tests, and an implementation plan. Optional diff base surfaces exact changed-file evidence alongside the heuristic. When the repository's .solumberc.json lists companions, companions also carries the top few files each companion repository would own for the same request.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "change_impact"
  }
}

Input Schema

Name	Required	Description
`top`	No	Number of files to return. Defaults to 10.
`path`	No	Repository path. Defaults to current working directory.
`amend`	No	Add files to the declared intent passed as intent, with the reason they belong to the change. Returns the amended record under intent without ranking anything; nothing is written.
`query`	Yes	Plain-English change request.
`intent`	No	With amend: the declared intent to add files to (the record, its JSON, or a path to it). Its request must be the query.
`declare`	No	Also freeze the predicted owner and supporting files as a declared intent (a scope contract) and return it under intent. Call it before editing, then pass that record to review_gate as intent: a changed file that was never declared fails the gate. Nothing is written.
`diffBase`	No	Optional git ref to validate predictions against (e.g. origin/main, HEAD).
`includeMarkdown`	No	Return a compact human-readable markdown report instead of the full JSON. Defaults to false.
`includeUntracked`	No	With diffBase, also count untracked, non-ignored files as changed. Defaults to true; pass false to review only tracked changes.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv4.7.2Oct 22, 2026

addedInput schema / properties / amend

Added value: +{
+  "description": "Add files to the declared intent passed as intent, with the reason they belong to the change. Returns the amended record under intent without ranking anything; nothing is written.",
+  "properties": {
+    "files": {
+      "description": "Repository-relative paths to add.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "reason": {
+      "description": "Why these files belong to the change.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "files",
+    "reason"
+  ],
+  "type": "object"
+}

addedInput schema / properties / declare

Added value: +{
+  "description": "Also freeze the predicted owner and supporting files as a declared intent (a scope contract) and return it under intent. Call it before editing, then pass that record to review_gate as intent: a changed file that was never declared fails the gate. Nothing is written.",
+  "type": "boolean"
+}

addedInput schema / properties / intent

Added value: +{
+  "description": "With amend: the declared intent to add files to (the record, its JSON, or a path to it). Its request must be the query."
+}

Changed1 schema field changedv4.2.0Oct 4, 2026

addedInput schema / properties / includeUntracked

Added value: +{
+  "description": "With diffBase, also count untracked, non-ignored files as changed. Defaults to true; pass false to review only tracked changes.",
+  "type": "boolean"
+}

First observedSep 15, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations declare readOnlyHint=true, and the description reinforces this with 'nothing is written' twice and 'returns the amended record under intent without ranking anything'. It also discloses the extra behavior of diffBase (exact changed-file evidence) and the companions behavior driven by .solumberc.json, which annotations alone would not convey.

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 sentences, front-loaded with the core ranking purpose before the optional diffBase and companions clauses. It is dense but every clause carries information; the companions sentence is the only one that could arguably be trimmed.

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?

For a 9-parameter tool with a nested amend object and no output schema, the description still explains what results come back (ranked files, risk flags, tests, plan, intent record, companions) and the two-mode behavior (ranking vs. amend/declare). An agent has enough to call it correctly and interpret the response.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline would be 3, but the description adds meaning beyond the schema: what diffBase actually does ('surfaces exact changed-file evidence'), what declare freezes, and what companions carries. Minor params like top and path are left to the schema, which is acceptable given full coverage.

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 states a specific verb and resource: 'rank the files most likely to own the change', and enumerates the concrete outputs (risk flags, suggested tests, implementation plan). This is clearly distinguishable from siblings like review_gate or repo_search, which are about gating and locating rather than impact ranking.

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?

It gives explicit workflow guidance: 'Call it before editing, then pass that record to review_gate as intent', and explains that diffBase validates predictions against a git ref. It does not state outright when NOT to use the tool or contrast it with review_context, but the context it does provide is strong and actionable.

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

Deploy Server