Skip to main content
Glama

get_change_risk

Scores a commit or range by diff shape to rank change risk against recent commits, highlighting impacted tests and uncovered lines.

Instructions

Score a live commit or base..head range from its diff shape.

Use this for a pre-merge score of a commit or PR range. It is distinct from
``get_risk``, which assesses indexed files and PR blast radius. ``extensions``
restricts counted suffixes; ``exclude_patterns`` omits gitignore-style paths.
Both filters also apply to the baseline used for the repository percentile.

Prefer ``risk_percentile`` as the indicator of change risk: it ranks this
change against sampled recent commits in the same repository. Summarize it
with ``review_priority`` and ``classification``. ``score``, ``probability``,
and ``level`` are secondary corpus-calibrated context, the fallback only
when ``risk_percentile`` is unavailable.

``impacted_tests`` names the tests the per-test coverage map proves execute
the change's changed *lines* (line-precise, narrower than get_risk's
file-level ``tests_to_run``), with ``missing_tests`` buckets for changed
lines no test covers. Its ``status`` is ``no_map`` (unknown, run the full
suite), never "untested", when no map is ingested.

Args:
    revspec: Commit or ``base..head`` range to score. Defaults to ``HEAD``.
    repo: Repository alias in workspace mode; omit for the default repository.
    extensions: File suffixes to count, for example ``[".py", ".ts"]``.
    exclude_patterns: Gitignore-style paths to omit, for example ``["tests/", "*.md"]``.
    baseline: Recent commits to sample for percentile ranking; 0 disables it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
repoNo
revspecNoHEAD
baselineNo
extensionsNo
exclude_patternsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior4/5

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

No annotations provided, but description covers key behaviors: filter application to baseline, risk_percentile usage, impact_tests status values. Could mention auth or rate limits, but adequate for read-like scoring tool.

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?

Detailed but well-structured. Uses paragraphs and clear Args list. Every sentence adds value.

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 5 parameters and existing output schema, description covers output fields (risk_percentile, score, classification, impact_tests) and nuances like status meaning. Complete for this tool.

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

Parameters5/5

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

With 0% schema coverage, description compensates fully. Explains revspec, repo, extensions, exclude_patterns, baseline with defaults and context of workspace mode, gitignore-style patterns, etc.

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?

Clearly states it scores a live commit or range from its diff shape. Distinguishes from get_risk by specifying what each does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use this for a pre-merge score of a commit or PR range.' and contrasts with get_risk. Also advises preferring risk_percentile.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/repowise-dev/repowise'

If you have feedback or need assistance with the MCP directory API, please join our Discord server