Skip to main content
Glama

Diff two indexes (change impact)

codetopo_diff
Read-only

Compare two code indexes or snapshots to identify added, removed, and changed symbols and edges, and track blast-radius movement of every touched symbol between versions.

Instructions

Compare two indexes (or two snapshot files): added, removed, and changed nodes and edges, plus the blast-radius movement of every touched symbol. Give exactly one before source and one after source.

Input Schema

NameRequiredDescriptionDefault
after_db_pathNoPath to the after index database.
after_snapshotNoPath to the after snapshot file (alternative to after_db_path).
before_db_pathNoPath to the before index database.
before_snapshotNoPath to the before snapshot file (alternative to before_db_path).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.6.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already establish read-only, non-destructive, closed-world behavior. The description adds genuinely new context by defining the output surface (structural deltas plus blast-radius movement) and the cardinality constraint on sources, which the schema does not enforce. It doesn't say anything about cost on large indexes, which would have pushed this to a 5.

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?

Two tight sentences: the first front-loads what is compared and what comes back, the second delivers the only hard input constraint. No filler, nothing repeated from the title.

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?

With no output schema, the description carries return-value duty and does summarize the result shape (node/edge deltas plus blast-radius movement). What's missing is scale/cost expectation and how snapshot inputs relate to codetopo_snapshot, but nothing needed to invoke it correctly is absent.

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 coverage is 100%, so baseline is 3. The description earns above baseline by stating the mutual-exclusivity rule ('exactly one before source and one after source'), which the flat four-property schema does not encode as a oneOf — this is real added semantics beyond the parameter descriptions.

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?

Specific verb+resource: compares two indexes or snapshot files and enumerates what it returns (added/removed/changed nodes and edges, blast-radius movement). It's clearly distinct from siblings like codetopo_snapshot (which produces snapshots) or codetopo_blast_radius (single-symbol analysis), though it doesn't name those siblings explicitly.

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?

Gives an important input rule — exactly one before source and one after source — which implies the tool is for comparing two states of the same codebase. But it never states when to prefer this over codetopo_blast_radius or when a diff is not appropriate (e.g. unrelated codebases), so usage context is only implied.

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