Which integrations are available for this server?

Allows to index pages from Confluence (Cloud and Data Center) with full body content using REST v2 and CQL filters. Allows to index GitHub issues and pull requests with optional state filters. Allows to index issues from Jira Cloud using JQL filters, rendering ADF body to Markdown. Allows to index issues from Linear with team and state filters via GraphQL. Allows to index documents from Notion databases and workspace search, rendering blocks to Markdown. Allows to index documents from an Obsidian vault, parsing front-matter, tags, and wikilinks. Allows to index API documentation from Postman collections and OpenAPI specifications.

How do I use DocGraph?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@DocGraph find all documents mentioning hybrid search" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

DocGraph

by carrilloapps

Overview Schema Related Servers Score Discussions

TypeScript

Local

📚 DocGraph

Universal documentation knowledge-graph MCP server with hybrid full-text + vector search.

Index every document in a project — local files plus remote sources from Notion, Jira, Obsidian, Linear, GitHub, and Confluence — into a single SQLite knowledge graph and expose it to AI agents over the Model Context Protocol. Works fully offline, no API key required.

npm version npm downloads License: MIT Node TypeScript Architecture

📦 npm: https://www.npmjs.com/package/@carrilloapps/docgraph

Related MCP server: Hoard

Why DocGraph

AI coding agents are only as good as the context they can find. DocGraph turns any project plus its remote knowledge sources into a single hybrid search index that an agent can query with natural language. The search returns the most relevant documents, headings, and code blocks — combining keyword search with semantic vector search across both local files and external SaaS sources.

Zero setup. A built-in, dependency-free local embedding provider means hybrid search works immediately — no API key, no model download, everything stays on your machine.
Multi-source. Pull documents from Notion, Jira, Confluence, Linear, GitHub issues/PRs, and local Obsidian vaults into the same graph as your filesystem.
Multi-project. One MCP server, many indexed projects — pass projectPath to each tool call.
Agent-native. Ships an installer that natively wires DocGraph into 8 AI agents — Claude Code, Cursor, opencode, Gemini CLI, Codex CLI, Kiro, Antigravity, and (best-effort) Hermes — each in its own native config format. See Supported agents.
Auto-sync. A debounced file watcher keeps the index current while docgraph watch or the MCP server is running — no manual reindex needed. See Auto-sync.
Benchmark harness. npm run benchmark clones real doc repos and runs a real git grep (or file-scan) baseline against DocGraph search, N runs median — see Benchmarks.

Features

🔎 Hybrid search — SQLite FTS5 + cosine vector similarity, merged with configurable weights.
🧠 Offline embeddings out of the box — deterministic feature-hashing vectors; swap in a cloud provider anytime.
🌐 Remote source adapters — Notion, Jira, Confluence (Cloud + Data Center), Linear, GitHub, Obsidian, all bundled, with retry/backoff and hash-based re-embed skipping.
🔄 Auto-sync — a debounced file watcher re-indexes changed files and removes deleted ones while docgraph watch or the MCP server runs.
🗂️ Multi-format indexing — Markdown (front-matter in YAML/TOML/JSON, headings, links, code blocks, tags), JSON, YAML, TOML, AsciiDoc, reStructuredText, Org-mode, plus doc-oriented symbol and comment extraction for JS/TS, Python, Go, Rust, Java/Kotlin/C#, and generic parsing across 40+ file types.
🕸️ Knowledge graph — documents, headings, tags, and internal links modelled as nodes and edges you can traverse.
📚 Multi-project — one MCP process serves every indexed project via the projectPath arg.
🔌 MCP server — 9+ tools exposed over stdio for AI agents.
🧑‍💻 8-agent native install — docgraph install writes each agent's own MCP config format non-destructively and can uninstall symmetrically.
📊 Benchmark suite — real git grep/file-scan baseline vs. DocGraph search, N-run median per scenario; see Benchmarks.
🧩 Clean Architecture — domain / application / infrastructure / presentation layers with dependency inversion, fully unit- and integration-tested.

Doc-oriented, not a code AST. DocGraph's per-language code parsing (JS/TS, Python, Go, Rust, Java/Kotlin/C#) extracts top-level symbol names, headings, and leading doc comments/docstrings via targeted regexes — enough to make source files searchable and to surface their structure in the knowledge graph. It is a companion to a dedicated code-graph tool (e.g. codegraph), not a replacement for a real compiler-grade AST/call-graph.

Supported agents

docgraph install (and docgraph init) detect installed agents and write DocGraph's MCP server into each one's own native config format — no manual JSON/TOML editing required. Every agent below is wired natively; nothing here is a no-op.

Agent	Config path	Format
Claude Code	`.mcp.json` (local) / `~/.claude.json` (global)	JSON `mcpServers.<name>`
Cursor	`.cursor/mcp.json` (local) / `~/.cursor/mcp.json` (global)	JSON `mcpServers.<name>`
opencode	`opencode.json`/`opencode.jsonc` (local) / `~/.config/opencode/opencode.json` (global)	JSON `mcp.<name>` block
Gemini CLI	`.gemini/settings.json` (local) / `~/.gemini/settings.json` (global)	JSON `mcpServers.<name>`
Codex CLI	`.codex/config.toml` (local) / `~/.codex/config.toml` (global)	TOML `[mcp_servers.<name>]`
Kiro	`.kiro/settings/mcp.json` (local) / `~/.kiro/settings/mcp.json` (global)	JSON `mcpServers.<name>`
Antigravity	`~/.gemini/antigravity/mcp_config.json` (single well-known location)	JSON `mcpServers.<name>`
Hermes Agent	`.hermes/mcp.json` (local) / `~/.hermes/mcp.json` (global)	JSON `mcpServers.<name>` — best-effort, unverified: Hermes has no publicly documented MCP config schema, so this follows the de-facto convention shared by the other agents above

