Skip to main content
Glama
Sign In
gograph

gograph

by ozgurcd
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Local

gograph_source

Read-onlyIdempotent

Retrieve verbatim Go source for a specific function, method, struct, interface, type, variable, or constant without loading an entire file; returns file paths and line numbers.

Instructions

Retrieve verbatim Go source for a named function, method, struct, interface, type, variable, or constant, including complete bodies or declarations. 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. Source reads are confined to regular .go files beneath the analyzed repository and reject symlink path components. Read-only; no side effects. WHEN TO USE: When you need a specific implementation or declaration in full without loading a large file — a targeted alternative to reading the whole file. NOT TO USE: For call hierarchy information (use gograph_callers/gograph_callees); for AST metadata without the full source (use gograph_node). RETURNS: Raw Go source blocks with file paths and line numbers. Text and gograph.read.v1 structured content both carry the source or a named refusal: absent symbol, ambiguity with candidates, unsafe/unreadable source, invalid indexed range, or source exceeding 65536 bytes (with its size).

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.
symbolYesThe name of the symbol to retrieve source for (supports short name 'ValidateToken', dot-notation 'graph.Graph', or fully-qualified ID)
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. Changed1 schema field changed
    • changedInput schema / properties / symbol / description
      Previous value: -"The name of the symbol (e.g., 'ValidateToken' or 'AuthService')"New value: +"The name of the symbol to retrieve source for (supports short name 'ValidateToken', dot-notation 'graph.Graph', or fully-qualified ID)"
  3. First observedv1.0.0

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations: it discloses the freshness check performed before the call, mode-specific CHA/SSA retry behavior, that reads are confined to regular .go files beneath the analyzed repo, that symlink path components are rejected, and a concrete 65536-byte size ceiling. It also enumerates the named refusal modes, which is behavior an agent cannot infer from readOnlyHint/idempotentHint alone.

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 what the tool returns, then ushers usage guidance into labeled WHEN/NOT/RETURNS blocks, which is easy to scan. It is dense with internal detail (precise vs precise_fallback graph retry semantics) that slightly exceeds what a caller needs to select and invoke the tool.

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?

There is no output schema, and the description compensates by describing the return payload (raw source blocks with file paths and line numbers, plus gograph.read.v1 structured content) and every refusal outcome. For a read tool with a 4-parameter surface, nothing needed 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 already 100%, so baseline is 3; the description earns an extra point by explaining what the symbol parameter produces when resolution is ambiguous (a named refusal listing candidates) and by tying range/oversize failures to the read. It does not elaborate on root, intention, or session_id, leaving those entirely to the schema.

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 ('Retrieve verbatim Go source') and enumerates exactly what kinds of symbols it covers (function, method, struct, interface, type, variable, constant, with complete bodies or declarations). An agent can distinguish this from gograph_node or gograph_skeleton 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?

Provides explicit WHEN TO USE ('need a specific implementation or declaration in full without loading a large file') and NOT TO USE clauses that name the correct alternatives for each excluded case (gograph_callers/gograph_callees for hierarchy, gograph_node for AST metadata without source). Both the positive and negative routing conditions are spelled out.

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