Skip to main content
Glama

get_dependency_graph

Map Java type or package dependencies as nodes and edges to trace imports, inheritance, fields, parameters, and return types. Requires a loaded project.

Instructions

Get package/type dependencies.

USAGE: get_dependency_graph(scope="type", name="com.example.OrderService") USAGE: get_dependency_graph(scope="package", name="com.example.service") OUTPUT: Dependency graph with nodes and edges

Each node has a name and a kind. A node that denotes a type is named by the type's fully qualified name with '$' between nested types (com.example.Outer$Inner), however the source names it, so each type is one node. A node that denotes a type, or a member of one (a static import), also has the package of that type as JDT resolves it ("(default package)" for the default package). A node that denotes a package (every node at package scope, and an on-demand package import) has no package; neither has a name that does not resolve.

At package scope the graph covers the package and its subpackages: each import is an edge from the package of the file declaring it to the package it imports, and every edge's source and target is a node, as is the requested package. A name that is no package of the project's source folders, a library's package such as java.util included, is SYMBOL_NOT_FOUND.

depth is 1 or more at either scope; below 1 is INVALID_PARAMETER. At type scope it is how many steps of dependencies are followed from the type: 1 lists the type's own dependencies, 2 also those of each dependency with source, and so on. Package scope does not use it.

Dependency types tracked:

  • import: Direct imports

  • extends: Superclass inheritance

  • implements: Interface implementation

  • field: Field type dependencies

  • parameter: Method parameter types

  • return: Method return types

Requires load_project to be called first.

Input Schema

NameRequiredDescriptionDefault
nameYesType name (fully qualified) or package name
depthNoHow deep to follow dependencies, 1 or more (default: 1)
scopeYesScope: 'type' or 'package'
includeExternalNoInclude JDK/library dependencies (default: false)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.5.3
    • changedInput schema / properties / depth / description
      Previous value: -"How deep to follow dependencies (default: 1)"New value: +"How deep to follow dependencies, 1 or more (default: 1)"
  2. Addedv1.3.4
  3. Removedv1.3.3
  4. First observedv1.2.0

TDQS

A4.3/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 explains node naming, package-scope coverage, edge semantics, dependency types tracked, depth behavior, and error codes. It also discloses the load_project prerequisite.

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 front-loaded with purpose and usage, then structured with output details and dependency types. It is somewhat long, but for a dependency-graph tool most of the detail is relevant and earns its place.

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 the absence of an output schema and annotations, the description explains the returned graph, node identity, package semantics, depth behavior, and failure modes. An agent has enough information to call the tool correctly.

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 parameter definitions are already strong, but the description adds meaningful semantics for scope, depth, node resolution, and package-scope behavior. It does not explicitly explain the includeExternal parameter, which keeps it from a 5.

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?

The description states a specific verb and resource: "Get package/type dependencies." Examples for type and package scope make the operation unambiguous, but the description does not explicitly contrast itself with nearby tools such as get_type_hierarchy or find_circular_dependencies.

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?

It gives concrete invocation examples for both scopes and notes that load_project must be called first. It also defines depth and error behavior, but does not say when to choose this tool over sibling dependency-related tools.

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