Skip to main content
Glama

List cross-repository dependencies

list_repo_dependencies
Read-onlyIdempotent

Show which repositories a repo depends on, and which repos depend on it. Traverse cross-repo dependency graphs for impact analysis before breaking changes.

Instructions

Read-only cross-repository dependency graph lookup. Shows which repositories depend on each other via build system declarations (Maven, Gradle, Cargo, npm, NuGet). Answers 'which repos does this repo depend on?' and 'which repos depend on this repo?'.

Usage: Use BEFORE cross-repo analysis to discover which other indexed repos are available for call tracing. Use reverse mode for impact analysis before making breaking changes in shared libraries.

Behaviour & Return: Read-only graph traversal with no side effects. Returns a JSON array of repository names. Empty results mean no DEPENDS_ON relationships exist for that repo.

Parameter guidance: 'repo_name' is required and must match the name used during indexing. 'max_depth' defaults to 3 (1 = direct only). 'reverse' toggles between forward and reverse dependency lookup.

Supports all build systems indexed by knot: Maven, Gradle, Cargo, npm, NuGet (.csproj + Central Package Management via Directory.Packages.props). C# repos that previously reported build_system: "none" now report "nuget" on re-index; knot-indexer --clean is recommended for immediate effect.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
reverseNoIf true, show repositories that depend ON this repo (reverse lookup). If false (default), show repositories this repo depends ON. Use reverse for impact analysis before breaking changes.
max_depthNoMaximum depth for transitive dependency traversal (default: 3). Use 1 for direct dependencies only. Higher values follow chains deeper. Must be between 1 and 10.
repo_nameYesRepository name to show dependencies for. Must match the name used during indexing (e.g., 'my-java-repo', 'auth-service'). This is REQUIRED — there is no default.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.9.4
    • changedInput schema / properties / max_depth / type
      Previous value: -"integer"New value: +[
      +  "integer",
      +  "null"
      +]
    • changedInput schema / properties / reverse / type
      Previous value: -"boolean"New value: +[
      +  "boolean",
      +  "null"
      +]
  2. Addedv1.4.0
  3. Removedv1.3.8
  4. Added
  5. Removedv1.3.2
  6. Addedv1.2.8
  7. Removedv1.2.7
  8. Addedv1.2.5

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world scope, so the safety profile is covered. The description still adds value beyond that: 'no side effects', the return shape (JSON array of repository names), and the meaning of empty results ('no DEPENDS_ON relationships exist'). It doesn't discuss depth limits on traversal or performance, which keeps it below 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Uses clear labeled sections (Usage, Behaviour & Return, Parameter guidance) with the core purpose front-loaded in the first sentence. The final paragraph on knot build-system support and re-indexing is genuinely bulky and somewhat tangential, costing it a point.

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 the return-value burden and does so ('JSON array of repository names', empty-result meaning), and annotations cover the safety profile. Build-system coverage (Maven, Gradle, Cargo, npm, NuGet) is spelled out. Minor gaps remain around traversal cost or ordering of results.

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

Parameters3/5

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

Schema description coverage is 100%, and the schema already documents repo_name, reverse, and max_depth with defaults and bounds. The description largely restates that ('max_depth defaults to 3 (1 = direct only)', 'reverse toggles between forward and reverse'), adding only light interpretation. Per the baseline rule, 3 is appropriate when the schema does the heavy lifting.

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?

Names a specific verb and resource ('cross-repository dependency graph lookup') and defines its scope precisely: which repos depend on each other via build system declarations. It even frames the two exact questions it answers, which separates it from list_repositories (enumerate repos) and find_callers (trace calls) without needing to name them.

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?

Gives explicit when-to-use guidance ('Use BEFORE cross-repo analysis to discover which other indexed repos are available for call tracing') and conditions for reverse mode ('impact analysis before making breaking changes in shared libraries'). It lacks an explicit when-not-to-use statement or a direct named alternative from the sibling set, so it stops short of a 5.

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