Installs are non-destructive: existing keys and unrelated servers in a config file are preserved, and a file that fails to parse is left untouched (install reports a skip rather than clobbering it). docgraph uninstall is symmetric — it removes exactly the docgraph entry it added.

Remote document sources

Every source listed below ships as a built-in adapter. Enable one or many in .docgraph/settings.json under sources.sources.<name> and they are pulled, indexed, and searched alongside local files.

Source	Auth	Notes
Obsidian	None (filesystem)	Walks a local vault, parses YAML front-matter, extracts inline `#tags` and `[[wikilinks]]`.
Notion	Bearer integration token	Database query or workspace search; cursor-based pagination (no page-100 cap, no duplicate pages); renders blocks to Markdown.
Jira (Cloud)	Email + API token (Basic) or OAuth bearer	JQL filter configurable; ADF body rendered to Markdown.
Confluence (Cloud)	Email + API token (Basic)	REST v2, space ID or CQL filter. Indexes the full page body (`body-format=storage`/`expand=body.storage`), not just metadata.
Confluence (Data Center / self-hosted)	Username + password (or PAT)	Same REST model as Cloud with no cloud-id prefix.
Linear	Personal API key	GraphQL `issues` query, team and state filters. Pagination is still capped to the first page of results — large teams won't get every issue in one pull.
GitHub	Fine-grained PAT	Issues or pull requests, optional state filter.

All HTTP-based sources (Notion, Jira, Confluence, Linear, GitHub) retry on 429/5xx with exponential backoff + jitter (honoring a Retry-After header when present); if a page fails after retries are exhausted, results already fetched are kept instead of being discarded for the whole run. Remote documents are content-hashed like local files — a pull that finds no change since the last run skips re-parsing/re-embedding that document, so repeated index/sources pull runs against a large, mostly-unchanged remote corpus don't re-pay embedding cost every time.

Obsidian, Jira (Cloud), Confluence (Cloud + Data Center), Linear, GitHub, and the Postman/OpenAPI source are exercised in the test suite and confirmed working as described above.

DocGraph collects and transmits no telemetry of any kind. See TELEMETRY.md.

Auto-sync

Both docgraph watch and the MCP server (docgraph-mcp serve) run a debounced filesystem watcher (via chokidar) on the served project. When files change, DocGraph re-indexes only the changed files — not a full reindex — and removes documents for any file that was deleted. Bursts of events (e.g. a save-all or a branch checkout) are coalesced by a debounce window before the sync runs, so a flurry of edits triggers one incremental sync instead of one per file event.

docgraph watch                 # index, then watch this project and auto-reindex on change
docgraph watch /path/to/project

Autosync is on by default for both watch and serve. Disable it with any of:

--no-watch (CLI flag on serve)
DOCGRAPH_NO_WATCH=1 (environment variable)
"watch": { "enabled": false } in .docgraph/settings.json

The debounce window is configurable via watch.debounceMs (default 1000 ms) — see Configuration.

Read-only mode

Run DocGraph so it never writes to the index: no indexing, no embedding writes, no autosync, no settings mutation — only reads (search, explore, get_*, list, stats, logs). Useful for serving a pre-built index to an agent, CI, or any untrusted context where the index must not change. Every mutating store method throws, the write MCP tools (index_project, index_file) return a JSON-RPC error, and the SQLite connections are opened { readonly: true, fileMustExist: true } — so the project must already be indexed.

Enable it with any of (highest precedence first):

--read-only (CLI flag, and on docgraph-mcp serve)
DOCGRAPH_READ_ONLY=1 (environment variable)
"security": { "readOnly": true } in .docgraph/settings.json

docgraph index                          # build the index first (writable run)
docgraph search "auth" --read-only      # then query it without any writes
DOCGRAPH_READ_ONLY=1 npx @carrilloapps/docgraph docgraph-mcp serve

The flag/env force read-only for the whole process regardless of a project's own settings; when neither is set, each project falls back to its own settings.security.readOnly (default false).

Installation

# As a dependency of the repo you want to index (recommended — local MCP server)
npm install --save-dev @carrilloapps/docgraph
npx docgraph init

# Or globally
npm install -g @carrilloapps/docgraph

# Self-contained installer (no Node.js required; bundles its own runtime)
# macOS / Linux:
curl -fsSL https://raw.githubusercontent.com/carrilloapps/docgraph/main/install.sh | sh
# Windows (PowerShell):
irm https://raw.githubusercontent.com/carrilloapps/docgraph/main/install.ps1 | iex

# From source
git clone https://github.com/carrilloapps/docgraph.git
cd docgraph
npm install
npm run build

The package installs three binaries, each with a short alias:

