What can you do with this server?

DocGraph is an MCP server that indexes .md, .docx, .html, and .pdf files into a knowledge graph, enabling LLM agents to search, navigate, audit, and analyze documentation. Key capabilities include: * Full-text search — FTS5-powered search with CJK + Latin support, filtered by governance status, sensitivity, research confidence, and more; optionally includes code files via the code_doc pack. * Task-oriented context building — Primary docgraph_context tool composes search results, node details, cross-references, and source content into a single result; supports summary, context_pack (reviewable evidence with citations), and drift_audit modes. * Knowledge graph traversal — Query incoming/outgoing references, compute transitive impact (blast radius), and find shortest paths between documents. * Drift audits — Detects 14+ finding types: stale/superseded/conflicting policies, unverified research evidence, stale git history, undocumented code exports, and more. * Topical similarity — Hybrid TF-IDF (50%) + shared-reference Jaccard (30%) + tag overlap (20%) scoring, optionally enhanced with neural embeddings. * Document & section details — Retrieve full metadata, structure, body, and cross-references for any document or heading. * Git history — View commit history, amendment counts, author counts, and first/last change dates per document. * Index health — Inspect file/node/edge counts, unresolved references, DB size, domain pack state, and enrichment coverage. * Tag management — List all frontmatter tags with document counts or filter documents by tag. * File browsing — List all indexed files with optional directory path filtering. * Domain packs — Extend the metadata schema for governance, research provenance, entity tracking, policy/SOP drift, assessment drift, and code documentation. * Workspace mode — Manage multiple projects in one server, fanning out queries across all stores with per-project scoping. * Agent metadata enrichment (opt-in) — Pull frontmatter-less docs, infer summaries/metadata via LLM, and push back with full provenance; never overrides authored metadata. * Neural embeddings (opt-in) — Agent-driven workflow to push externally computed vectors into DocGraph for semantic similarity beyond TF-IDF.

Which integrations are available for this server?

Supports Codex (OpenAI) as an MCP client for querying documentation knowledge graphs, performing drift audits, and managing document metadata.

DocGraph

by Detective-XH

Overview Schema Related Servers Score Discussions

Local

DocGraph is an MCP server that indexes .md, .docx, .html, and .pdf files into a knowledge graph, enabling LLM agents to search, navigate, audit, and analyze documentation. Key capabilities include:

Full-text search — FTS5-powered search with CJK + Latin support, filtered by governance status, sensitivity, research confidence, and more; optionally includes code files via the code_doc pack.
Task-oriented context building — Primary docgraph_context tool composes search results, node details, cross-references, and source content into a single result; supports summary, context_pack (reviewable evidence with citations), and drift_audit modes.
Knowledge graph traversal — Query incoming/outgoing references, compute transitive impact (blast radius), and find shortest paths between documents.
Drift audits — Detects 14+ finding types: stale/superseded/conflicting policies, unverified research evidence, stale git history, undocumented code exports, and more.
Topical similarity — Hybrid TF-IDF (50%) + shared-reference Jaccard (30%) + tag overlap (20%) scoring, optionally enhanced with neural embeddings.
Document & section details — Retrieve full metadata, structure, body, and cross-references for any document or heading.
Git history — View commit history, amendment counts, author counts, and first/last change dates per document.
Index health — Inspect file/node/edge counts, unresolved references, DB size, domain pack state, and enrichment coverage.
Tag management — List all frontmatter tags with document counts or filter documents by tag.
File browsing — List all indexed files with optional directory path filtering.
Domain packs — Extend the metadata schema for governance, research provenance, entity tracking, policy/SOP drift, assessment drift, and code documentation.
Workspace mode — Manage multiple projects in one server, fanning out queries across all stores with per-project scoping.
Agent metadata enrichment (opt-in) — Pull frontmatter-less docs, infer summaries/metadata via LLM, and push back with full provenance; never overrides authored metadata.
Neural embeddings (opt-in) — Agent-driven workflow to push externally computed vectors into DocGraph for semantic similarity beyond TF-IDF.

DocGraph

Documentation knowledge graph MCP server for LLM agents

MCP-native for LLM agents · CJK + Latin FTS5 · Multi-format graph

License: MIT Go Report Card Go 1.25+ Single binary Formats

macOS Linux Windows

Claude Code Codex Hermes Agent OpenCode

Govern your documents like code. DocGraph indexes .md, .docx, .html, and .pdf into a graph and runs drift audits on them — stale policies, conflicting research claims, superseded ADRs, undocumented code exports — so you can review your doc corpus the way you review a codebase. Most doc tools index and search. DocGraph also tells you what's broken.

Drift audit on documents

docgraph_context format=drift_audit

Surfaces 14 finding codes across the corpus. A few:

policy.stale_review — SOPs past their review_due date
policy.superseded_referenced — docs citing a replaced policy
policy.conflicting — same scope, contradicting rules
research.competing_interpretations — claims that contradict
research.unverified_evidence — assertions with no source
research.superseded_claim — research overruled by a newer claim
doc.stale_by_git — docs with no git commits in a long while
code.undocumented_export — code surfaces with no doc anchor
code.unanchored_feature — approved features with no code anchor

Three packs ship enabled (governance, research_provenance, entity); three are opt-in (policy_process, assessment_drift, code_doc). No code knowledge required for governance and research — they work on any document collection.

Opt-in agent enrichment, with provenance

Your .docx / .pdf / .html archive has no frontmatter, so it can't be governed. DocGraph fixes that without compromising authority:

agent → docgraph_enrichment(action=pending)
        ↳ scope (N docs), per-model USD estimate, sensitive paths flagged, token
user  → "go"
agent → runs LLM with its own key, then action=process for each doc
        ↳ stored as source=agent_inferred (advisory, lowest authority)
        ↳ logged with model_id, agent_id, run_id, content_hash

The confirmation token is batch-bound — one user consent authorizes the docs the user saw, no more. Sensitive paths silently refuse to issue tokens. agent_inferred metadata never overrides human frontmatter or extracted document metadata. Your governance survives the agent. DocGraph itself never calls an LLM. Enable with --enable-enrichment.

Other differentiators

CJK + Latin search that actually works — FTS5 trigram, not English-only
CodeGraph-style graph traversal for docs — docgraph_graph operation=incoming|outgoing|impact|trace
Workspace fan-out — one MCP server, N projects, one query
Reviewable evidence packs — format=context_pack returns indexed text, hashes, citations, impact (not a RAG black box)

What it isn't

A RAG black box, an embedding shop, or a Notion replacement. It's the layer that makes your existing docs auditable, navigable, and safe to feed to LLMs.

The LLM-facing fit guide — when DocGraph helps a project and when to use your own tools instead — is in AGENTS.md. Single binary, zero runtime dependencies, indexes hundreds of docs in seconds.

At a Glance

Metric	Value
Language	Go 1.25+
Binary size	~13 MB
Codebase	~23,520 lines of Go (+ ~28,390 lines of tests)
Index speed	70–700 files per project in 2–6s (full rebuild; `--force`)
Typical graph	~950 nodes and ~670 edges per 100 indexed files

Related MCP server: md-graph

Install

go install github.com/Detective-XH/docgraph@latest

Or build from source with version embedded:

