Skip to main content
Glama
Sign In
gograph

gograph

by ozgurcd
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Local

gograph_deps

Read-onlyIdempotent

List all dependencies of a target package. Use direct or transitive imports to audit package layering and understand dependency relationships across the code.

Instructions

List the import dependencies of a named package. With transitive=false (default), returns direct imports; true returns the BFS closure. The MCP server refreshes source analysis before the call. Read-only; no side effects. WHEN TO USE: When auditing package layering. NOT TO USE: For reverse lookup (use gograph_dependents). RETURNS: direct[] and transitive[] arrays; with mermaid=true, Mermaid flowchart text; found:false when absent.

Input Schema

NameRequiredDescriptionDefault
rootNoAbsolute path of the checkout you are working in (your cwd or git worktree). Must be this server's repository or one of its git worktrees; the answer then comes from that checkout's own graph. A path elsewhere is refused. Alias: cwd. Omit only when the configured checkout is the one you mean.
mermaidNoReturn Mermaid flowchart text instead of structured JSON
packageYesThe target package path or name to inspect (e.g., 'internal/search', 'internal/cli')
intentionNoTechnical rationale, required for analytical calls selecting an active session.
session_idNoCaller selector returned by session_create. Omission means an independent caller; never inherits server environment or another caller's session.
transitiveNoIf true, return the full transitive import closure via Breadth-First Search (BFS)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.7.18
    • addedInput schema / properties / intention
      Added value: +{
+  "description": "Technical rationale, required for analytical calls selecting an active session.",
+  "type": "string"
+}
    • addedInput schema / properties / root
      Added value: +{
+  "description": "Absolute path of the checkout you are working in (your cwd or git worktree). Must be this server's repository or one of its git worktrees; the answer then comes from that checkout's own graph. A path elsewhere is refused. Alias: cwd. Omit only when the configured checkout is the one you mean.",
+  "type": "string"
+}
    • addedInput schema / properties / session_id
      Added value: +{
+  "description": "Caller selector returned by session_create. Omission means an independent caller; never inherits server environment or another caller's session.",
+  "type": "string"
+}
  2. Changed1 schema field changedv1.5.6
    • addedInput schema / properties / mermaid
      Added value: +{
+  "description": "Return Mermaid flowchart text instead of structured JSON",
+  "type": "boolean"
+}
  3. Addedv1.5.3
  4. Removedv1.5.3
  5. Changed2 schema fields changedv1.4.70
    • changedInput schema / properties / package / description
      Previous value: -"The package name or path (e.g., 'internal/auth')"New value: +"The target package path or name to inspect (e.g., 'internal/search', 'internal/cli')"
    • changedInput schema / properties / transitive / description
      Previous value: -"If true, return the full transitive import closure via BFS"New value: +"If true, return the full transitive import closure via Breadth-First Search (BFS)"
  6. First observedv1.0.0

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so 'Read-only; no side effects' just repeats machine-readable data. The description does add real context that the annotations cannot convey: the server refreshes source analysis before the call, which implies freshness and possible latency. It also states that the tool returns found:false when the package is absent, which is a useful behavioral note.

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?

It is compact and front-loaded: purpose first, then the options, then labeled WHEN TO USE, NOT TO USE, and RETURNS sections. Every sentence carries information except 'Read-only; no side effects', which repeats the annotations but is a minor redundancy.

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?

It covers six parameters with full schema coverage, and it spells out both the return shape (direct[] and transitive[] arrays, Mermaid text, found:false) and the main behavioral trait (the server refreshes analysis first). For a read-only query tool with no output schema, nothing an agent needs in order to call it correctly is missing.

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 the baseline is 3, and the description adds meaning beyond it: it gives transitive=false as the default and describes its effect (direct imports versus the BFS closure), and it links mermaid=true to flowchart output. The remaining parameters (root, session_id, intention) are fully documented in their own schema descriptions.

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 names a specific verb and resource ('List the import dependencies of a named package') and immediately distinguishes the tool from gograph_dependents, the reverse-lookup sibling. An agent can pick this one without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit WHEN TO USE case ('auditing package layering') and a NOT TO USE case that routes the agent to gograph_dependents for reverse lookup. This is exactly the when/when-not/alternative structure that makes a definition selectable.

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