Skip to main content
Glama
raultov

knot

by raultov
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Hybrid

List cross-repository dependencies

list_repo_dependencies
Read-onlyIdempotent

Discover forward and reverse repository dependencies from build declarations. Use reverse mode to assess impact 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. Empty lookups are explained in the response text with a three-way classification: declares-but-resolves-without-edge (stale graph, re-index hint), declares-but-nothing-resolves (not indexed), or nothing declared; the reverse direction names consumers that declare the repo without an edge yet.

Parameter guidance: 'repo_name' is required and must match the name used during indexing. 'max_depth' defaults to 3 (1 = direct only) and applies to both directions — in reverse mode it follows dependents transitively. '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, max: 10). Use 1 for direct dependencies only. Requests above 10 are clamped to 10 (and below 1 to 1). Applies to both directions: with reverse=true it follows dependents transitively.
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. Changed1 schema field changedv1.9.6
    • changedInput schema / properties / max_depth / description
      Previous value: -"Maximum depth for transitive dependency traversal (default: 3). Use 1 for direct dependencies only. Higher values follow chains deeper. Must be between 1 and 10."New value: +"Maximum depth for transitive dependency traversal (default: 3, max: 10). Use 1 for direct dependencies only. Requests above 10 are clamped to 10 (and below 1 to 1). Applies to both directions: with reverse=true it follows dependents transitively."
  2. 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"
+]
  3. Addedv1.4.0
  4. Removedv1.3.8
  5. Added
  6. Removedv1.3.2
  7. Addedv1.2.8
  8. Removedv1.2.7
  9. Addedv1.2.5

TDQS

A4.5/5.0
Behavior5/5

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

The description goes well beyond the readOnly/idempotent annotations by disclosing that it is a side-effect-free graph traversal, specifying the JSON array return type, and explaining empty result semantics with a three-way classification including stale-graph and not-indexed cases. This is rich, actionable behavioral detail.

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?

The description is long but exceptionally well structured with labeled paragraphs for usage, behavior, return values, parameter guidance, and supported build systems. Every sentence carries actionable information and is front-loaded with the core purpose before 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 there is no output schema, the description fully compensates by explaining return shape, empty-result semantics, direction behavior, depth semantics, and supported build systems. For a 3-parameter tool with rich annotations, nothing essential is missing.

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%, so the baseline is 3. The description mostly restates the schema's parameter guidance (repo_name required, max_depth default/applies to both directions, reverse toggling) rather than adding entirely new meaning, though it does usefully summarize the key constraints in one place.

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 description states a specific verb ('lookup') and precise resource ('cross-repository dependency graph'), and explicitly frames the two questions it answers: which repos does this repo depend on and which depend on it. This clearly distinguishes it from sibling tools like list_repositories and find_callers.

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?

Explicit usage guidance is provided: use before cross-repo analysis for call tracing, and use reverse mode for impact analysis before breaking changes. It does not explicitly name alternatives or state when not to use it, so it stops short of a 5, but the context is clear enough for an agent to select it appropriately.

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

Deploy Server

Other Tools