git clone https://github.com/Detective-XH/DocGraph.git
cd DocGraph
go build -ldflags "-X main.version=$(git describe --tags --always)" -o docgraph .

Requires Go 1.25 or later.

go install does not support -ldflags injection, so docgraph version will output dev for binaries installed that way. Use the source build above to get a versioned binary.

CLI

docgraph init [--dry-run] [--interactive] [--install-clients auto|all|LIST] [--workspace] [--scope user] [--with-skills] [--update-skills] [path] # Create local config; optionally install MCP clients and bundled skills
docgraph install [--dry-run] [--interactive] [--clients auto|all|LIST] [--workspace] [--scope user] [--update-skills] [path]      # Configure MCP clients without re-initializing
docgraph pack list [--workspace] <path>                         # List domain packs and enabled state
docgraph pack enable [--workspace] [--no-sync] <pack-id> <path>  # Enable a domain pack; code_doc syncs by default
docgraph pack disable [--workspace] <pack-id> <path>             # Disable a domain pack; code_doc rows are removed
docgraph index [--force] [--threshold N] [--no-gitignore] [--no-history] <path>  # Index a project
docgraph sync [--threshold N] [--no-gitignore] [--no-history] <path>             # Incremental hash-based update
docgraph heal [--project <path>] [--fix] [--owner <name>] [--git-timeout <dur>]  # Infer and patch missing status/owner frontmatter fields in .md files
docgraph status <path>                       # Print index stats
docgraph serve [--threshold N] [--no-gitignore] [--no-history] [--max-watches N] [--enable-embeddings] [--enable-enrichment] --path <path>     # MCP stdio server (single project)
docgraph serve [--threshold N] [--no-gitignore] [--no-history] [--max-watches N] [--enable-embeddings] [--enable-enrichment] --workspace <dir> # MCP stdio server (auto-discover all child dirs)
docgraph version                             # Print build version

LIST is a comma-separated client list: claude,codex,hermes,opencode. auto always writes project-local Claude Code config and also writes Codex, Hermes, and OpenCode config when their config directories already exist. all creates config files for every supported client. Use --dry-run to print create/update/unchanged actions without writing files. Use --interactive to print the same review and confirm before writes.

Bundled Skills

When installing for Claude Code, DocGraph automatically installs companion skills into .claude/skills/ alongside the MCP config — no extra flag needed:

docgraph init --install-clients claude /path/to/project  # MCP config + skill
docgraph install --clients claude /path/to/project       # MCP config + skill

To install skills on a project that was already initialized without --install-clients:

docgraph init --with-skills /path/to/project

Skills are installed with skip-if-exists policy — safe to re-run. To update an existing skill to the latest bundled version:

docgraph init --update-skills /path/to/project
docgraph install --clients claude --update-skills /path/to/project

The docgraph-drift-audit skill audits all indexed .md files for DocGraph compatibility: missing frontmatter, isolated docs (no outgoing links), broken wikilinks, headings, and similarity islands. Reports PASS/FAIL per category and offers auto-fix via docgraph_files and docgraph_similar.

Available skills bundled in the binary:

Skill	Purpose
`docgraph-drift-audit`	Audit `.md` files for DocGraph compatibility
`policy-drift-audit`	Display and triage policy/process drift findings from `docgraph_context format=drift_audit`
`assessment-drift-audit`	Display and triage research assessment drift findings from `docgraph_context format=drift_audit`
`code-doc-drift-audit`	Display and triage docs-code drift findings (`code.*`) when the `code_doc` pack is enabled

MCP Tools

docgraph_graph supports operation=incoming|outgoing|impact|trace. Use document for incoming, outgoing, and impact; use from and to for trace.

Tools

#	Tool	Description
1	`docgraph_search`	FTS5 full-text search (CJK + Latin) with section-level results, field-weighted ranking, graph-aware and git-history-aware reranking, and governance/research/entity filters. Returns documentation only by default; pass `include_code=true` or `kind=code_file` to include `code_doc`-pack code files
2	`docgraph_context`	Primary entry point -- task context with related docs, structure, cross-refs, and bounded source content. Use `format=context_pack` for reviewable evidence packs; `format=drift_audit` for policy/process, research, and (when `code_doc` is enabled) docs-code drift audit reports
3	`docgraph_graph`	Graph traversal facade. `operation=incoming` (who references this doc), `operation=outgoing` (what this doc links to), `operation=impact` (blast radius, configurable depth), `operation=trace` (shortest path between two docs). Use `document=` for incoming/outgoing/impact; `from=` and `to=` for trace
4	`docgraph_node`	Single document details with metadata, structure, and edges
5	`docgraph_files`	Indexed file tree
6	`docgraph_similar`	Find topically similar documents (TF-IDF + shared refs + tags; `engine=auto/tfidf/neural`)
7	`docgraph_status`	Index health (files/nodes/edges/unresolved/DB size), per-project stats, neural embedding model totals, domain packs, metadata quality, enrichment coverage, LLM callout tool state (embeddings/enrichment enabled/disabled + required flags), and compact drift audit summary when policy/research findings exist
8	`docgraph_tags`	List all tags with doc counts, or filter documents by tag
9	`docgraph_enrichment`	Opt-in (`--enable-enrichment`). Pull or store inferred summaries and metadata for documents without frontmatter. Facade: `action=pending\|process`
10	`docgraph_embeddings`	Opt-in (`--enable-embeddings`). Neural embedding workflow facade. `action=pending` lists docs needing embeddings; `action=store` saves a vector and recomputes neural similarity; `action=clear` deletes all embeddings for a model

Start with docgraph_context for any research question. It composes search, structure, and cross-references into a single result. Use the other tools to drill into specifics.

For the agent-facing decision of whether to install/use DocGraph at all, see AGENTS.md. Once installed, tool-selection rules are in the MCP serverInstructions (injected each session) and the per-tool descriptions.

Agent Metadata Enrichment

The full mechanics of the opt-in workflow summarized at the top of this README. DocGraph never calls an LLM itself — your agent does, with its own key, then writes results back with provenance.

docgraph_enrichment(action=pending, limit, content_mode) returns frontmatter-less documents without a current inferred summary, including doc_id, content_hash, and bounded content. The response includes a CONFIRMATION_TOKEN bound to the batch of doc_ids it lists.
The agent infers a concise summary and optional metadata JSON object.
docgraph_enrichment(action=process, doc_id, content_hash, summary, metadata, confidence, model_id, provider, agent_id, confirmation_token) stores the result. model_id is required, content_hash must match the pending response, and confirmation_token must be the one returned by action=pending for a doc_id in that batch.

Inferred metadata never overrides authored frontmatter or extracted document metadata. Stored summaries appear in docgraph_node, docgraph_context, and context packs. docgraph_status reports enrichment coverage and stale results. Normal retrieval uses one current enrichment per document, while DocGraph keeps an internal run ledger with model, provider, agent, and content-hash provenance. Agent-inferred summaries and metadata are advisory context, not source of truth.

Privacy: docgraph_enrichment action=pending returns document content that your agent may send to an external provider. Get user consent before proceeding.

Semantic Similarity

DocGraph computes topic similarity between documents using three signals:

Signal	Method	Weight
Text overlap	TF-IDF cosine similarity	50%
Shared references	Jaccard similarity of outgoing link targets	30%
Tag overlap	Jaccard similarity of frontmatter tags	20%

