Skip to main content
Glama
Sign In
gograph

gograph

by ozgurcd
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Local

gograph_wiki

DestructiveIdempotent

Generate a token-efficient llm-wiki of machine-first Markdown pages from a Go repository graph, giving agents an orientation to architecture, hotspots, routes, packages, and more in one call.

Instructions

Generate the llm-wiki/ directory of machine-first markdown pages from the static graph. Pages produced: overview.md, architecture.md, hotspots.md, routes.md, env.md, errors.md, concurrency.md, api-surface.md, and one packages/.md per internal package. 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. A relative output is anchored beneath the graph root and rejects linked components; an absolute output explicitly selects a local destination whose final directory must be real. Generated page paths and regular-file writes remain confined beneath the selected output root. Writes may overwrite existing regular files; MCP annotations mark it mutating and destructive. WHEN TO USE: At the start of an agent session on an unfamiliar codebase — run once to get a token-efficient orientation without issuing dozens of individual tool calls. NOT TO USE: For targeted symbol lookups (use gograph_context or gograph_source). RETURNS: JSON manifest of written page filenames and a count; error when the graph cannot be loaded or the output directory is unsafe or cannot be created.

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.
outputNoWiki directory: relative paths are graph-rooted; an absolute path explicitly selects a real local output root (default 'llm-wiki')
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 changedv1.5.6
    • changedInput schema / properties / output / description
      Previous value: -"Output directory for wiki pages (default: 'llm-wiki')"New value: +"Wiki directory: relative paths are graph-rooted; an absolute path explicitly selects a real local output root (default 'llm-wiki')"
  3. Addedv1.4.78

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds real context: freshness checks with automatic refresh, CHA/SSA retry on source changes in precise modes, confinement of writes beneath the chosen output root, and that existing regular files may be overwritten. It stops short of describing pagination or output volume, but for a destructive write tool this is substantially more than the annotations carry.

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?

It is long, but the structure is front-loaded and scannable: artifact list first, then safety/semantics, then WHEN TO USE / NOT TO USE / RETURNS. Some sentences (the freshness/retry passage) are dense and slightly redundant with the schema, but each block carries decision-relevant information.

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?

With no output schema, the description correctly supplies a RETURNS section ('JSON manifest of written page filenames and a count') plus the failure modes (graph cannot be loaded, unsafe or uncreatable output directory). Combined with the overwrite and path-confinement rules, an agent has everything needed to call this 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 the baseline is 3; however the description adds genuinely new meaning beyond the schema for the output parameter — that relative paths are graph-rooted while rejecting linked components, and that an absolute path must resolve to a real directory. It also ties root to 'this server's repository or a git worktree', clarifying the refusal behavior.

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 first sentence gives a specific verb and resource ('Generate the llm-wiki/ directory of machine-first markdown pages from the static graph') and then enumerates the exact artifacts (overview.md, architecture.md, hotspots.md, packages/<name>.md). This makes it immediately distinguishable from the symbol-lookup siblings it names.

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?

Explicit WHEN TO USE ('at the start of an agent session on an unfamiliar codebase — run once') and NOT TO USE ('for targeted symbol lookups, use gograph_context or gograph_source') sections route the agent to alternatives with the selecting condition stated.

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