Skip to main content
git diff tells you what lines changed. SDL-MCP tells you what that change means at the symbol level and which parts of the codebase are affected — ranked by risk.

Beyond Line Diffs

A delta pack contains four categories of semantic information:
  • Changed symbols with semantic diffs (signature changes, invariant additions/removals, side-effect changes)
  • Blast radius — ranked list of dependent symbols that may be impacted, with distance scores
  • Fan-in trends — which symbols are becoming increasingly depended upon (amplifiers)
  • Risk tiers — whether the interface, behavior, and side effects are stable

Anatomy of a Delta Pack

Here is what a delta pack looks like for a validateToken() signature change:
         Code Change: modified `validateToken()` signature

              ┌───────────────┼───────────────┐
              ▼               ▼               ▼
       signatureDiff    invariantDiff    sideEffectDiff
       ┌────────────┐  ┌─────────────┐  ┌──────────────┐
       │before:     │  │added:       │  │added:        │
       │ (token:    │  │ "throws on  │  │ "logs to     │
       │  string)   │  │  expired"   │  │  audit trail"│
       │after:      │  │removed:     │  │              │
       │ (token:    │  │ (none)      │  │              │
       │  string,   │  └─────────────┘  └──────────────┘
       │  options?: │
       │  object)   │
       └────────────┘


      ┌──── Blast Radius ────┐
      │                      │
      │  1. authenticate()   │ ← distance: 1, direct caller
      │  2. refreshSession() │ ← distance: 1, direct caller
      │  3. AuthMiddleware    │ ← distance: 2, calls authenticate
      │  4. loginHandler()   │ ← distance: 2, calls authenticate
      │  5. auth.test.ts     │ ← test file, flagged for re-run
      │                      │
      └──────────────────────┘

Semantic Diff Fields

Diff FieldWhat It Captures
signatureDiffParameters added, removed, or changed; return type changes; new overloads
invariantDiffPreconditions or postconditions added or removed (e.g., “throws on expired token” added)
sideEffectDiffObservable effects added or removed (e.g., “logs to audit trail” added)
These three fields together answer: did the contract of this symbol change, not just its implementation?

Blast Radius Ranking

Each affected symbol in the blast radius is ranked by multiple signals:
SignalWhat It Measures
DistanceHops in the dependency graph from the changed symbol
Fan-inHow many other symbols depend on the affected symbol
Test proximityWhether the affected symbol has tests that should be re-run
Process participationWhether the symbol is part of a critical call chain
Direct callers (distance 1) appear first. Transitive dependents are ranked below them, with higher-fan-in symbols surfaced ahead of low-impact ones.

Fan-In Trend Analysis (Amplifiers)

SDL-MCP tracks how a symbol’s fan-in changes across versions. A symbol whose fan-in is growing rapidly is an amplifier — changes to it ripple through an increasing number of dependents over time. The delta response flags these explicitly:
{
  "amplifiers": [
    {
      "symbolId": "abc123",
      "previous": 5,
      "current": 12,
      "growthRate": 1.4
    }
  ]
}
An amplifier with growthRate: 1.4 has seen its fan-in grow 40% between versions — a signal that future changes to it will have increasing impact.
Amplifier symbols deserve extra caution during refactoring. Their blast radius will be larger in the future than it is today.

Delta Analysis Workflow

1

Detect code changes

SDL-MCP detects changed symbols between two indexed versions of the codebase — either triggered by re-indexing after a commit, or via live buffer updates during editing.
2

Compute semantic diffs

For each changed symbol, SDL-MCP computes three parallel diffs:
  • signatureDiff — parameter and return type changes
  • invariantDiff — added and removed invariants
  • sideEffectDiff — added and removed side effects
These are extracted from the structured symbol card data, not from line-level text diffs.
3

Compute blast radius

SDL-MCP traverses the dependency graph outward from each changed symbol, collecting all direct and transitive dependents. Each dependent receives a distance score and is ranked by the blast radius signals (distance, fan-in, test proximity, process participation).
4

Run fan-in trend analysis

Fan-in counts from the previous version are compared to the current version. Symbols with rapidly growing fan-in are flagged as amplifiers.
5

Assemble the delta pack

The complete delta pack combines changed symbols with their semantic diffs, the ranked blast radius, and the amplifier list. This is what sdl.delta.get returns.

PR Risk Analysis

sdl.pr.risk.analyze wraps delta analysis into a structured risk assessment with numeric scoring, categorized findings, and prioritized test recommendations.
  Risk Score: 72 (HIGH)

  Findings:
  ├── [HIGH] Signature change on validateToken (fan-in: 12)
  ├── [MED]  New side effect: audit trail logging
  └── [LOW]  Invariant addition (non-breaking)

  Recommended Tests:
  ├── [HIGH] Re-run auth.test.ts (direct coverage)
  ├── [HIGH] Re-run middleware.test.ts (blast radius)
  └── [MED]  Add test for new options parameter

Risk Scoring Formula

The overall risk score (0–100) is a weighted average of four components:
Risk Score = ChangedSymbols    × 0.4
           + BlastRadius       × 0.3
           + InterfaceStability × 0.2
           + SideEffects       × 0.1
ComponentWeightWhat It Captures
Changed Symbols40%Average per-symbol risk: interface stability, behavior stability, side-effect changes
Blast Radius30%Number of direct dependents, transitive distance, dependency rank scores
Interface Stability20%Proportion of changes with signature modifications
Side Effects10%Proportion of changes affecting side effects

Finding Types

TypeSeverityDescription
high-risk-changeshighSymbols with risk score ≥ 70
interface-breaking-changeshighModified symbols with signature changes
side-effect-changesmediumModified symbols with side-effect changes
removed-symbolsmediumDeleted symbols that may break dependents
large-impact-radiusmediumMany direct dependents (> 10) potentially affected
new-symbolslowNewly added symbols
TypePriorityWhen Recommended
unit-testshighModified symbols present
integration-testshighInterface-breaking changes detected
regression-testsmediumDirect dependents in blast radius
api-breakage-testshighSymbols were removed
new-coverage-testslowNew symbols added

CI/CD Integration

Use sdl.pr.risk.analyze in a pipeline to gate merges on risk score:
# Index the base branch
sdl-mcp index --repo-id my-api

# Start the MCP server and analyze PR changes
sdl-mcp serve --stdio &
echo '{
  "tool": "sdl.pr.risk.analyze",
  "arguments": {
    "repoId": "my-api",
    "fromVersion": "main",
    "toVersion": "feature-branch",
    "riskThreshold": 70
  }
}' | mcp-client

# Check the escalationRequired field in the response.
# If true, block the merge and require additional review.
When escalationRequired is true in the response, the PR’s risk score exceeded the threshold and the merge should be blocked pending additional review.
sdl.pr.risk.analyze requires both fromVersion and toVersion to be indexed. Run sdl-mcp index on both branches before invoking the tool in CI.

MCP Tools for Delta and Risk

ToolDescription
sdl.delta.getRaw delta pack: semantic diffs, blast radius, amplifiers
sdl.pr.risk.analyzeStructured risk assessment with score, findings, and test recommendations
sdl.slice.refreshDelta-scoped slice update — returns only cards that changed since the last slice version

Build docs developers (and LLMs) love