Documents scoring above the threshold (default 0.25) are connected with similar_to edges. This finds conceptually related documents even when they don't explicitly link to each other — the key advantage over grep-based search.

Similarity is computed automatically during indexing. Query with docgraph_similar. Tune sensitivity with --threshold N on index, sync, or serve; lower values create more similar_to edges.

Neural Embeddings (agent-driven)

DocGraph never calls an LLM itself. Instead, your agent computes embeddings with any provider and pushes the vectors back — a pull-then-push agentic workflow that enables semantic search far beyond TF-IDF vocabulary matching.

docgraph_embeddings(action=pending, model_id, limit, content_mode) — returns docs without up-to-date embeddings, including content and content_hash. content_mode=full (default) reads the full section from disk; content_mode=excerpt uses the stored body excerpt. Different model_id values are partitioned separately and never compared with each other.
Your agent computes vectors with its own provider (OpenAI, Ollama, Nomic, etc.)
docgraph_embeddings(action=store, doc_id, model_id, vector, content_hash) per doc — stores the vector and recomputes neural similar_to edges. Pass content_hash exactly as returned by step 1.
docgraph_similar deduplicates TF-IDF and neural results for the same pair, preferring neural when both exist.

In workspace mode, both embedding workflows automatically locate the correct per-project store by doc_id.

Privacy: pending embedding actions return document content that your agent will send to an external provider. Get user consent before proceeding.

Use docgraph_embeddings(action=clear, model_id) to delete all vectors for a model and reclaim space. docgraph_status shows a Neural Embeddings table listing stored models, total vectors, and stale count.

Node and Edge Kinds

Nodes: document, heading, definition, tag; optional code_file nodes when the code_doc domain pack is enabled.

Edges:

Kind	Meaning
`contains`	Document contains heading/definition
`references`	`[text](path.md)` Markdown link
`wikilinks_to`	`[[target]]` wikilink
`related_to`	Frontmatter wikilink (e.g., `related_to: "[[target]]"`)
`similar_to`	Topic similarity (TF-IDF + shared refs + tags; or neural if embeddings stored)
`tagged`	Frontmatter tag association
`embeds`	`![[embed]]` transclusion
`links_external`	URL to external resource

What Gets Indexed

Markdown (.md) — up to 1 MB per file:

YAML frontmatter parsed into metadata; headings and **Term:** definition lines produce structural nodes
[[wikilinks]], [links](path.md), ![[embeds]], external URLs, and frontmatter tags produce typed edges

Word documents (.docx) — up to 10 MB per file:

Heading paragraphs (Heading 1–6 styles) become heading nodes with containment edges
Hyperlinks extracted as docx_hyperlink edges; Dublin Core metadata (core.xml) stored as key/value tuples
Zip-slip protection, per-entry size limits, 50 MB total uncompressed budget

HTML (.html, .htm) — up to 5 MB per file:

<h1>–<h6> tags (including id attributes) become heading nodes
<meta name=…> and <meta property=…> stored as metadata tuples; <a href=…> become typed link edges
<script> and <style> content excluded from body text and section chunks

PDF (.pdf) — up to 50 MB / 500 pages per file:

Each page becomes a heading node and a section chunk
Info-dict fields (Title, Author, Subject, Keywords, CreationDate) indexed as metadata tuples
Image-only PDFs detected via average chars/page and flagged with warning: image-only-pdf
Predefined CMap fonts decoded natively: Uni*-UCS2-* (UniGB/CNS/JIS/KS), 90ms-RKSJ-* (Shift-JIS), GBK-EUC-H/V (Simplified Chinese), ETen-B5-H/V (Traditional Chinese), KSCms-UHC-H/V (Korean). Pages that still cannot be decoded are flagged with warning: extraction-failed:encoding-garbage and skipped rather than indexed with replacement-character garbage

Code documentation surfaces (opt-in) — up to 1 MB per file:

Enable the code_doc domain pack to index file headers, exported doc comments, test names, and example names:
- Single project: docgraph pack enable code_doc /path/to/project
- Workspace: docgraph pack enable --workspace code_doc /path/to/workspace
- Inspect state: docgraph pack list /path/to/project
Supported languages include Go, Python, Ruby, JavaScript, TypeScript, Svelte, Vue, Rust, C, C++, Java, Swift, C#, PHP, Kotlin, Dart, Lua, Luau, Pascal, SQL, and Liquid
Adds one code_file node per source file; incremental pack enable sync completes in 1–4s for 40–80 code files, up to ~12s for 300+ code files
After enabling, docgraph_search still returns documentation only by default — opt code files in with kind=code_file or include_code=true — and format=drift_audit surfaces code.* findings
--force re-index resets domain pack state — re-run docgraph pack enable code_doc <path> after a force rebuild
This is shallow documentation indexing only; CodeGraph remains the intended tool for call graphs, type resolution, routes, and code impact

Common rules:

Respects .gitignore and .docgraphignore
Skipped directories: node_modules, .git, target, dist, build, vendor, .next, .cache, __pycache__, .codegraph, .docgraph, .obsidian, and .claude/worktrees (agent git worktrees — full repo copies that would index as duplicates). These are pruned unconditionally — --no-gitignore lifts .gitignore rules but does not re-include them. (For Obsidian vaults this means the .obsidian/ app-config dir is skipped while your notes are still fully indexed.)

Domain Packs

Domain packs extend the metadata schema for specific use cases. Three packs are enabled by default; three are opt-in.

Pack	Default	Domain	Purpose
`governance`	On	governance	Lifecycle status, ownership, sensitivity, review scheduling, audience access controls, and document supersession
`research_provenance`	On	research	Claims, evidence, source type, confidence, analyst workflow, event/assessment dates, and temporal validity
`entity`	On	entity	Entity classification, canonical naming, and alias declaration; activates the entity source graph
`code_doc`	Off	code	File headers, doc comments, test names, and example names from Go, Python, JS/TS, Rust, and 20+ more languages
`policy_process`	Off	policy_process	Policy/SOP drift detection — conflicting, stale, duplicated, superseded, and non-canonical documents
`assessment_drift`	Off	research	Assessment drift detection — stale assessments, unverified evidence, and competing research interpretations

Frontmatter Fields by Pack

Each pack reads specific keys from your Markdown frontmatter.

governance — lifecycle and access control:

status: active            # Governance lifecycle status
owner: alice              # Accountable person or role
sensitivity: internal     # Sets retrieval boundaries
allowed_audience: [engineering, legal]
review_due: 2026-12-31    # Triggers policy.stale_review when overdue
effective_date: 2026-01-01
canonical_source: true    # Marks as the authoritative copy among duplicates
approver: bob
department: Engineering
supersedes: old-policy.md
superseded_by: new-policy.md

research_provenance — evidence and provenance tracking:

claim_id: CLM-001
source_type: primary      # primary | secondary | internal
confidence: high
analyst_status: verified
assessment_date: 2026-05-01
event_date: 2026-04-15
last_verified: 2026-05-20
valid_until: 2026-11-01   # Triggers research.stale_assessment when expired
evidence: [doc/evidence-a.md, doc/evidence-b.md]
client: ACME
deliverable_id: RPT-42

entity — canonical entity declaration:

