Skip to main content
Glama
Sign In
Solumbe

Solumbe

by BASHBOP
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Convergence Score

convergence_score

Measures how closely an actual git diff matches the stated task intent, returning a deterministic 0-100 score plus coverage, scope, and risk-alignment sub-scores against a base ref.

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?). No model. A task that predicts no owner file is band inconclusive, with no score. Emits a recomputable receipt (a hash anyone can regenerate). Requires a base git ref to diff against; scores the working tree's tracked changes unless head or staged selects an exact subject.

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>",
      "base": "<base>"
    },
    "name": "convergence_score"
  }
}

Input 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 instead of the working tree; the receipt binds to the head commit. 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".
intentNoDeclared intent from change_impact declare (record, JSON, or path): score against the declared files instead of a live prediction.
stagedNoScore only the Git index; the receipt binds to its tree.
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. Changed3 schema fields changedv4.10.0
    • changedInput schema / properties / head / description
      Previous value: -"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."New value: +"Score exactly base..head instead of the working tree; the receipt binds to the head commit. Cannot be combined with staged."
    • changedInput schema / properties / intent / description
      Previous value: -"Optional declared intent (from change_impact with declare: the record, its JSON, or a path to it). The diff is then scored against the files declared before the edit instead of a live prediction, and the receipt names the contract."New value: +"Declared intent from change_impact declare (record, JSON, or path): score against the declared files instead of a live prediction."
    • changedInput schema / properties / staged / description
      Previous value: -"Measure 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."New value: +"Score only the Git index; the receipt binds to its tree."
  2. Changed1 schema field changedv4.7.2
    • addedInput schema / properties / intent
      Added value: +{
+  "description": "Optional declared intent (from change_impact with declare: the record, its JSON, or a path to it). The diff is then scored against the files declared before the edit instead of a live prediction, and the receipt names the contract."
+}
  3. 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"
+}
  4. First observed

TDQS

A4/5.0
Behavior5/5

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

Even though annotations only state readOnlyHint=false, the description adds substantial behavioral context: no model is used, scoring is deterministic, an inconclusive band exists, a recomputable receipt is emitted, and untracked/staged/head behavior is clarified. This gives an agent real insight beyond the annotation.

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 front-loaded with the core purpose and stays compact despite covering the scoring model, sub-scores, inconclusive cases, receipt, and subject selection. Each sentence adds useful information without repetition.

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

Completeness4/5

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

For a complex 9-parameter tool with no output schema, the description covers the essential invocation context and output meaning at a high level: score range, sub-scores, inconclusive band, and receipt. It still does not describe the full JSON return shape or all mode interactions, so it is strong but not fully complete.

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 the parameters are already well documented. The description adds high-level meaning for base, head/staged subject selection, and intent-vs-diff scoring, but it does not explain most individual parameters such as top, includeMarkdown, includeUntracked, or path beyond what the schema already says.

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 gives a specific verb and resource: score convergence as a deterministic 0–100 distance between stated intent and git diff, with named sub-scores. It is clearly a scoring operation unlike the sibling tools, but it does not explicitly contrast itself with alternatives such as change_impact or review_gate.

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 explains operational context—base is required, working tree is scored by default, and head/staged select alternate subjects—but it does not state when to choose this tool over sibling tools or when not to use it. Usage is implied rather than explicitly routed.

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