# ADR-008: SF Tools Over MCP for Provider Parity

**Status:** Rejected — never implement
**Superseded by:** docs/adr/0000-purpose-to-software-compiler.md + docs/dev/ADR-020-internal-wire-architecture.md
**Date:** 2026-04-09
**Superseded by:** `docs/adr/0000-purpose-to-software-compiler.md`, `docs/dev/ADR-020-internal-wire-architecture.md`

## Decision

Never build or restore an SF MCP server package. SF is not an MCP server product and must not become one.

Current SF uses MCP only as a client-side integration surface for external tools that SF may call. SF workflow execution stays inside the `sf` runtime through in-process extension tools, daemon/RPC/headless paths, and DB-backed workflow state.

## Reason

The original ADR proposed exposing SF workflow tools through a new MCP server for provider parity. That creates another mutable workflow transport and another state-safety surface. The current architecture avoids that extra server boundary: planning, execution, validation, and completion write structured state to SQLite first and render markdown/JSON as projections.

## Operational Rule

- Never recreate `packages/mcp-server`.
- Never add a `src/mcp-server.ts` workflow backend.
- Never document SF as an MCP server provider.
- Never add provider-parity work that depends on SF exposing itself over MCP.
- Keep `src/resources/extensions/mcp-client/` as the client integration boundary.

If a future integration needs external control of SF, use the daemon/RPC/headless contract. MCP remains for SF-as-client only.