entity_type: organization   # person | organization | location | …
canonical_name: Acme Corp
aliases: [ACME, Acme Corporation]

policy_process (opt-in) — SOP and policy enrichment:

sop_category: onboarding
policy_domain: HR           # HR | Security | Finance | …
process_owner: People Ops
version: "2.1"
conflict_resolution: supersedes-v2.0

assessment_drift (opt-in) — competing research tracking:

contradicts: assessment-2026-03.md
supersedes_claim: CLM-099

Drift Audit Findings

docgraph_context format=drift_audit surfaces advisory findings from enabled packs. No code knowledge is needed — governance and research packs work on any document collection (.md, .docx, .html, .pdf).

Finding	Pack(s) required	What it detects
`policy.stale_review`	governance	`review_due` has passed
`policy.superseded_referenced`	governance	Superseded doc is still cited by others
`policy.duplicate`	governance	Near-duplicate content detected via similarity
`policy.non_canonical`	governance	No `canonical_source` marker among near-duplicates
`policy.conflicting`	governance	Similar docs with conflicting status or effective dates
`research.stale_assessment`	research_provenance	`valid_until` has expired
`research.unverified_evidence`	research_provenance	Evidence reference cannot be resolved
`research.competing_interpretations`	research_provenance + assessment_drift	Conflicting claims on the same topic
`research.superseded_claim`	research_provenance + assessment_drift	Outdated claim still cited
`research.impacted_deliverable`	research_provenance	Deliverable depends on a stale claim
`doc.stale_by_git`	none (git history)	No git commits in over N days (default 365), independent of frontmatter dates
`code.missing_symbol`	code_doc	Doc references a code symbol that no longer exists
`code.undocumented_export`	code_doc	Exported symbol has no doc comment
`code.unanchored_feature`	code_doc + governance	Feature mentioned in docs has no matching code

Managing Packs

docgraph pack list /path/to/project                                # Show all packs and enabled state
docgraph pack enable policy_process /path/to/project               # Enable an opt-in pack
docgraph pack enable assessment_drift /path/to/project
docgraph pack enable code_doc /path/to/project                     # Also triggers incremental sync
docgraph pack disable code_doc /path/to/project                    # Removes code_file rows
docgraph pack enable --workspace policy_process /path/to/workspace # Apply to all child projects

--force re-index resets all pack state — re-run docgraph pack enable <pack-id> <path> after a force rebuild.

Workspace Mode

Point DocGraph at a parent directory and it auto-discovers all immediate child directories as separate projects:

docgraph serve --workspace /path/to/workspace

Each project gets its own .docgraph/docgraph.db (add .docgraph/ to .gitignore)
Cross-project search fans out to all databases
File watcher (fsnotify, 2s debounce) monitors served projects for live re-indexing
Watch set is capped per process (--max-watches, default 8192; 0 = unlimited). Every watched directory/file is one descriptor on macOS, so an unbounded recursive watch of a very large tree can drive the OS file-descriptor table toward exhaustion (worse: one such process per connected client). The cap holds open descriptors to roughly the cap — plus the widest single watched directory, which fsnotify opens eagerly — instead of one per file in the whole tree. Beyond the cap, changes do not auto-reindex; run docgraph sync or restart. Override with the flag or DOCGRAPH_MAX_WATCHES.
No configuration file needed

File Exclusion

DocGraph respects .gitignore by default. For additional control, create a .docgraphignore file (same syntax as .gitignore):

# Project-level .docgraphignore — exclude files within a project
drafts/
archive/
*.draft.md
!archive/INDEX.md    # re-include a specific file

Workspace-level .docgraphignore (at the workspace root) excludes entire projects by directory name:

# Workspace-level .docgraphignore — exclude projects
OSINT-Platform-backup-20260518
csint-private

Editing .docgraphignore while docgraph serve is running applies the change automatically: newly-excluded files are pruned from the index on save (a guarded reconcile — an over-broad pattern that would drop more than half the corpus is refused with a message rather than emptying the index). With no server running, a newly-excluded file is dropped on the next docgraph index --force <path>. docgraph_status reports the active ignore sources (.gitignore, .docgraphignore, --no-gitignore) and how to add an exclusion.

Indexing all files

To index files that are gitignored (e.g., .claude/skills/, memory/ directories), use the --no-gitignore flag:

docgraph index --no-gitignore <path>
docgraph sync --no-gitignore <path>
docgraph serve --no-gitignore --workspace <dir>

This ignores .gitignore rules but still respects .docgraphignore.

MCP Client Integration

DocGraph works with any MCP-compatible client via stdio transport.

For automatic setup:

docgraph init --install-clients auto /path/to/project
docgraph install --clients all --workspace /path/to/workspace

The installer writes:

Client	Config target
Claude Code	`/path/to/project/.mcp.json`
Codex	`$CODEX_HOME/config.toml` or `~/.codex/config.toml`
Hermes Agent	`~/.hermes/config.yaml`
OpenCode	project `opencode.json` / `.opencode.json`, otherwise `$XDG_CONFIG_HOME/opencode/opencode.json`

Claude Code

Project-level (this project only) — add to .mcp.json in your project root, or run:

docgraph init --install-clients claude /path/to/project

Manual .mcp.json:

{
  "mcpServers": {
    "docgraph": {
      "command": "docgraph",
      "args": ["serve", "--path", "."]
    }
  }
}

User-level (global) — available across all projects. Writes to ~/.claude.json via the claude CLI:

docgraph install --clients claude --scope user --workspace /path/to/workspace

Or manually with the claude CLI:

claude mcp add --scope user docgraph -- docgraph serve --workspace /path/to/workspace

Verify the connection:

claude mcp list

Important: Claude Code stores user-scope MCP config in ~/.claude.json, not ~/.claude/mcp.json. Manually editing ~/.claude/mcp.json has no effect — use claude mcp add --scope user or the project-level .mcp.json approach instead.

PATH note: docgraph must be on your PATH. For go install builds, ensure $GOPATH/bin is in your PATH (run go env GOPATH to find the location). If not, use the absolute path to the binary.

Codex (OpenAI)

Add to your MCP configuration:

[mcp_servers.docgraph]
command = "docgraph"
args = ["serve", "--workspace", "/path/to/workspace"]

Hermes Agent

Add to ~/.hermes/config.yaml:

mcp_servers:
  docgraph:
    command: docgraph
    args:
      - serve
      - --workspace
      - /path/to/workspace

OpenCode

Add to your opencode MCP configuration:

{
  "mcpServers": {
    "docgraph": {
      "command": "docgraph",
      "args": ["serve", "--workspace", "/path/to/workspace"]
    }
  }
}

Any MCP client

DocGraph uses stdio transport. Launch with:

docgraph serve --workspace /path/to/workspace
# or single project:
docgraph serve --path /path/to/project

The server reads JSON-RPC from stdin and writes to stdout.

Architecture

scan .md / .docx / .html / .pdf  (docformat registry: extensions + per-format size limits)
  -> dispatch:
       .md          → goldmark + inlined YAML frontmatter parser
       .docx        → stdlib archive/zip + encoding/xml
       .html / .htm → golang.org/x/net HTML tokenizer
       .pdf         → Detective-XH/gopdf (ledongthuc/pdf fork; text layer + CJK CMaps; writes to temp file)
       code docs    → optional code_doc pack for comments/tests/examples
  -> extract nodes, edges, links, metadata tuples, and section chunks
  -> store in SQLite (modernc.org/sqlite, pure Go)
  -> resolve cross-document references
  -> compute topic similarity (TF-IDF + graph Jaccard)
  -> serve over MCP stdio (mark3labs/mcp-go)