docgraph — CLI (short: dg)
docgraph-mcp — MCP server over stdio (short: dg-mcp; also reachable as docgraph mcp)
docgraph-install — agent auto-installer for all 8 supported agents (Claude Code, Cursor, opencode, Gemini CLI, Codex CLI, Kiro, Antigravity, Hermes) (short: dg-install)

Every subcommand also has a short alias (e.g. dg s "query" = docgraph search "query", dg i = docgraph index, dg st = docgraph stats) — see CLI reference.

Requires Node.js ≥ 18 on developer machines, or the bundled installer for users.

Quick start

# 1. Add DocGraph as a dev dependency and wire it into your agents.
npm install --save-dev @carrilloapps/docgraph
npx docgraph-install --yes                # auto-detect every installed agent (see Supported agents)

# 2. Configure remote sources you want indexed.
$EDITOR .docgraph/settings.json          # enable notion / jira / github / obsidian / ...

# 3. Build the index (filesystem + every enabled remote source).
docgraph init                             # one-shot: settings + initial index + per-agent MCP config
docgraph search "authentication"

# 4. Inspect.
docgraph stats
docgraph sources list                     # configured + enabled status for every source

docgraph init creates .docgraph/settings.json, builds the index, and writes portable MCP configuration (.mcp.json and opencode.json) that launches the server via npx — no absolute paths, so it works on any machine and OS.

Running from source? Use node dist/presentation/cli/cli.js <command> (or the npm run index / npm run search scripts) instead of the global docgraph binary.

CLI reference

docgraph <command> [options]        # or the short binary: dg <command>

Commands (short alias):
  init [path]              One-shot: settings, initial index, per-agent MCP config
  install | uninstall      Wire DocGraph into / remove from every detected AI agent
  index [path]        (i)  Index local files plus every enabled remote source
  reindex [path]      (ri) Clear and re-index
  watch [path]        (w)  Index, then auto-reindex on file changes (autosync)
  search <query>      (s)  Hybrid search (text + vector)   [also: q]
  stats [path]        (st) Show index statistics
  stats-json [path]   (stj) Show statistics as JSON
  list [path]         (ls) List all indexed documents
  sources [action]    (src) Manage remote sources (list|enable|disable|pull)
  apis [action]            Manage API specs (add|list|remove|enable|disable|pull)
  logs [options]           Read .docgraph/docgraph.log (--tail|--level|--grep|--follow*)
  export <file>       (exp) Export the current .docgraph.db to a portable file
  import <file>       (imp) Import a previously-exported .docgraph.db backup
  exclude [action]    (ex) Manage exclude patterns (list|add|remove|default|gitignore)
  files                    List supported file extensions
  settings [action]   (cfg) Manage settings (show|init|path)
  providers           (prov) List supported embedding providers
  serve [path]             Print MCP server configuration
  mcp [path]               Run the MCP server over stdio (= the docgraph-mcp binary)

Long and short forms are interchangeable — docgraph search "api", dg search "api", and dg s "api" are identical.

* --follow streams new log entries live as they're written (polling by byte offset, so it keeps working no matter how large the file grows) — Ctrl-C to stop. --tail, --level, and --grep all work as documented. See LOGGING.md.

Search options: --limit=n, --format=json|text, --ext=<ext>, --lang=<lang>, --tags=a,b,c, --no-vector, --no-text. Any command accepts --path=<dir>.

docgraph search "api" --lang=typescript --format=json
docgraph sources list                              # see which sources are enabled
docgraph sources pull --path=/path/to/project      # force a remote-source refresh
docgraph exclude add "**/fixtures/**"
docgraph stats

MCP server

MCP speaks over stdio. docgraph init writes the config below automatically; docgraph serve prints it without touching any files. The launch command is portable — it resolves the locally installed binary via npx, so there are no absolute, machine-specific paths. The project root is inferred from the server's working directory, the DOCGRAPH_PROJECT env var, or the projectPath argument every tool accepts.

Launch forms (short & long)

The server can be started three equivalent ways — use whichever you prefer:

Form	Command
Short (recommended for humans)	`npx -y @carrilloapps/docgraph mcp`
Explicit binary	`npx -y -p @carrilloapps/docgraph docgraph-mcp serve`
Short binary alias	`npx -y -p @carrilloapps/docgraph dg-mcp serve`

The generated agent configs below use the explicit docgraph-mcp binary for maximum robustness; the short mcp subcommand is a convenience that routes through the main CLI.

Claude Code (.mcp.json):

{
  "mcpServers": {
    "docgraph": {
      "command": "npx",
      "args": ["-y", "-p", "@carrilloapps/docgraph", "docgraph-mcp", "serve"]
    }
  }
}

opencode (opencode.json):

{
  "mcp": {
    "docgraph": {
      "type": "local",
      "command": ["npx", "-y", "-p", "@carrilloapps/docgraph", "docgraph-mcp", "serve"],
      "enabled": true
    }
  }
}

Set DOCGRAPH_DEBUG=1 to log JSON-RPC traffic to stderr.

Available tools

Tool	Description
`index_project`	Index local files plus every enabled remote source
`index_file`	Index a specific file
`search`	Hybrid search across indexed documents (with optional `projectPath`)
`explore`	Explore a topic with surrounding context (headings, code)
`get_document`	Get a document by ID or path
`get_related`	Get documents related by tags and links
`get_stats`	Get index statistics
`list_documents`	List indexed documents
`get_document_graph`	Get a document's node/edge connections
`list_projects`	List projects with an active `.docgraph` index in this MCP server

