Skip to main content
Glama

get_risk

Assess code change risk by combining git history, dependency reach, and security findings to reveal likely breakage, missing tests, and co-change partners.

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. 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
NameRequiredDescriptionDefault
repoNo
includeNo
targetsYes
changed_filesNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Install Server

TDQS

A4.9/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 behavioral burden and does so thoroughly. It discloses that structural reach is not proof of runtime breakage, that structural_impact_score is uncalibrated and never a probability, that overall_risk_score is a deprecated alias, and that include-gated blocks are projections rather than omissions.

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 description is long, but every sentence adds a distinct fact and it is well structured with an opening purpose, signal definitions, PR-mode directives, caveats, response limits, and an Args section. It could be trimmed, but the density is justified for a tool with many behavioral caveats.

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 zero annotations, zero schema descriptions, and a complex response surface, this description is complete. It covers purpose, selection criteria, parameter semantics, response shape, size limits, recovery metadata, and safety caveats, leaving nothing essential for correct invocation unexplained.

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?

Schema description coverage is 0%, but the Args section compensates by explaining all four parameters: targets as file paths, repo as usually omitted, changed_files as PR-changed files for blast-radius mode, and include as opt-in blocks with concrete values like 'graph', 'churn', and 'scales'. This fully covers the parameter semantics gap.

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 opening line, 'What history says about touching these files — bug fixes, churn, owners,' states the tool's purpose with a specific verb and resource. It further clarifies by describing the fused signal types and explicitly distinguishing get_risk from get_change_risk, which handles commit/range scoring.

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?

The description gives explicit when-to-use guidance: pass changed_files for PR mode, read the directive block first, and use get_change_risk instead for commits or base..head ranges. It also notes that repo is 'usually omitted,' giving the agent practical invocation context.

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

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