Skip to main content
Glama

gograph_doc

Read-onlyIdempotent

Fetch Go documentation for stdlib or third-party symbols directly with go doc, without requiring a graph build. Get signatures and doc comments to understand call chains.

Instructions

Fetch the Go documentation (signature + doc comment) for any package, stdlib symbol, or third-party symbol by running go doc <query>. No graph build required — works without .gograph/graph.json. WHEN TO USE: When following a call chain into stdlib (fmt, net/http, io) or a third-party dependency (pgx, gin, zap) and you need the signature or method listing without reading source files. NOT TO USE: For project-internal symbols (use gograph_source or gograph_context instead — they return callers/callees too). RETURNS: The raw go doc output text including package declaration, function/type/method signature, and full doc comment; error message when the symbol is not found or go is not on PATH.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesThe go doc query string. Examples: 'fmt.Errorf', 'net/http.HandleFunc', 'io.Reader', 'github.com/jackc/pgx/v5.Conn.QueryRow'
Behavior5/5

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

Annotations already indicate read-only, non-destructive, idempotent. Description adds return format (raw go doc output), error conditions (symbol not found, go not on PATH), and no graph build needed. No contradictions.

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?

Well-structured with sections, front-loaded purpose, and no wasted words. Four sentences cover all needed info.

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?

Despite no output schema, description explains return format and error cases. Input schema is simple. Complete context for agent invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Parameter 'query' has 100% schema coverage with description, and description provides concrete examples (fmt.Errorf, net/http.HandleFunc, etc.) that add significant meaning.

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 clearly states it fetches Go documentation for packages/symbols using `go doc <query>`. It differentiates from siblings by noting no graph build required and explicitly contrasts with project-internal tools.

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 (following call chains into stdlib/third-party) and NOT TO USE (project-internal symbols, with alternatives like gograph_source/gograph_context).

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ozgurcd/gograph'

If you have feedback or need assistance with the MCP directory API, please join our Discord server