Skip to main content
Glama
BASHBOP

Solumbe

by BASHBOP
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Convergence Score

convergence_score

Measure alignment between a stated task and your git diff with a deterministic 0-100 score, covering intent coverage, scope, and risk alignment.

Instructions

Score convergence: a deterministic 0–100 measure of the distance between a stated task (intent) and the actual git diff (execution), with sub-scores for Coverage (did the intent happen?), Scope (did only the intent happen?), and Risk alignment (did unrequested drift land on risk-sensitive paths?). Composed from the change_impact diff comparison and the shared risk vocabulary — no model, no new analysis. New files beside a confirmed owner and tests of confirmed files count as in scope, listed under drivers.inferredRelated. Emits a recomputable receipt (a timestamp-free hash anyone can regenerate and verify) as durable evidence. Requires a base git ref to diff against; scores the working tree's tracked changes unless head or staged selects an exact subject.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
topNoNumber of predicted owner files to consider. Defaults to 10.
baseYesGit ref to diff against (e.g. origin/main, HEAD~1). Required.
headNoScore exactly base..head (a direct tree diff, no merge base) instead of the working tree, and bind the receipt to the head commit and its tree SHA. Uncommitted and untracked files play no part. Cannot be combined with staged.
pathNoRepository path. Defaults to current working directory.
queryYesThe stated task / intent to measure against the diff, e.g. "add Stripe refunds".
stagedNoMeasure only the exact Git index tree and bind the receipt to its tree SHA. May create Git object or index-cache metadata; source files are unchanged.
includeMarkdownNoReturn a compact human-readable markdown report instead of the full JSON. Defaults to false.
includeUntrackedNoWorking-tree mode only: also score untracked, non-ignored files. Defaults to false; untracked files are otherwise listed under untracked and not scored.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.15.2
    • addedInput schema / properties / head
      Added value: +{
+  "description": "Score exactly base..head (a direct tree diff, no merge base) instead of the working tree, and bind the receipt to the head commit and its tree SHA. Uncommitted and untracked files play no part. Cannot be combined with staged.",
+  "type": "string"
+}
    • addedInput schema / properties / includeUntracked
      Added value: +{
+  "description": "Working-tree mode only: also score untracked, non-ignored files. Defaults to false; untracked files are otherwise listed under untracked and not scored.",
+  "type": "boolean"
+}
  2. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the sparse readOnlyHint=false annotation, the description discloses determinism, the absence of model analysis, the recomputable timestamp-free receipt, the default working-tree subject, and the side effect that staged mode 'may create Git object or index-cache metadata' while source files remain unchanged. This is rich behavioral context that helps an agent anticipate side effects and reproducibility.

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?

The description is dense but every sentence earns its place: definition, sub-scores, composition, scope rules, receipt, and mode selection. It is front-loaded with the core purpose and avoids filler or repetition of schema details.

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?

Given the tool's complexity—8 parameters, no output schema, and a rich sibling set—the description covers the essential invocation context: what is measured, how scope is determined, how modes alter the subject, side effects, and the durable receipt. An agent has enough to select and call the tool correctly.

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 is 3, but the description adds meaningful cross-parameter semantics: it explains that head and staged select an exact subject instead of the working tree, that includeUntracked only applies in working-tree mode, and that staged can create metadata. This goes beyond the individual parameter descriptions in the schema.

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 opens with a specific verb and resource: 'Score convergence: a deterministic 0–100 measure of the distance between a stated task (intent) and the actual git diff (execution).' It names the three sub-scores and explicitly distinguishes itself from the sibling change_impact tool by stating it is 'composed from the change_impact diff comparison' rather than being a raw diff tool.

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?

The description gives clear context for invocation: it requires a base git ref, defaults to the working tree, and explains the head/staged modes. However, it never explicitly states when to choose this tool over siblings like change_impact, review_gate, or model_route, nor does it provide exclusions or alternative conditions.

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