Embeddings & providers

By default provider: "auto" resolves to the built-in local provider — deterministic, offline, dependency-free hashing embeddings that make hybrid search work with no setup. For higher-quality semantic recall, configure a cloud or local-server provider; auto picks it up automatically when the matching API key is present in the environment.

Run docgraph providers to see every provider and its API-key environment variable.

Local, no key: local (default), ollama, lmstudio, localai, jan
Cloud, API key: openai, cohere, voyageai, mistral, google, huggingface, fireworks, togetherai, azure, minimax, replicate

export OPENAI_API_KEY=sk-...
docgraph reindex      # auto-detects OpenAI and regenerates embeddings

Configuration

Settings are read from .docgraph/settings.json (or docgraph.json) at the project root; anything omitted falls back to sensible defaults. Values of the form ${ENV_VAR} are expanded from the environment. Create a starter file with docgraph settings init.

{
  "embedding":   { "provider": "auto", "dimension": 256 },
  "indexing":    { "chunkSize": 512, "generateOnIndex": true },
  "search":      { "vectorWeight": 0.7, "textWeight": 0.3, "minScore": 0.1, "limit": 20 },
  "exclude":     { "useGitignore": true, "useDefaultPatterns": true },
  "sources": {
    "sources": {
      "notion":  { "enabled": true, "options": { "token": "${NOTION_TOKEN}", "databaseId": "..." } },
      "obsidian":{ "enabled": true, "options": { "vaultPath": "/Users/me/Vault" } },
      "jira":    { "enabled": false, "options": { "host": "https://acme.atlassian.net" } }
    },
    "pullOnIndex": true,
    "pullOnReindex": true,
    "maxPagesPerSource": 50,
    "maxConcurrentSources": 4
  },
  "watch": { "enabled": true, "debounceMs": 1000 },
  "security": { "readOnly": false }
}

sources.pullOnIndex, sources.pullOnReindex, sources.maxPagesPerSource, and sources.maxConcurrentSources are enforced: index/reindex consult pullOnIndex/ pullOnReindex to decide whether to touch the network at all, each remote source is capped to maxPagesPerSource pages via configureMaxPages(), and up to maxConcurrentSources sources are pulled concurrently instead of strictly one at a time.

Key	Default	Description
`embedding.provider`	`auto`	Embedding provider (`local`, `openai`, ...)
`embedding.dimension`	`256`	Vector size for the `local` provider
`indexing.chunkSize`	`512`	Characters per embedded chunk
`indexing.generateOnIndex`	`true`	Generate embeddings while indexing
`sources.sources.<name>.enabled`	`false`	Per-source enable flag
`sources.pullOnIndex`	`true`	Whether `index` pulls remote sources at all
`sources.pullOnReindex`	`true`	Whether `reindex` pulls remote sources at all
`sources.maxPagesPerSource`	`50`	Per-source page cap, forwarded to each adapter
`sources.maxConcurrentSources`	`4`	Max remote sources pulled concurrently
`watch.enabled`	`true`	Auto-sync file watcher for `watch`/`serve` (see Auto-sync)
`watch.debounceMs`	`1000`	Debounce window (ms) before an auto-sync re-index runs
`security.readOnly`	`false`	Forbid all writes; overridden per-run by `--read-only` / `DOCGRAPH_READ_ONLY` (see Read-only mode)
`search.vectorWeight` / `textWeight`	`0.7` / `0.3`	Hybrid merge weights
`search.minScore`	`0.1`	Minimum cosine similarity for vector hits
`exclude.useGitignore`	`true`	Honour the project `.gitignore`

Programmatic API

import { Container } from '@carrilloapps/docgraph';

const docgraph = new Container('/path/to/project');
await docgraph.indexing.indexProject();

const results = await docgraph.search.search({ query: 'authentication tokens', limit: 5 });
for (const hit of results) {
  console.log(`${(hit.score * 100).toFixed(1)}%  ${hit.document.relativePath}`);
}

// Remote sources are first-class: pull them on demand.
const counts = await docgraph.indexing.pullRemoteSources();
console.log('Pulled:', counts);

docgraph.close();

Individual services (IndexingService, SearchService, QueryService), ports, adapters, the ProjectRegistry, and every source implementation are all exported for advanced composition and testing.

Multi-project support

One MCP server process serves every indexed project. Each tool call accepts an optional projectPath argument; if absent, the server uses the DOCGRAPH_PROJECT env var or its working directory. Projects are kept in a small LRU (default DOCGRAPH_MAX_PROJECTS=16) so long-running sessions don't grow unbounded. Use list_projects to inspect what's loaded.

// Library form
import { ProjectRegistry } from '@carrilloapps/docgraph';
const registry = new ProjectRegistry({ maxProjects: 16 });
const services = registry.get('/projects/alpha');
const other    = registry.get('/projects/beta');

DOCGRAPH_MAX_PROJECTS=32 npx @carrilloapps/docgraph docgraph-mcp serve

Benchmarks

