Skip to main content
Engineering Docs ships a minimal MCP (Model Context Protocol) server that exposes three programmatic tools for working with your .engineering-docs/ folder: validating document completeness, checking cross-document consistency, and regenerating the master index. The server runs as a Node.js process communicating over stdio and is compatible with any MCP-capable client — including Claude Code, Cursor, and custom agent harnesses. The MCP integration is most valuable in multi-session projects (where you want to verify document health without running the full orchestrator), CI pipelines (where you want automated quality gates on documentation pull requests), and team workflows (where multiple engineers contribute to the same document set and need consistency enforced automatically).

The .mcp.json configuration

The plugin ships with a ready-to-use .mcp.json at the project root that registers the validation server with any MCP-compatible client:
.mcp.json
The server command is node scripts/validate.js. It reads from .engineering-docs/ in the current working directory, so it must be run from your project root.

Configuring the MCP server in your agent

Claude Code reads .mcp.json automatically when it’s present in the project root. No additional configuration is required — the engineering-docs server will appear in your available MCP tools after the plugin is installed.To verify the server is registered:
You should see engineering-docs in the output with the validate_document_set, check_consistency, and generate_index tools listed.

The three MCP tools

validate_document_set

Checks that all required documents exist in .engineering-docs/ and that each has valid YAML frontmatter. Required documents checked: Frontmatter fields validated on every document:
Required frontmatter fields
Example response:
validate_document_set response

check_consistency

Verifies cross-document consistency across three dimensions: dependency references, entity names, and terminology. What it checks:
  1. Dependency references — Every filename listed in a document’s depends_on frontmatter field must actually exist in .engineering-docs/. Missing dependencies are reported as missing_dependency issues.
  2. Entity name overlap — Using a heuristic of capitalized multi-word phrases, the tool detects when a document’s dependencies define entities that aren’t referenced in the dependent document. A large gap (more than 3 unreferenced entities) is flagged as an entity_gap issue — informational, not always an error.
  3. Terminology consistency — Common terms that appear in multiple variant spellings across documents are flagged. The tool checks variants like:
Example response:
check_consistency response

generate_index

Regenerates the index.md master index from all documents currently in .engineering-docs/. Useful after manual edits to the document set, after a brownfield run that appended new documents, or to restore an accidentally deleted index. What it produces:
Generated index.md
Example response:
generate_index response
generate_index produces the index content as a string in the response — it does not write to disk automatically. Your agent or CI script is responsible for writing the returned index value to .engineering-docs/index.md.

The hooks system

Engineering Docs includes a SessionStart hook that runs check-progress.js automatically at the start of every agent session. This surfaces any in-progress documentation so you can pick up where you left off — without having to remember which documents were still in draft.

hooks/hooks.json

hooks/hooks.json
The hook fires on session startup, clear (context cleared), and compact (context compacted) — the three moments when an agent might otherwise lose track of in-progress work.

What check-progress.js does

The script checks for a .engineering-docs/ folder in the current working directory. If it finds one, it reads index.md and reports any documents with draft or in-progress status:
Example hook output at session start
If no .engineering-docs/ folder exists, the script exits silently. If the folder exists but has no index.md, it prints a prompt to run the orchestrator. If all documents are final with no draft or in-progress items, the script also exits silently — no noise when there’s nothing to report.

When MCP is most useful

CI pipelines

Add validate_document_set and check_consistency as steps in your documentation PR pipeline to catch missing required docs and terminology drift before merge.

Automated quality gates

Block a sprint from starting unless all required documents are status: final and owner_reviewed: true. The validate_document_set response ok field is a clean boolean gate.

Multi-session projects

Large projects span many sessions. The MCP tools let you verify document health at the start of each new session without re-running the full orchestrator pipeline.

Team documentation workflows

When multiple engineers contribute to the same .engineering-docs/ folder, check_consistency can be run as a pre-commit hook to catch entity name and terminology drift introduced by different authors.

Example CI workflow

ci-docs-check.yml
The CI example above treats entity_gap issues as informational (filtered out from the failure check) because not every entity in a dependency needs to be explicitly referenced in a dependent document — the gap heuristic is a signal, not a strict requirement.