FTS5 uses the trigram tokenizer for mixed CJK and Latin full-text search.

Dependencies

Dependency	Role
modernc.org/sqlite	Pure-Go SQLite driver (no CGo) with FTS5
goldmark	Markdown parser
yaml.v3	YAML frontmatter parsing
mcp-go	MCP protocol (stdio transport)
fsnotify	Cross-platform file watcher
golang.org/x/net	HTML tokenizer for `.html`/`.htm` extraction
Detective-XH/gopdf	PDF text-layer extraction (fork of ledongthuc/pdf adding CJK CMap decoders)
stdlib	`.gitignore` + `.docgraphignore` matching, `archive/zip` + `encoding/xml` for `.docx`

Supply Chain

CI verifies module checksums with go mod verify, runs govulncheck, and generates a CycloneDX JSON SBOM artifact named docgraph-sbom with cyclonedx-gomod. The SBOM is generated from go.mod during GitHub Actions runs; generated SBOM files are not checked into the repository.

CodeGraph Interoperability

DocGraph and CodeGraph are complementary. DocGraph owns documentation context, governance/research metadata, citation paths, document references, context packs, drift audits, and shallow code-documentation surfaces. CodeGraph owns source-code intelligence such as symbols, callers/callees, call traces, route handlers, and code impact.

CodeGraph interoperability currently ships as an advisory handoff layer in the MCP server instructions. DocGraph does not call CodeGraph, read .codegraph/, or import CodeGraph symbol anchors. The reserved codegraph_anchor metadata field stays empty until CodeGraph exposes a stable export/API contract.

For docs-code work, enable DocGraph's code_doc pack — it is the interface layer between DocGraph and CodeGraph. DocGraph indexes documentation surfaces (file headers, exported doc comments, test names, example names); CodeGraph indexes code structure (symbols, callers/callees, call graphs, type resolution). Together they give a complete picture: format=drift_audit with code_doc enabled can surface code.missing_symbol, code.undocumented_export, and code.unanchored_feature findings, then hand symbol-level questions to codegraph_* tools when the agent environment exposes them.

Inspired By

DocGraph is inspired by CodeGraph, which builds a knowledge graph from source code symbols using tree-sitter and SQLite. DocGraph adopts the same core design:

Schema: nodes + edges + files + unresolved_refs + FTS5 + section_chunks + section_chunks_fts + document_metadata + governance_metadata + research_metadata + domain_packs + domain_pack_fields + entities + entity_mentions — the graph model extended with section snapshots, section-level search, normalized governance metadata, research provenance, domain schema pack registration, and entity/source graph primitives. Schema is bootstrapped via idempotent CREATE TABLE/INDEX/TRIGGER IF NOT EXISTS on every open; if the shape needs to change, delete .docgraph/ and reindex.
Pipeline: scan → parse → store → resolve — the same four-phase indexing pipeline, with goldmark replacing tree-sitter for AST extraction.
Two-phase resolution: raw links are extracted during parsing, then resolved in a separate pass after all files are indexed — identical to CodeGraph's UnresolvedReference → ReferenceResolver pattern.
MCP tool surface: 8 default tools with CodeGraph-compatible naming for context, search, node, similar, files, status, tags, plus graph traversal (docgraph_graph); 2 additional LLM-callout tools (docgraph_embeddings, docgraph_enrichment) register only when their --enable-* flags are set. Graph traversal, embeddings, and enrichment are facade tools that group fine-grained operations behind a single dispatch parameter, keeping agent-facing instructions compact.

Where they diverge: DocGraph is written in Go (single binary, no Node.js runtime), uses the trigram tokenizer for CJK support, and adds workspace mode for multi-project fan-out queries — features that reflect documentation use cases rather than code navigation. DocGraph also adds hybrid topic similarity (TF-IDF + graph Jaccard + tags) to discover conceptual relationships that neither explicit links nor code structure can capture.

Release v0.3.4 — SHA-256 Checksums

Signed by EDB0808F3F248B66F53837B4888293C4BA30EEF6 (Xavier).

docgraph-darwin-arm64.tar.gz

c4dc880d8ed6796f28718c76c99e410c110366fd6c47bd991b518b023b5c28c3

docgraph-darwin-amd64.tar.gz

31dbfa7f8d6748f7147863f1f0b9549f82ca83f0e9847bc45002520c7039a1e6

docgraph-linux-amd64.tar.gz

a8ae2cf4843b47316853ee5177c89599c9893eb6d256731db432ec4565846f71

docgraph-linux-arm64.tar.gz

a9223d01473554063b0bbb584b1e7c205271c6340db3d2826a50fdefff52c3cc

docgraph-windows-amd64.zip

b1cacd26d9d69cc7169f7a6fe73cce565868d7be6131cc1a925a16545ad1a88a

Verify:

gpg --verify SHA256SUMS.asc SHA256SUMS
shasum -a 256 -c SHA256SUMS

License

MIT

Available Tools

10 tools

docgraph_contextA

Destructive

PRIMARY TOOL. Build relevant documentation context for a task or topic. Composes governance-aware search + node details + cross-references + bounded source content in one call. For a single known document, use docgraph_node instead. For broad queries, set includeContent=false or reduce maxContentBytes (default 2000, hard cap 6000) to avoid large responses; a 10-node query with default settings can produce 20–50 KB of output.

ParametersJSON Schema

Name	Required	Description
`task`	Yes	Description of the task/topic to find context for
`format`	No	Output format: summary (default), context_pack for a reviewable evidence pack, or drift_audit for a drift audit report (finding codes: policy.stale_review, policy.superseded_referenced, policy.duplicate, policy.non_canonical, policy.conflicting, research.stale_assessment, research.unverified_evidence, research.competing_interpretations, research.superseded_claim, research.impacted_deliverable; doc.stale_by_git when git history is present; when code_doc is enabled: code.missing_symbol, code.undocumented_export, code.unanchored_feature).
`status`	No	Filter by governance status.
`project`	No	Workspace mode only: scope results to a single project by name (the directory name shown in docgraph_status). Omit to query all projects. No-op in single-store mode.
`claim_id`	No	Filter by research claim_id.
`maxNodes`	No	Max documents to return (default 10)
`as_of_date`	No	Evaluate effective_date and valid_until against YYYY-MM-DD.
`confidence`	No	Filter by research confidence.
`impactDepth`	No	Context pack impact depth for incoming references (default 1, max 3).
`sensitivity`	No	Filter by sensitivity.
`source_type`	No	Filter by research source_type.
`analyst_status`	No	Filter by research analyst_status.
`includeContent`	No	Include bounded source content for each result (default true)
`referenceLimit`	No	Context pack max incoming/outgoing references per item (default 5, max 20).
`maxContentBytes`	No	Max source bytes per result (default 2000, hard cap 6000)
`allowed_audience`	No	Filter to documents available to an audience label. Public documents are included.
`canonical_source`	No	Filter by canonical source marker or value.

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already indicate destructiveHint=true and openWorldHint=true. The description adds behavioral context by warning about potential large responses and suggesting parameter adjustments (includeContent, maxContentBytes) to manage output size. It does not contradict annotations.

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?