npm run benchmark clones real-world documentation repos, builds a DocGraph index, and runs a fixed set of natural-language queries against it, scoring both a WITH (DocGraph search) and a WITHOUT DocGraph arm. The baseline arm is a real comparison, not a stub: git grep -n -i over the same checkout, falling back to a manual recursive file scan if git is unavailable. Each scenario is measured N runs (default 4), median reported.

npm run build                                    # benchmark shells out to dist/, so build first
npm run benchmark
npm run benchmark -- --runs=8                    # custom run count
npm run benchmark -- --scenario=react-native     # one scenario at a time

Results are generated locally, on demand — the script writes a full report (per-run latency, hit counts, and a per-scenario summary) to benchmarks/results.json and prints a summary table to stdout. That output directory is not checked into this repository or published anywhere, so no numbers are quoted here — run it yourself against your own docs. Bundled scenarios: react-native (facebook/react-native), supabase-js (supabase/supabase-js), and astro (withastro/docs).

Telemetry

DocGraph collects, stores, and transmits no telemetry or usage data of any kind. See TELEMETRY.md for the full policy. Every event — index start, vector-search warning, source fetch, MCP request — is written as a structured JSON-Lines entry to .docgraph/docgraph.log and rotated locally (format reference in LOGGING.md). Nothing leaves the user's machine unless you explicitly configure a cloud embedding provider, in which case only document chunks are sent to that provider to compute embeddings.

docgraph logs                            # last 50 entries
docgraph logs --tail=200 --level=error   # last 200 errors only
docgraph logs --grep="vector"            # entries matching 'vector'
docgraph logs --grep="vector" --follow   # streams new matches live, Ctrl-C to stop
docgraph logs --all                      # list every rotated file
docgraph logs --format=json              # pipe into jq / dashboards

Log format (one JSON object per line, NDJSON / JSON-Lines):

{"ts":"2026-07-03T18:53:36.975Z","level":"info","msg":"embeddings.enabled","ctx":{"provider":"auto","resolvedProvider":"local"}}
{"ts":"2026-07-03T18:53:37.443Z","level":"info","msg":"indexing.complete","ctx":{"component":"indexing","documents":61,"nodes":216,"edges":175,"vectors":828}}

Configure via .docgraph/settings.json:

{
  "logging": {
    "level": "info",                // "error" | "warn" | "info" | "debug"
    "maxBytes": 5242880,            // 5 MB before rotation
    "maxFiles": 3,                  // docgraph.log, .1, .2 retained
    "mirrorStderr": false           // set true or DOCGRAPH_DEBUG=1 to mirror to stderr
  }
}

Level	What you'd see at default `info`
`error`	Uncaught exceptions, embedding provider failures, MCP tool errors
`warn`	Embeddings disabled, malformed config, source fetch failures
`info`	Index start/complete, source initialised, project loaded, MCP tool calls
`debug`	Per-request latency, every batch embed, every GraphQL round-trip

Architecture

DocGraph follows Clean Architecture. Dependencies point inward — inner layers know nothing about outer ones — so the core logic is independent of SQLite, HTTP and the file system.

┌──────────────────────────────────────────────────────────────────────────┐
│ presentation/        CLI · MCP server (stdio JSON-RPC) · Installer        │
├──────────────────────────────────────────────────────────────────────────┤
│ container.ts         composition root (wires everything per project)      │
│ project-registry.ts  LRU cache of containers, one per projectPath          │
├──────────────────────────────────────────────────────────────────────────┤
│ application/         IndexingService · SearchService · QueryService       │
│                      (use cases — pullRemoteSources() lives here)         │
├──────────────────────────────────────────────────────────────────────────┤
│ domain/              entities · ports (interfaces) ·                       │
│                      chunker   (no external deps)                          │
├──────────────────────────────────────────────────────────────────────────┤
│ infrastructure/      SQLite store · vector store · embedding providers ·   │
│                      filesystem source · remote sources (Notion, Jira,    │
│                      Obsidian, Confluence, Linear, GitHub) ·               │
│                      file watcher (auto-sync) · config                    │
└──────────────────────────────────────────────────────────────────────────┘

src/
├── domain/                          # Enterprise rules — depends on nothing
│   ├── entities.ts                  #   Document, GraphNode/Edge, SearchResult, ... (Zod)
│   ├── ports.ts                     #   Repository, VectorStore, EmbeddingProvider, ...
│   └── chunker.ts                   #   Pure text-chunking service
├── application/                     # Use cases — depends only on domain
│   ├── indexing-service.ts          #   indexProject, pullRemoteSources, indexRemoteDocument
│   ├── search-service.ts
│   └── query-service.ts
├── infrastructure/                  # Adapters — implement domain ports
│   ├── config/settings.ts           #   DocGraphSettings + sources.sources
│   ├── persistence/                 #   SQLite knowledge store + vector store
│   ├── filesystem/                  #   Document source + multi-format parser
│   ├── embeddings/                  #   Provider factory + local/cloud providers
│   ├── sources/                     #   Remote source adapters (Notion, Jira, Obsidian, ...)
│   └── watch/                       #   Debounced file watcher (auto-sync)
├── presentation/                    # Entry points
│   ├── cli/                         #   Argument parsing + CLI
│   ├── installer/                   #   Native install for all 8 supported agents
│   └── mcp/                         #   MCP server (multi-project, autosync)
├── container.ts                     # Composition root
├── project-registry.ts              # Multi-project LRU
└── index.ts                         # Public library API

