Skip to main content
Glama
BASHBOP

Solumbe

by BASHBOP
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Change Impact

change_impact
Read-only

Rank likely file owners for a plain-English change request, with risk flags, tests, and an implementation plan.

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. Uses a per-user external cache and leaves the target repository unchanged.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
topNoNumber of files to return. Defaults to 10.
pathNoRepository path. Defaults to current working directory.
queryYesPlain-English change request.
diffBaseNoOptional git ref to validate predictions against (e.g. origin/main, HEAD).
includeMarkdownNoReturn a compact human-readable markdown report instead of the full JSON. Defaults to false.
includeUntrackedNoWith 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.

  1. Changed1 schema field changedv4.2.0
    • 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"
+}
  2. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=true, so the description adds real value: it discloses that a per-user external cache is used and that the target repository is left unchanged, which reassures an agent about side effects. It does not discuss cost, latency, permissions, or cache invalidation, keeping it below a 5.

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?

The primary capability is front-loaded in the first sentence, and the follow-on sentences each carry distinct information (diffBase, companions, caching/no-repo-mutation). It is a bit dense and sentence three is long, but nothing is wasted.

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?

With no output schema, the description does the job of describing returns: ranked files, risk flags, suggested tests, an implementation plan, optional changed-file evidence, and companion-repo results. Combined with the readOnly annotation and full schema coverage, an agent has everything needed to call it correctly.

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% and all six parameters are documented inline, so the baseline is 3. The description clarifies the semantic role of diffBase (exact changed-file evidence alongside the heuristic) and the companions behavior, but that behavior is mostly about output rather than parameter syntax, so it does not meaningfully exceed the schema.

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 verb/resource pairing is very specific: given a change request, it ranks files most likely to own the change and returns risk flags, suggested tests and an implementation plan. That clearly sets it apart from read-oriented siblings like repo_search or repo_map in substance, but it never names a sibling or explicitly contrasts itself with them, so it stops short of a 5.

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 implied by 'Given a plain-English change request' and the conditional notes on diffBase and companions, but there is no explicit when-to-use/when-not guidance and no routing to or away from alternatives like repo_inspect or context_pack. An agent can infer the trigger, but it is left to inference.

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