The description is concise with two sentences. The first sentence clearly states the primary purpose. The second sentence provides essential usage guidance and a warning about response sizes. No redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (17 parameters, no output schema), the description provides a high-level overview but lacks detail on governance-awareness, cross-references, and output formats (covered in the schema but not reiterated). Some gaps remain for fully informing the agent.

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 coverage is 100%, so all parameters have descriptions. The tool description adds limited new parameter information beyond the schema, only implicitly referencing includeContent and maxContentBytes in the size warning. Baseline is 3 for high schema coverage.

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 explicitly states 'PRIMARY TOOL. Build relevant documentation context for a task or topic.' It uses a specific verb ('build') and resource ('documentation context'), and distinguishes itself from the sibling tool docgraph_node by advising to use that for a single known document.

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

Usage Guidelines4/5

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

The description gives clear guidance on when to use an alternative ('For a single known document, use docgraph_node instead') and provides advice on configuring parameters to avoid large responses. However, it does not explicitly exclude other sibling tools or mention when not to use this tool beyond that specific case.

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

docgraph_exploreA

Destructive

Survey several related documents and their cross-references in one call. More efficient than multiple docgraph_node calls. For a single known document, use docgraph_node instead. For governance filters or structured context, use docgraph_context instead.

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Search terms to find related documents
`maxDocs`	No	Max documents (default 5)
`project`	No	Workspace mode only: scope results to a single project by name (the directory name shown in docgraph_status). Omit to query all projects. No-op in single-store mode.

TDQS

A3.7/5.0

Behavior1/5

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

The description uses 'survey' implying a read-only operation, but annotations set destructiveHint=true, indicating destructive behavior. This is a direct contradiction.

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?

Three sentences that are front-loaded with purpose, then efficiency, then guidelines. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While purpose and guidelines are clear, the description lacks context about the destructive behavior and does not hint at the response format (no output schema).

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 baseline is 3. The description does not add additional meaning beyond the schema's parameter 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 clearly states the tool surveys several related documents and cross-references, and distinguishes it from siblings docgraph_node and docgraph_context.

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?

Explicitly says when to use (multiple documents) and when not to (single doc: use docgraph_node; governance/context: use docgraph_context).

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

docgraph_filesB

Destructive

List all indexed files (.md, .docx, .html, .pdf). Use path filter to narrow scope (bare directory name, e.g. path=docs). For a single known doc, use docgraph_node instead.

ParametersJSON Schema

Name	Required	Description
`path`	No	Filter to directory subtree (bare directory name, e.g. docs or reports/2024)
`limit`	No	Max files to return (default 50)
`project`	No	Workspace mode only: scope results to a single project by name (the directory name shown in docgraph_status). Omit to query all projects. No-op in single-store mode.

TDQS

B3.4/5.0

Behavior1/5

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

The description states 'List all indexed files' implying a read-only operation, but annotations declare destructiveHint: true. This creates a direct contradiction about whether the tool modifies state. The description does not resolve this or add any other behavioral traits beyond the conflicting annotation. Hence, it fails to provide accurate transparency.

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?

The description is two sentences, front-loaded with the core purpose ('List all indexed files'), followed by usage advice and alternative suggestions. Every sentence adds value with no redundancy or fluff. Highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 3 optional parameters and no output schema, the description covers usage context well but omits details about the output format, pagination, or default behavior for omitted parameters. The contradiction with annotations further undermines completeness. Score is average given these gaps.

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?

The input schema already describes all three parameters with 100% coverage. The description adds practical context: for 'path' it clarifies 'bare directory name' and gives an example; for 'project' it explains workspace mode behavior and no-op in single-store mode. This goes beyond the schema's descriptions, earning a 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists all indexed files with specific extensions (.md, .docx, .html, .pdf). It also mentions filtering by path, which adds specificity. However, it does not differentiate from many siblings like docgraph_context or docgraph_graph, relying on a single sibling comparison (docgraph_node). This prevents a top score.

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

Usage Guidelines4/5

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

The description explicitly advises using the path filter to narrow scope and directs users to docgraph_node for a single known document. This provides clear guidance for a common use case. However, no guidance is given for other scenarios or when to avoid this tool entirely, which would be needed for a 5.

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

docgraph_graphA

Destructive

Document graph traversal facade. Operations: incoming — documents that cite/reference this document outgoing — documents this document links to impact — transitive incoming references (who depends on this) trace — shortest forward path from document A to document B over reference edges (markdown links, wikilinks, embeds); one-directional, ignores similarity/tag edges; "no path" ≠ "unrelated"

ParametersJSON Schema

Name	Required	Description
`to`	No	Target document name or path for trace
`from`	No	Starting document name or path for trace
`depth`	No	Impact depth (default 2, max 5)
`limit`	No	Max incoming/outgoing results (default 10)
`document`	No	Document name or path for incoming, outgoing, and impact. When copying a path from docgraph_search results, strip the trailing '#heading:line' suffix (and any '[project/]' prefix in workspace mode) to the bare file path before passing it here.
`operation`	Yes	Graph operation: incoming, outgoing, impact, or trace

TDQS

A3.6/5.0

Behavior3/5

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

The description adds useful nuance for the trace operation (one-directional, ignores similarity/tag edges, 'no path' ≠ 'unrelated'), but fails to address the destructiveHint=true annotation, which implies side effects not mentioned. Annotations provide readonly/destructive flags, but the description does not clarify the destructive nature.

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?

The description is a single, front-loaded paragraph with a clear bullet-like list. Every sentence serves a purpose, no redundancy, and it efficiently conveys the core functionality.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 6 parameters and no output schema, the description does not mention what the tool returns (documents, paths, counts?), nor does it explain the destructive side effects indicated by annotations. Critical information about output format and behavioral implications is missing.

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 coverage is 100% with parameter descriptions already present. The tool description does not add new information beyond what the schema provides; it merely restates the operation context. Baseline 3 applies due to high schema coverage.

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 the tool is a document graph traversal facade and lists four specific operations (incoming, outgoing, impact, trace) with concise explanations, distinguishing it from sibling tools like docgraph_search or docgraph_similar.

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

Usage Guidelines3/5

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

Each operation is described with when to use it (e.g., 'incoming — documents that cite/reference this document'), but there is no explicit guidance on when not to use this tool or alternatives among the many sibling tools. The context is implied rather than explicit.

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

docgraph_historyA

Destructive

Show git commit history for a document: how many times it was amended, by how many authors, first/last change dates, and the most recent commit message. Returns empty for files not tracked by git (gitignored or untracked).

ParametersJSON Schema

Name	Required	Description	Default
`document`	Yes	Document name or path

TDQS

A3.6/5.0

Behavior1/5

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

The description contradicts the annotations: it states a read-only 'show' operation, but annotations have destructiveHint: true and readOnlyHint: false. This is a clear contradiction, forcing the score to 1 per rules.

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?

The description is a single, efficient sentence that front-loads the purpose and includes key details. Every part is necessary and well-structured.

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 simple tool with one parameter and no output schema, the description covers what is returned (commits count, authors, dates, message) and edge cases (empty for untracked). It is mostly complete, though lacks info on output format or ordering.

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?