The document metadata, knowledge graph, vectors, and remote-source cache all live in a single SQLite database at .docgraph/docgraph.db inside the indexed project.

Development

npm install
npm run build          # compile TypeScript to dist/
npm run typecheck      # type-check without emitting
npm test               # node:test runner, 60+ specs across 12 files
npm run benchmark      # real git-grep/file-scan baseline vs. DocGraph search, see Benchmarks section

Tests use the built-in node:test runner (no test-framework dependency) and cover the domain services, infrastructure adapters, remote sources, multi-project registry, and full end-to-end flows through the composition root.

License

MIT © Junior Carrillo

Available Tools

10 tools

exploreC

Explore a topic with surrounding context

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`topic`	Yes
`projectPath`	No	Absolute path to the indexed project (defaults to the running server’s project root). Use it to query a different project in the same session.	/app

TDQS

C2.2/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It does not disclose whether the tool is read-only, has side effects, or requires specific permissions. The description is minimal and uninformative.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very short (5 words), which sacrifices clarity for conciseness. It is front-loaded but lacks essential details to be useful.

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

Completeness1/5

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

Given 3 parameters, no output schema, and similar sibling tools, the description is critically incomplete. It does not explain what 'context' means, what the tool returns, or how it differs from search or get_related.

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

Parameters2/5

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

The description adds no meaning to the parameters beyond the schema. Schema coverage is only 33%, but the description does not compensate by explaining topic, limit, or projectPath in context.

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

Purpose3/5

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

The description 'Explore a topic with surrounding context' states a general purpose but lacks specificity. It does not differentiate from sibling tools like search or get_related. It is not a tautology but is vague.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of context, exclusions, or when not to use it.

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

get_documentC

Get a document by ID or path

ParametersJSON Schema

Name	Required	Description	Default
`id`	No
`path`	No
`projectPath`	No	Absolute path to the indexed project (defaults to the running server’s project root). Use it to query a different project in the same session.	/app

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided, and the description gives no behavioral context such as error handling, authentication needs, or idempotency. Only states the basic action.

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?

The description is a single, front-loaded sentence with no unnecessary words. However, it could include additional context without losing conciseness.

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?

For a simple retrieval tool with no output schema, the description lacks details on return format, default behavior, or edge cases. It is minimally complete for basic understanding.

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

Parameters2/5

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

Schema coverage is only 33% (only projectPath has a description). The tool description does not elaborate on id, path, or their relationship, leaving the AI agent to infer from type alone.

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 action (get), resource (document), and method (by ID or path). It distinguishes from sibling tools like get_document_graph or get_related which have different purposes.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like search or explore. No mention of prerequisites or when not to use it.

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

get_document_graphC

Get a document node/edge connections

ParametersJSON Schema

Name	Required	Description	Default
`documentId`	Yes
`projectPath`	No	Absolute path to the indexed project (defaults to the running server’s project root). Use it to query a different project in the same session.	/app

TDQS

C2.4/5.0

Behavior1/5

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

No annotations are provided, so the description must disclose behavioral traits. It only states the action, but does not mention whether it is read-only, requires prior indexing (especially given siblings 'index_file' and 'index_project'), or has any side effects. This is insufficient for safe invocation.

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?

The description is a single, concise sentence with no wasted words. It is appropriately front-loaded. However, it could include more information without becoming verbose.

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

Completeness1/5

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

For a graph retrieval tool with no output schema and no annotations, the description is woefully incomplete. It does not specify what nodes and edges are returned, whether pagination exists, or if there are performance implications. Given the complexity, the description fails to provide essential operational context.

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

Parameters2/5

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

Schema coverage is 50% (projectPath has a description, documentId does not). The tool description adds no extra meaning to parameters; it does not explain what 'documentId' or 'projectPath' represent in the graph context. With low coverage and no additional context, the parameter semantics are poor.

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 'Get a document node/edge connections' clearly states the action (get) and the resource (document node/edge connections), indicating it retrieves graph relationships. It is not a tautology and distinguishes itself from siblings like 'get_document' (single document) and 'get_related' (related items). However, it could be more specific about the type of graph (e.g., dependency or citation).

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like 'get_related' or 'explore'. There are no prerequisites or exclusion criteria mentioned. The description lacks context for situational use.

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

get_relatedC

Get related documents

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`documentId`	Yes
`projectPath`	No	Absolute path to the indexed project (defaults to the running server’s project root). Use it to query a different project in the same session.	/app

TDQS

C2.6/5.0

Behavior2/5

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

With no annotations provided, the description bears full responsibility for behavioral transparency. It only states 'Get related documents' without explaining the underlying relatedness logic, performance implications, or whether any side effects occur.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise (4 words), but this brevity comes at the expense of informativeness. While it is not verbose, it does not earn its place by providing sufficient detail.

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?

Given the presence of three parameters, no output schema, and no annotations, the description is far from complete. It lacks critical context such as the definition of 'related', how the 'limit' parameter affects results, and any expected output format.

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

Parameters2/5

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

Schema description coverage is only 33% (only 'projectPath' has a description). The tool description adds no additional meaning for parameters 'documentId' and 'limit', leaving the agent uninformed about what 'limit' controls or what 'documentId' refers to.

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 'Get related documents' clearly specifies the action (get) and the resource (related documents), making the tool's purpose reasonably clear. However, it does not differentiate from sibling tools like 'get_document_graph' which might also retrieve related documents.

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

