Skip to main content
Glama
Sign In
gograph

gograph

by ozgurcd
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Local

gograph_node

Read-onlyIdempotent

Fetch AST metadata for a Go symbol, package, or file—kind, path, line, signature, doc comment, and struct fields—to inspect structure without reading the full source body.

Instructions

Fetch AST metadata for a named symbol, package, or file: kind, file path, line number, full signature, doc comment, and struct fields if applicable. The MCP server checks freshness before this call and refreshes in the current requested analysis mode; precise and precise_fallback graphs retry CHA/SSA after source changes. Read-only; no side effects. WHEN TO USE: When you need structural metadata (kind, signature, line number) without the full source body — lighter than gograph_source for metadata-only lookups. NOT TO USE: For full source code (use gograph_source); for call relationships (use gograph_callers/gograph_callees). RETURNS: Node properties array with kind, file, line, and signature; empty when the name is not found.

Input Schema

NameRequiredDescriptionDefault
nameYesThe exact symbol, package path, or Go file name to inspect (e.g., 'Graph', 'internal/search', 'server.go')
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.
limitNoMaximum rows per page; the byte budget may return fewer.
cursorNoOpaque next_cursor for the same graph snapshot and result selection.
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.

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. Changed2 schema fields changedv1.7.5
    • addedInput schema / properties / cursor
      Added value: +{
+  "description": "Opaque next_cursor for the same graph snapshot and result selection.",
+  "maxLength": 128,
+  "type": "string"
+}
    • addedInput schema / properties / limit
      Added value: +{
+  "default": 100,
+  "description": "Maximum rows per page; the byte budget may return fewer.",
+  "maximum": 200,
+  "minimum": 1,
+  "type": "integer"
+}
  3. Addedv1.5.3
  4. Removedv1.5.3
  5. Changed1 schema field changedv1.4.70
    • changedInput schema / properties / name / description
      Previous value: -"The symbol, package, or file name to look up"New value: +"The exact symbol, package path, or Go file name to inspect (e.g., 'Graph', 'internal/search', 'server.go')"
  6. First observedv1.0.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered structurally. The description adds genuinely non-obvious behavior: the server checks freshness and refreshes in the requested analysis mode, and precise/precise_fallback graphs retry CHA/SSA after source changes, plus an empty result when the name is not found. These are real operational traits beyond the annotations, though the CHA/SSA retry sentence is terse enough to be somewhat opaque.

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?

Front-loads the core purpose, then uses clear labeled sections (WHEN TO USE / NOT TO USE / RETURNS), which is easy for an agent to parse. Slightly verbose in the freshness/CHA-SSA sentence, but nothing is truly wasted.

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?

For a read tool with a rich schema and no output schema, the description covers purpose, alternatives, behavioral caveats, and return shape, which is close to complete. It does not mention pagination behavior or next_cursor despite the schema exposing limit/cursor, a minor gap for an agent handling multi-page 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%, so all six parameters — including root scoping, limit/cursor paging, intention, and session_id — are already documented in the schema. The description adds no parameter-level detail beyond the schema, so the baseline of 3 applies.

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?

States a specific verb and resource ("Fetch AST metadata for a named symbol, package, or file") and enumerates the returned fields: kind, file path, line number, signature, doc comment, struct fields. It explicitly positions itself relative to siblings ("lighter than gograph_source for metadata-only lookups"), so an agent can discriminate it without opening another 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?

Contains explicit WHEN TO USE and NOT TO USE sections with named alternatives: gograph_source for full source, gograph_callers/gograph_callees for call relationships. The selection condition (metadata-only vs. source body) is spelled out rather than implied.

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