The single parameter 'document' is described in the input schema with 'Document name or path', achieving 100% schema coverage. The description adds no further semantic detail about the parameter, meeting the baseline but not exceeding it.

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 the tool shows git commit history for a document, listing specific details like number of amendments, authors, dates, and last commit message. This distinguishes it from sibling tools like docgraph_status or docgraph_context, which handle other aspects.

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

Usage Guidelines4/5

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

The description provides clear context for when to use the tool (to see history) and includes a condition for empty results (files not tracked by git). However, it does not explicitly mention when not to use it or suggest alternative tools, which could be helpful given the sibling list.

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

docgraph_nodeA

Destructive

Get a single document or heading's full details: metadata, structure, and cross-references. Use 'section' to read the full content of a specific heading section from the source file. For multiple documents, use docgraph_explore instead.

ParametersJSON Schema

Name	Required	Description
`section`	No	Return full content of a specific heading section. Accepts the exact heading text OR the anchor slug shown in search results (e.g. 'Neural Embeddings (agent-driven)' or 'neural-embeddings-agent-driven').
`document`	Yes	Document name, path, or heading qualified name (e.g. 'docs/guide.md' or 'guide.md#Installation') When copying a path from docgraph_search results, strip the trailing '#heading:line' suffix (and any '[project/]' prefix in workspace mode) to the bare file path before passing it here.
`includeBody`	No	Include body excerpt (default true)

TDQS

A3.8/5.0

Behavior1/5

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

Description says 'Get' (read-only) but annotations have destructiveHint: true, indicating mutation. This is a severe contradiction; no side effects or behavioral traits disclosed.

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?

Two sentences, no wasted words, front-loaded with purpose and usage guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite strong parameter details, missing behavioral context (destructive nature due to annotation contradiction) and no output schema described, leaving significant gap for an agent.

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 covers 100% of parameter descriptions. Description adds value with examples for 'section' (heading text or anchor slug) and cleaning instructions for 'document' (strip suffixes).

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?

Description clearly states verb 'Get' and resource 'single document or heading's full details', and distinguishes from sibling docgraph_explore for multiple documents.

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?

Explicitly says when to use (single doc/heading) and when not (multiple docs: use docgraph_explore), and explains the 'section' parameter for full content.

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

docgraph_searchA

Destructive

Full-text search across all indexed Markdown documents. Returns matching documents and headings with snippets. For topic-level context, prefer docgraph_context which combines search with structure. Use governance and research filters to constrain retrieval without adding separate tools. Result paths carry a '#heading:line' suffix and (in workspace mode) a '[project/]' prefix — strip these to the bare file path before passing a path to docgraph_node / docgraph_graph / docgraph_context (a heading result also prints its bare 'parent document:' path for this).

ParametersJSON Schema

Name	Required	Description
`kind`	No	Filter by node kind: document, heading, definition, tag. Code files (code_doc pack) are excluded by default; pass kind=code_file or include_code=true to surface them.
`limit`	No	Max results (default 10)
`query`	Yes	Search terms
`status`	No	Filter by governance status (e.g. approved, draft, superseded). Requires metadata reindex.
`project`	No	Workspace mode only: scope results to a single project by name (the directory name shown in docgraph_status). Omit to query all projects. No-op in single-store mode.
`claim_id`	No	Filter by research claim_id. Requires metadata reindex.
`entity_id`	No	Filter to documents that mention a specific entity UUID.
`as_of_date`	No	Evaluate effective_date and valid_until against YYYY-MM-DD.
`confidence`	No	Filter by research confidence (e.g. high, medium, low). Requires metadata reindex.
`entity_type`	No	Filter to documents that mention entities of this type (e.g. person, organization).
`sensitivity`	No	Filter by sensitivity (e.g. public, internal, confidential, restricted). Requires metadata reindex.
`source_type`	No	Filter by research source_type (e.g. primary, secondary, internal). Requires metadata reindex.
`include_code`	No	Include code_file results from the code_doc pack alongside documentation. Default false (docs only).
`analyst_status`	No	Filter by research analyst_status. Requires metadata reindex.
`allowed_audience`	No	Filter to documents available to an audience label. Public documents are included.
`canonical_source`	No	Filter by canonical source marker or value. Requires metadata reindex.

TDQS

A4.1/5.0

Behavior2/5

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

Annotations indicate destructiveHint=true and idempotentHint=false, which are unusual for a search tool, but the description does not address these traits. The description focuses on result path handling but omits behavioral side effects.

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?

Description is a single paragraph that front-loads the core purpose and provides essential details in a compact form. A bit dense but no wasted sentences.

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?

Given 16 parameters and no output schema, the description covers search function, sibling differentiation, filters, and result handling. Lacks explanation of destructive behavior, but otherwise adequate for the complexity.

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%, but description adds value by explaining filter usage and result path format (suffix stripping, parent document path). This helps agents use parameters correctly beyond 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?

Clearly states it performs full-text search across indexed Markdown documents and returns matching documents with headings and snippets. Differentiates from sibling docgraph_context by specifying it combines search with structure.

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?

Explicitly advises when to use this tool vs docgraph_context, and instructs to use governance and research filters. Also provides specific guidance on stripping path suffixes for downstream tools.

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

docgraph_similarA

Destructive