Usage Guidelines2/5

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

No usage guidelines are provided. The description does not indicate when to use this tool versus alternatives such as 'search' or 'explore', nor does it specify any prerequisites or constraints.

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

get_statsC

Get index statistics

ParametersJSON Schema

Name	Required	Description	Default
`projectPath`	No	Absolute path to the indexed project (defaults to the running server’s project root). Use it to query a different project in the same session.	/app

TDQS

C2.5/5.0

Behavior2/5

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

With no annotations, the description carries full burden but only states a read-like operation. It does not disclose whether the tool is purely read-only, requires specific permissions, or how it behaves with invalid project paths. No side effects or error conditions are mentioned.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise at three words, but lacking structure or front-loading of key information. While brevity is valued, the description sacrifices completeness for conciseness, providing minimal actionable 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?

No output schema, and the description does not specify what the tool returns (e.g., numeric stats, object). For a simple tool with one parameter, more detail (like return format or example values) would greatly improve completeness without needing an 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 coverage is 100%, and the description adds no meaning beyond what the parameter's own description already provides. The tool's one-line description does not elaborate on parameter usage or constraints, so it relies entirely on the schema.

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

Purpose3/5

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

Description 'Get index statistics' conveys the verb and resource but lacks specificity about what 'index statistics' entails (e.g., document count, size). It does not distinguish itself from sibling tools like 'list_documents' or 'list_projects', which could also relate to index information.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives such as 'list_documents' or 'search'. The description does not mention prerequisites, typical use cases, or scenarios where this tool is preferred over siblings.

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

index_fileC

Index a specific file

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	Path to the file
`projectPath`	No	Absolute path to the indexed project (defaults to the running server’s project root). Use it to query a different project in the same session.	/app

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It does not explain what 'indexing' entails (e.g., parsing, search indexing), side effects, permissions, or state changes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is concise, but it sacrifices necessary context. It could be expanded to include important details without becoming verbose.

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?

No output schema is provided, yet the description does not mention return values or results. The tool's behavior is underspecified given the complexity of indexing.

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 the schema already documents both parameters adequately. The description adds no extra meaning beyond the schema, meeting the baseline of 3.

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 'Index a specific file' clearly states the verb (index) and resource (specific file), but lacks differentiation from sibling tools like 'index_project' or 'search'. No title is provided.

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

Usage Guidelines2/5

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

No guidance is given on when to use this tool versus alternatives. Sibling tools such as 'index_project' and 'search' exist but no criteria for selecting among them are mentioned.

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

index_projectC

Index all documents in the project

ParametersJSON Schema

Name	Required	Description	Default
`projectPath`	No	Absolute path to the indexed project (defaults to the running server’s project root). Use it to query a different project in the same session.	/app

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It only states 'Index all documents' without explaining side effects (e.g., potential long duration, mutation of state, idempotency, or required permissions). The short description leaves significant behavioral ambiguity.

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 sentence with zero waste. It is front-loaded and efficient, earning its length.

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?

Given the complexity of an indexing operation (potentially expensive, irreversible), the description is incomplete. It lacks details about return values, error conditions, or operational impact. No output schema exists, and annotations are absent, so the description fails to provide sufficient context for safe agent 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?

Schema coverage is 100% (the single parameter is well-described in the schema). The tool description adds no additional meaning beyond the schema. Baseline 3 is appropriate since the description does not enhance parameter understanding.

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 indexes all documents in a project, using a specific verb and resource. It distinguishes from sibling tools like 'index_file' (single file) and 'search' (querying). However, it lacks specifics on what indexing entails (e.g., building a search index).

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives, such as 'index_file' for selective indexing. The description does not mention prerequisites, limitations, or when not to use it. The parameter hint about querying a different project is the only context, but it is directive, not usage guidance.

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

list_documentsC

List all indexed documents

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`language`	No
`extension`	No
`projectPath`	No	Absolute path to the indexed project (defaults to the running server’s project root). Use it to query a different project in the same session.	/app

TDQS

C2.5/5.0

Behavior2/5

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

With no annotations, the description must fully disclose behavior. It only states 'List all indexed documents'—no mention of pagination, ordering, performance implications, or how parameters like 'limit' affect results. The agent cannot anticipate important behavioral traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely terse (5 words), which is under-specification rather than effective conciseness. It lacks essential details that a longer, well-structured description would provide, diminishing its utility.

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?

No output schema is provided, and the description omits return value details, error handling, or behavior for empty results. For a list tool with four parameters, this description is incomplete and leaves the agent with insufficient information to use the tool reliably.

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

Parameters2/5

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

Schema description coverage is only 25% (only 'projectPath' has a description). The tool description adds no explanation for 'limit', 'language', or 'extension'. Given low coverage, the description should compensate but fails to clarify parameter meaning or constraints.

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 uses a specific verb 'List' and identifies the resource 'indexed documents', making the basic purpose clear. However, it does not differentiate from sibling tools like 'search' or 'explore', and the phrase 'all' contradicts the filtering parameters available, slightly reducing clarity.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. Siblings like 'search' or 'get_related' likely serve different querying needs, but the description offers no context for selection, leaving the agent without decision support.

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

