repowise

get_risk

Assess file or PR change risk by fusing git history, dependency reach, and security findings to flag potential breakage and tests to run.

Instructions

What history says about touching these files — bug fixes, churn, owners.

Fuses git temporal signals (``hotspot_score``/``owner_pct`` are 0-1; trend;
bus factor) with graph topology. ``dependents`` are directed structural
reach (source depends on target), ``consumers`` require typed contract links,
and ``co_change_partners`` are historical correlation only. Those counts
are a floor over the indexed graph. Structural reach is not proof of
runtime breakage. The response also includes security
findings. Pass changed_files for PR mode: the response leads with a
directive block (may_break, missing_cochanges, missing_tests,
tests_to_run) — read it first. Each test_recommendations row carries a
measured or inferred basis, and coverage availability is explicit. To
score a commit or ``base..head`` range instead, use ``get_change_risk``.

In PR mode ``structural_impact_score`` is an uncalibrated 0-10 structural
heuristic, never a runtime-breakage probability; ``overall_risk_score`` is
its deprecated exact alias.

Default responses fit 24,000 serialized chars; nonempty ``include`` uses
32,000. Reductions carry counts and ``_meta.omitted`` recovery refs;
``_meta.recovery_unavailable`` names a storage failure.
Include-gated blocks are projections, not omissions.

Args:
    targets: file paths to assess.
    repo: usually omitted.
    changed_files: PR-changed files for blast-radius mode.
    include: opt-in blocks - "graph", "churn", "scales" (units and
        calibration for every scalar; identical per call, so ask once).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`repo`	No
`include`	No
`targets`	Yes
`changed_files`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.48.0Sep 3, 2026

addedInput schema / properties / include

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Include"
+}

First observedv0.1.0Jul 12, 2026

TDQS

A4.2/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so extensively: it discloses response size limits (24,000 default, 32,000 with include), truncation semantics ('Reductions carry counts and _meta.omitted recovery refs; _meta.recovery_unavailable names a storage failure'), that include-gated blocks are projections rather than omissions, and the epistemic caveats ('Structural reach is not proof of runtime breakage'; 'structural_impact_score is an uncalibrated 0-10 structural heuristic, never a runtime-breakage probability'; 'overall_risk_score is its deprecated exact alias'). This is unusually rich behavioral context for a large-payload read tool.

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?

Purpose is front-loaded well, but the body is dense and repetitive: PR mode is introduced twice, structural_impact_score is discussed in two separate places, and the exact character-budget figures plus recovery-ref mechanics occupy substantial space. Much of it earns its place, but the redundancy and length keep it below the top scores.

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 four-parameter, output-schema-backed tool with zero annotation coverage, the description covers inputs, output shape, metadata/recovery semantics, and the meaning of the headline scores. An output schema exists, so it needn't restate return fields, and it appropriately focuses on the epistemic and truncation caveats an agent needs to interpret results 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 description coverage is 0% (the schema only supplies titles and types), so the description must compensate and does: it explains targets, why repo is 'usually omitted', the role of changed_files in PR mode, and enumerates include values ('graph', 'churn', 'scales' with units/calibration). It stops short of format-level detail (e.g., path conventions for targets), so a 4 rather than a 5.

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 opening sentence states the resource and the evidence it fuses ('What history says about touching these files — bug fixes, churn, owners'), which is a concrete, non-tautological purpose. It explicitly distinguishes itself from the sibling get_change_risk ('To score a commit or base..head range instead, use get_change_risk'), so an agent can route between them. The only mild weakness is that the 'verb' is diffuse — the description reads more like a data-fusion contract than a crisp action.

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 names a concrete trigger ('Pass changed_files for PR mode') and points to the divergent sibling for a different scope (commit or base..head → get_change_risk). It also tells the caller to 'read [the directive block] first' and that 'scale' includes are call-invariant ('ask once'). It does not spell out when NOT to call it or prerequisites, so it falls short of a full 5.

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

Deploy Server