Find documents topically similar to a given document using TF-IDF term overlap + shared references + tag overlap (engine=auto/tfidf — the default, always on, no flags). Returns 0 results for a topically unique document (a broad README or changelog commonly has no similar_to edges even when the index is fully built and the engine is working): 0 does NOT mean the engine is off, embeddings are disabled, or the index is broken. Neural similarity is an OPTIONAL add-on layered on top — only if embeddings were stored via docgraph_embeddings action=store (engine=neural) are neural scores added; embeddings being disabled never causes a TF-IDF 0-result. For explicit link tracking use docgraph_graph. Accepts document paths only — heading anchors (doc.md#heading) return empty. The score is a 0-to-1 weighted blend (TF-IDF cosine 50% + shared-reference Jaccard 30% + tag Jaccard 20%); it is NOT a percentage. Each result shows the three signal components that drove its score. No per-vocabulary-term breakdown is available — the engine does not retain individual term contributions, so you cannot identify which specific terms, phrases, or mentions made a score high OR low; any per-term explanation of the TF-IDF component is fabricated. Scores are corpus-relative; 0.4-0.5 can mean near-identical in a corpus with high shared vocabulary.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max results (default 10)
`engine`	No	Similarity engine: auto (default), tfidf, or neural. neural requires --enable-embeddings; returns an error if the server was not started with that flag. To check whether neural is available BEFORE querying, call docgraph_status and inspect the docgraph_embeddings field.
`project`	No	Workspace mode only: scope results to a single project by name (the directory name shown in docgraph_status). Omit to query all projects. No-op in single-store mode.
`document`	Yes	Document name or path (document paths only; heading anchors return empty)

TDQS

A4.4/5.0

Behavior3/5

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

The description is very transparent about limitations (no per-term breakdown, scores are corpus-relative, 0 results meaning). However, annotations indicate destructiveHint=true, implying the tool might modify state, but the description suggests a purely read-only operation (find similar documents). This contradiction reduces the score.

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?

Description is long but efficiently packed with necessary details. Front-loaded with main purpose, then edge cases and caveats. Minor redundancy (e.g., repeated '0 does NOT mean'), but every sentence earns its place.

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?

Given the complexity (multiple engines, scoring formula, edge cases like 0 results), the description is thorough. Explains weighted blend, what results contain, and limitations. No output schema, but the description covers return format sufficiently.

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% with descriptions, but the description adds significant value: explains engine defaults (auto/tfidf always on, no flags), document path restrictions, limit default, and project scope behavior. Exceeds baseline.

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?

Clearly states it finds topically similar documents using TF-IDF, shared references, and tag overlap. Distinguishes from sibling tools like docgraph_graph for explicit link tracking and mentions docgraph_embeddings for neural similarity. Specific verb and resource, no ambiguity.

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?

Explicitly tells when to use alternatives (e.g., docgraph_graph for explicit link tracking). Warns that heading anchors return empty, explains 0 results do not indicate engine failure, and advises checking docgraph_status for neural availability. Comprehensive guidance.

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

docgraph_statusA

Destructive

Index health: file count, node count, edge count, unresolved references, DB size. Use to verify the index is ready before other operations, or to inspect embedding model state, LLM callout tool state (docgraph_embeddings/docgraph_enrichment enabled/disabled + required flags), domain packs, and drift findings. Metadata quality scores (0–100) reflect frontmatter completeness; deductions for missing status, owner, or review_due are the most common and do not affect content reliability.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior1/5

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

Annotations declare destructiveHint=true, but the description describes a read-only health check with no mention of destructive actions. This is a clear contradiction, severely undermining transparency.

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?

Two well-structured sentences that front-load the primary purpose and add secondary use cases without 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?

Given no parameters, no output schema, and a rich set of sibling tools, the description covers the tool's output, usage scenarios, and important clarifications (e.g., metadata score deductions) completely.

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?

With zero parameters and 100% schema coverage, the description adds significant meaning by enumerating the health metrics and metadata quality scores returned, which the schema cannot convey.

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 reports index health metrics (file count, node count, edge count, etc.) and additional state details, which is specific and distinguishes it from sibling tools like docgraph_context or docgraph_graph.

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

Usage Guidelines4/5

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

Explicit guidance is given: 'Use to verify the index is ready before other operations, or to inspect embedding model state, LLM callout tool state... domain packs, and drift findings.' It provides clear context but does not mention when not to use or alternatives.

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

docgraph_tagsB

Destructive

List all tags across indexed documents with document counts, or find all documents with a specific tag.

ParametersJSON Schema

Name	Required	Description	Default
`tag`	No	Tag name to filter by. If omitted, lists all tags with counts.
`project`	No	Workspace mode only: scope results to a single project by name (the directory name shown in docgraph_status). Omit to query all projects. No-op in single-store mode.

TDQS

B3.2/5.0

Behavior1/5

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

The description describes read-only operations (list, find), yet the annotations set destructiveHint=true, indicating potential mutation. This contradiction is not addressed in the description, and no additional behavioral context is provided to explain the discrepancy.

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?

Single sentence efficiently captures both behaviors. No extraneous words, and the primary action (listing) is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description mentions document counts but does not specify the output format or address the destructive hypothesis from annotations. Given the lack of an output schema and the presence of a contradictory annotation, contextual completeness is insufficient for safe and correct tool invocation.

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?

With 100% schema description coverage, the description does not add meaningful guidance beyond what the schema already provides. The description restates the schema's filtering behavior without further detail.

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 the tool's function: listing all tags with counts or finding documents by a specific tag. It uses specific verb-resource phrasing and distinguishes itself from sibling tools like docgraph_search or docgraph_status.

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

Usage Guidelines3/5

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

The description implies when to use (when tag information is needed) but does not provide explicit guidance on when not to use or how it differs from alternatives. The sibling tools are not referenced for comparison, leaving the agent to infer distinctions.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

10 tool updatesv0.1.0Jun 3, 2026
- First observeddocgraph_context
- First observeddocgraph_explore
- First observeddocgraph_files
- First observeddocgraph_graph
- First observeddocgraph_history
- First observeddocgraph_node
- First observeddocgraph_search
- First observeddocgraph_similar
- First observeddocgraph_status
- First observeddocgraph_tags

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0

Disambiguation5/5

Each tool has a uniquely defined purpose: context building, exploration, file listing, graph traversal, history, node retrieval, search, similarity, status, and tags. No two tools overlap in functionality, making their distinctions clear.

Naming Consistency5/5

All tools follow the 'docgraph_<noun>' pattern consistently, where the noun succinctly describes the operation (e.g., docgraph_context, docgraph_search). This uniform naming scheme makes the tool set predictable and easy to navigate.

Tool Count5/5

With 10 tools, the server covers a comprehensive set of documentation graph operations without being overwhelming. Each tool serves a distinct and necessary function, fitting the domain well.

Completeness5/5

The tool surface covers the full lifecycle of documentation graph interaction: indexing, searching, navigation, similarity, history, and status. All common query and exploration needs are addressed, with no obvious gaps for the stated purpose.

Maintenance

ActivityStale

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Mirror Memory MCP Server
io.github.Tr1ckyMag1ca1
Personal knowledge base MCP server with semantic search, auto-categorization, metadata extraction
Knowledge & Memory Search Note Taking
2
Mdkit A
online.mdkit
Document-to-Markdown MCP server — convert PDF, Office and HTML into LLM-ready Markdown.
Developer Tools RAG Systems Data Platforms
31
forkast-mcp-docs A
io.github.ForkastPredict
MCP server for querying Forkast documentation
Documentation Access Search Developer Tools
42
DocsMint
io.github.HiAi-gg
Self-hosted AI-native knowledge workspace with hybrid search, GraphRAG, and MCP.
Documentation Access RAG Systems Knowledge & Memory
171

Related MCP Servers

Atlas
Documentation Access Search RAG Systems
moxellabs
A
license
Not graded
quality
A
maintenance
Local-first MCP server for querying multi-repo engineering documentation artifacts from a SQLite corpus.
Updated 13 days ago (2026-08-25 01:07 UTC)
10
AGPL 3.0
md-graph
Knowledge & Memory Search File Systems
LZMW
F
license
Not graded
quality
C
maintenance
MCP server that enables full-text search and link navigation over Markdown files as a knowledge graph.
Updated 3 months ago (2026-06-04 05:51 UTC)
-
Lexomni MCP
Search Note Taking Documentation Access
PagansDev
A
license
A
quality
C
maintenance
MCP server for local knowledge management with Markdown and PDF indexing using SQLite FTS5.
Updated 7 months ago (2026-02-17 20:28 UTC)
5
12
2
MIT
DocGraph
Documentation Access Knowledge & Memory Search
carrilloapps
A
license
B
quality
A
maintenance
Universal documentation knowledge-graph MCP server with hybrid full-text + vector search. Indexes local files and remote sources from Notion, Jira, Obsidian, Linear, GitHub, and Confluence into a single SQLite knowledge graph, exposing it to AI agents via the Model Context Protocol.
Updated 2 months ago (2026-07-04 19:05 UTC)
10
21
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/Detective-XH/DocGraph'

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