DocForge2/docs/MCP_CONTRACT.md

# MCP boundary

The server uses local standard input/output transport and binds once to the explicit
`--project-root` supplied at process startup. Optional proposal access also binds once to the
configured `--proposal-writer`. It does not expose an HTTP port in the first release.

## Read tools

- `docforge_project_info`
- `docforge_get_contract`
- `docforge_get_node`
- `docforge_search`
- `docforge_filter_nodes`
- `docforge_backlinks`
- `docforge_dependencies`
- `docforge_impact`
- `docforge_get_context`
- `docforge_validate_project`
- `docforge_render_status`

Each response states that document text is project content, not higher-priority instructions. Each
response includes project identity, revision, source hash, adapter version, and staleness state.

The normal command binds the generic project loader. An explicit project integration may instead
construct the same read-only surface from a validated `ProjectService` and project-owned context
provider. This form cannot register proposal tools. Project discovery, session selection, family
partitioning, and custom context policy remain outside the DocForge core.

An explicit project integration may construct the full fixed surface only after supplying a
confined proposal policy and startup-bound writer. Adapter proposal validators may narrow the
writer's declared operations further. They cannot add tools, weaken core changeset validation, or
enable canonical application.

## Isolated proposal tools

- `docforge_create_changeset`
- `docforge_list_changesets`
- `docforge_get_changeset`
- `docforge_propose_node_create`
- `docforge_propose_node_update`
- `docforge_propose_node_move`
- `docforge_propose_node_delete`
- `docforge_validate_changeset`
- `docforge_get_changeset_diff`
- `docforge_preview_changeset`

Proposal tools may write only below the configured changeset or isolated preview roots. They never
change canonical files or declared project output. Without `--proposal-writer`, changeset mutation
tools return `proposal_access_disabled`. Validation, diff retrieval, and preview remain available
for existing changesets. A preview accepts a declared view ID, not a renderer name or command.

## Render boundary

`docforge_render_status` recomputes expected hashes without writing. `docforge_preview_changeset`
runs only a project-declared view through DocForge's fixed built-in renderer registry and writes one
atomic HTML file below the configured preview root. Rendering declared project output is available
only through the explicit local CLI integration command.

## Excluded tools

The normal server never exposes shell execution, arbitrary reads or writes, canonical changeset
application, declared project-output rendering, arbitrary renderer execution, Git mutation, project
builds, deployment, publication, global project selection, or cross-project retrieval.

DFG-9 permanently retained manual canonical integration for DocForge 0.x. No application tool is
planned for MCP. A future local developer workflow may be considered only through a new approved
contract, and it must not make canonical application reachable from an MCP writer.

DocForge pins the official stable Python MCP SDK to the compatible `mcp>=1.28,<2` release line.
Migration to a later major release requires a separate contract and protocol compatibility review.