list_projectsA

List projects with an active .docgraph index in this MCP server.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior4/5

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

Without annotations, the description partially covers behavior by specifying the condition (active .docgraph index) and implying a read-only list, though it omits details like 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that efficiently conveys the purpose with no unnecessary words.

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 zero-parameter tool with no output schema, the description is nearly complete, though it could clarify the scope of 'projects' in the MCP server.

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?

No parameters exist, so baseline 4 applies; description adds no param info which is appropriate.

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 lists projects with an active .docgraph index, distinguishing it from siblings like list_documents and index_project.

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 usage for listing indexed projects but provides no explicit guidance on when to use vs. alternatives or when not to use.

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

searchC

Search documents using hybrid full-text + vector search

ParametersJSON Schema

Name	Required	Description	Default
`tags`	No	Filter by tags
`fuzzy`	No	Use fuzzy matching
`limit`	No	Max results
`query`	Yes	Search query
`language`	No	Filter by language
`extension`	No	Filter by extension
`projectPath`	No	Absolute path to the indexed project (defaults to the running server’s project root). Use it to query a different project in the same session.	/app

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are present, so the description must carry the full burden of behavioral disclosure. It mentions the hybrid search method but does not state that the tool is read-only, potential side effects, or any constraints. This is insufficient for a search tool with no annotation safety net.

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?

The description is a single sentence with no wasted words. However, it could benefit from slightly more detail without becoming verbose, especially given the lack of other 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?

The description is too brief for a tool with 7 parameters, no output schema, and no annotations. It does not explain how parameters interact, the concept of hybrid search, or what the return format looks like, leaving significant gaps for an AI 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 description coverage is 100%, and each parameter has a clear description in the schema. The tool description adds no additional meaning beyond what the schema provides, so a baseline score of 3 is appropriate.

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 searches documents using hybrid full-text and vector search. The verb 'Search' and resource 'documents' are specific, but it does not differentiate from sibling tools like 'explore' or 'get_related'.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives among sibling tools. There is no mention of prerequisites or context that would help an agent decide to use this search over other tools.

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 updatesv1.0.1Jul 4, 2026
- First observedexplore
- First observedget_document
- First observedget_document_graph
- First observedget_related
- First observedget_stats
- First observedindex_file
- First observedindex_project
- First observedlist_documents
- First observedlist_projects
- First observedsearch

Install Server

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

TDQS

B3.3/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: exploration, document retrieval, graph connections, related documents, stats, indexing, and listing. No overlaps or ambiguity.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern in snake_case (e.g., get_document, index_file, list_projects), with only a few single-verb names like explore and search, which are still clear and fit the pattern.

Tool Count5/5

10 tools is well-scoped for a document indexing and exploration server, covering indexing, querying, and management without excess or deficiency.

Completeness4/5

The tool surface covers core workflows: indexing (file and project), querying (search, explore, get, related, graph), and listing. Missing update or delete operations, but these are not central to exploration-focused design.

Maintenance

ActivityStale

ResponsivenessSyncing

Resources

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

DocsMint
io.github.HiAi-gg
Self-hosted AI-native knowledge workspace with hybrid search, GraphRAG, and MCP.
Documentation Access RAG Systems Knowledge & Memory
171
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
docbase
io.github.krayinc
DocBase MCP server for AI agents
Documentation Access Search Developer Tools
2
hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237

Related MCP Servers

memory-mcp
Knowledge & Memory RAG Systems Search
Shaktisinhchavda
A
license
A
quality
D
maintenance
A local-first MCP server that exposes personal notes and files as unified semantic context for AI agents via vector search and file monitoring.
Updated 4 months ago (2026-05-18 05:14 UTC)
6
MIT
Hoard
Knowledge & Memory RAG Systems Agent Orchestration
thrr87
A
license
Not graded
quality
D
maintenance
Local MCP server for indexing personal knowledge into SQLite with hybrid search, chunk-level citations, memory tools, and agent orchestration.
Updated 7 months ago (2026-02-07 12:52 UTC)
4
MIT
ContextMCP
Documentation Access RAG Systems
dodopayments
A
license
Not graded
quality
A
maintenance
Self-hosted MCP server that indexes documentation from various sources and makes it searchable by AI assistants via the Model Context Protocol and REST API.
Updated 4 days ago (2026-09-01 19:40 UTC)
197
76
Apache 2.0
DocGraph
Knowledge & Memory Search Documentation Access
Detective-XH
A
license
A
quality
A
maintenance
MCP server that indexes Markdown, Word, HTML, and PDF documents into a SQLite knowledge graph with CJK+Latin full-text search and cross-document reference tracking. Runs drift audits to surface stale policies, conflicting research claims, superseded ADRs, and undocumented code exports.
Updated 2 months ago (2026-07-20 08:12 UTC)
10
7
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/carrilloapps/docgraph'

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

📚 DocGraph

Table of contents

Why DocGraph

Features

Supported agents

Remote document sources

Auto-sync

Read-only mode

Installation

Quick start

CLI reference

MCP server

Launch forms (short & long)

Available tools

Embeddings & providers

Configuration

Programmatic API

Multi-project support

Benchmarks

Telemetry

Architecture

Development

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API