Complete MCP Reference

Reference Facts to consult while you work. Not meant to be read end to end.

Purpose

This is the dedicated user-facing reference for the local sdd-mcp server.

Use this page when you need to know:

• what the MCP server is for
• which tools, resources, and prompts it exposes
• what each operation does
• what side effects it produces
• what output the user should expect

Setup and connectivity live in 33-mcp-server-guide.md, per-script output in 40-command-results-reference.md. If you are not technical, start at 43-easy-mcp-guide.md instead of here.

What sdd-mcp is

sdd-mcp is the operational MCP layer of this framework.

It gives AI clients a structured way to:

• create or bootstrap SDD workspaces
• create and inspect specs
• validate the SDD state of a project
• enforce the implementation gate
• write traceability artifacts
• read key project context through MCP resources

It serves the framework docs too, but the point is the operations: an agent drives the project through this interface.

Visual architecture

flowchart LR
  A["User"] --> B["AI Client"]
  B --> C["sdd-mcp"]
  C --> D["sdd-core"]
  C --> E["MCP Resources"]
  D --> F["Target Project"]
  E --> F
  F --> G["idea/"]
  F --> H["specs/"]
  F --> I["bitacora/"]
  F --> J["docs/"]

Reading path:

• the AI client reads MCP resources and prompts
• sdd-mcp exposes the operational contract
• sdd-core performs the actual project mutations
• the target project stores the resulting SDD artifacts

What the user can expect

With sdd-mcp connected, an AI client returns structured output instead of free-text guesswork, and its writes to status, roadmap, logbook and traceability files are deterministic. Gate checks happen before implementation, not after. Work can live in the default workspace under ./www/<project-name>/, or at any external path on the tools that take a projectRoot.

Scope rules

• Recommended default workspace inside this template: ./www/<project-name>/
• External target project paths are also supported on tools that receive projectRoot
• The runnable project must never be initialized in the template root
• If a target project lives inside this template, it must live under ./www/

Transports

Supported transports:

• stdio
• Streamable HTTP

Entrypoints:

• stdio: packages/sdd-mcp/dist/index.js
• HTTP: http://127.0.0.1:3334/mcp

Tool reference

sdd_create_workspace

Purpose:

• create a managed runnable workspace under ./www/<project-name>/

When to use:

• when the user wants the recommended default workspace inside this template

Input:

• projectName
• assistant
• profile
• useSpecKit

What it does:

• creates the SDD base workspace
• optionally initializes Spec Kit

What the user should expect:

• a clean runnable project folder under ./www/
• no changes outside that managed workspace

Structured output:

• projectRoot
• profile
• assistant
• usedSpecKit

sdd_create_spec

Purpose:

• create the next numbered spec folder from the template bundle

When to use:

• when the target project already has the SDD base and needs a new feature spec

Input:

• projectRoot
• featureName
• owner

What it does:

• creates spec.md, plan.md, tasks.md, research.md, history.md
• creates contracts/README.md
• appends a row to specs/INDEX.md

Structured output:

• specId
• specDir
• indexUpdated

sdd_validate

Purpose:

• validate the SDD structure and required files of a target project

When to use:

• before closing a session
• before trusting a migrated or initialized project

Input:

• projectRoot

What it does:

• checks required folders
• checks required files
• checks numbered spec bundles

Structured output:

• ok
• errors
• warnings
• messages[]

sdd_check_gate

Purpose:

• decide whether implementation is allowed under SDD rules

When to use:

• immediately before implementation

Input:

• projectRoot

What it does:

• checks approval status
• checks plan consistency signals
• checks tasks presence
• checks consent log requirement when approved specs exist

Structured output:

• ok
• errors
• warnings
• approvedSpecs
• totalSpecs
• messages[]

sdd_record_user_consent

Purpose:

• record explicit user approval before implementation starts

When to use:

• only when implementation is actually about to begin

Input:

• projectRoot
• summary

What it does:

• appends a timestamped line to .sdd/user-consent.log

Structured output:

• logFile
• summary
• timestamp

sdd_list_specs

Purpose:

• list numbered specs and their status

When to use:

• to pick the active spec for a session

Input:

• projectRoot

What it does:

• reads numbered specs
• extracts approval status from spec.md

Structured output:

• specs[]
  • id
  • dir
  • status

sdd_generate_status

Purpose:

• build a project status dashboard

When to use:

• at session close
• before handoff

Input:

• projectRoot

What it does:

• creates or replaces STATUS.md
• summarizes active specs
• summarizes task progress
• includes recent project log excerpt

Structured output:

• path
• content

sdd_generate_roadmap

Purpose:

• generate a roadmap from specs/INDEX.md

When to use:

• when the user wants a visual and markdown roadmap

Input:

• projectRoot

What it does:

• creates or replaces docs/roadmap.mmd
• creates or replaces docs/roadmap.md

Structured output:

• mermaidPath
• markdownPath
• mermaid
• markdown

sdd_append_project_log

Purpose:

• append a global project log entry

When to use:

• to record high-level session changes

Input:

• projectRoot
• entry

What it does:

• appends content to bitacora/global/PROJECT_LOG.md

Structured output:

• path
• content

sdd_write_daily_log

Purpose:

• create or replace one daily log file

When to use:

• to store the session note for a date

Input:

• projectRoot
• date
• content

Rules:

• date must use YYYY-MM-DD

What it does:

• creates or replaces bitacora/diaria/YYYY-MM-DD.md

Structured output:

• path
• content

sdd_write_handoff

Purpose:

• create or replace a handoff file

When to use:

• when one session leaves a clear next step for another operator or agent

Input:

• projectRoot
• fileName
• content

Rules:

• fileName must be a simple markdown file name

What it does:

• creates or replaces bitacora/handoffs/<fileName>

Structured output:

• path
• content

sdd_write_decision

Purpose:

• create or replace a decision record

When to use:

• when the session makes an important project decision

Input:

• projectRoot
• fileName
• content

Rules:

• fileName must be a simple markdown file name

What it does:

• creates or replaces bitacora/decisiones/<fileName>

Structured output:

• path
• content

sdd_board_read

Purpose:

• read the visual SDD Builder board of a target project

When to use:

• when the AI needs the canvas layout plus every spec with status and task progress

Input:

• projectRoot

What it does:

• reads specs/board.canvas (JSON Canvas), generating a default layout if missing
• lists specs with approval status and done/total task counts

What the user should expect:

• the exact same view the /builder canvas renders

Structured output:

• canvas (nodes, edges)
• specs (id, dir, status, tasks)

sdd_board_write

Purpose:

• replace the board canvas layout

When to use:

• when the AI arranges or reorganizes cards and connections as a whole

Rules:

• only layout is stored; markdown files are never touched

What it does:

• validates and atomically writes specs/board.canvas

Input:

• projectRoot
• canvas

Structured output:

• ok
• nodes
• edges

sdd_board_connect

Purpose:

• connect two existing board cards with an optional labeled edge

When to use:

• when the AI records a dependency or relation between cards

Rules:

• both node ids must exist on the board
• identical edges are not duplicated (idempotent)

Input:

• projectRoot
• fromNode
• toNode
• label

Structured output:

• canvas

sdd_read_tasks

Purpose:

• read the checkbox tasks of one spec’s tasks.md

When to use:

• before toggling a task, to get line numbers and done state

Input:

• projectRoot
• specId

Structured output:

• specId
• tasks (text, done, line)

sdd_set_task_done

Purpose:

• toggle one checkbox line in a spec’s tasks.md

When to use:

• when a task is completed or reopened during a session

Rules:

• surgical edit of the single - [ ] / - [x] line, atomic write
• line comes from sdd_read_tasks

Input:

• projectRoot
• specId
• line
• done

Structured output:

• specId
• tasks

sdd_gate_summary

Purpose:

• one-call gate semaphore: the gate check plus the structural validation, with every message grouped by the spec it belongs to

When to use:

• when you want the whole workspace status in a single call (this is the data behind the SDD Builder gate chip and the per-card badges)

Rules:

• same sdd-core layer as the /api/gate REST route — no second copy of the rule
• dependencyWarnings are advisory only (an approved spec depending on a not-approved one), never gate errors

Input:

• projectRoot

Structured output:

• ok
• errors, warnings (counts)
• messages grouped by spec
• dependencyWarnings

sdd_approve_spec

Purpose:

• surgically fill the existing approval block of a spec.md

When to use:

• when the human decision maker has approved the spec and you must leave the evidence on disk before implementation

Rules:

• writes Estado -> Aprobado, approval date -> today, approver -> the given name
• evidence always wins when provided; without it, an existing evidence line is never overwritten
• fails with a clear bilingual error when the ## Estado de aprobación / Approval status block is missing — copy the block from specs/_template/spec.md first
• the tool records the decision, it does not make it: approval is always a human act

Input:

• projectRoot
• specId
• approver
• evidence (optional)

Structured output:

• specId
• status
• approvalDate
• approver
• evidenceUpdated
• fieldsUpdated

sdd_update_spec_sections

Purpose:

• replace only the content under the guided-editor headings of a spec.md, preserving everything else

When to use:

• when filling or refining a spec from a guided editor or from the conversation, without rewriting the whole file

Rules:

• surgical, atomic, serialized read-modify-write: two concurrent saves queue instead of clobbering each other
• the approval block is always preserved
• tolerant to the EN/ES headings of the repo template; a heading the file does not have is appended at the end with its canonical bilingual title and reported in created

Input:

• projectRoot
• specId
• story (optional, free text)
• scenarios, criteria, requirements, properties, successCriteria (optional, lists)
• outOfScope (optional, free text)

Structured output:

• specId
• updated (sections replaced in place)
• created (sections appended because the file lacked them)

sdd_read_spec_document

Purpose:

• read one document of a spec bundle (spec.md, plan.md, tasks.md, research.md or history.md) as raw markdown

When to use:

• when the agent is connected over HTTP/Desk (no filesystem) and needs the actual spec content — the read counterpart of sdd_approve_spec and sdd_update_spec_sections

Input:

• projectRoot
• specId
• document (one of the five bundle documents)

Structured output:

• specId, document, content

sdd_read_bitacora

Purpose:

• read the logbook: without fileName it lists the .md files of one folder (handoffs, decisiones, diaria, global); with fileName it returns that file’s content

When to use:

• when resuming a session (read the latest handoff — the list comes sorted, the last one is the newest) or reviewing prior decisions

Rules:

• fileName must be a plain .md basename (no path separators); any traversal attempt fails with a clear error

Input:

• projectRoot
• kind (handoffs | decisiones | diaria | global)
• fileName (optional)

Structured output:

• kind, files, and with fileName: content

sdd_check_drift

Purpose:

• answer whether the code a spec governs changed AFTER its approval date (drift semaphore, spec 025)

When to use:

• before touching code governed by an approved spec, or when auditing project state

Rules:

• states: clean, drifted (with the offending commits), unscoped (no File scope declared), unknown (not approved / no git)
• the same computeSpecDrift rule the board and dashboard use — it never fakes a clean

Input:

• projectRoot
• specId (optional; omitted, it reports every spec)

Structured output:

• reports (specId, status, drift)

sdd_add_task

Purpose:

• append one unchecked task (- [ ] text) to a spec’s tasks.md

When to use:

• during planning, when new work shows up that must live in the spec

Rules:

• the task lands right after the last checkbox (or at the end when there is none); atomic write, same primitive as sdd_set_task_done

Input:

• projectRoot
• specId
• text (single line, without the checkbox)

Structured output:

• specId, updated tasks with line numbers

sdd_lint_ears

Purpose:

• lint acceptance criteria against the EARS skeleton (WHEN/IF/WHILE … THE SYSTEM SHALL …) plus vague words without a measurable number

When to use:

• while drafting criteria, before saving them with sdd_update_spec_sections

Rules:

• pure (no filesystem) and advisory: results are suggestions, never blockers
• the same validateEarsCriterion the Builder uses

Input:

• criteria (list of lines)

Structured output:

• results (criterion, level, matchesPattern, vagueWords, hints)

sdd_score_spec

Purpose:

• score a spec bundle 0-100 with a grade (A/B/C/D) and improvement notes

When to use:

• to judge whether a spec is ready before asking for approval

Rules:

• same heuristics as scripts/score-spec.sh (files present, spec sections, plan signals, task breakdown, research rationale, dated history)

Input:

• projectRoot
• specId (optional; omitted, it scores every spec)

Structured output:

• scores (specId, score, grade, notes)

sdd_install_sidecar

Purpose:

• install the compact spec/ sidecar into an EXISTING external project (the recommended layout for real projects outside this template)

When to use:

• as the first step to adopt SDD in an existing project from Desk or npx, with no bash and no template clone

Rules:

• delegates to scripts/install-spec-sidecar.sh (the production-tested installer); refuses the template root like every tool
• after it runs, every other tool works against that projectRoot

Input:

• targetPath (existing directory)
• profile (minimal | recommended)

Structured output:

• projectRoot, sddRoot, profile

sdd_check_policy

Purpose:

• run the multi-agent policy check (sdd.policy.yaml blocks, agent rule files aligned with the canonical operating system) without running the full gate

When to use:

• when you only need to know whether the policy is healthy, not the approval verdict of every spec

Rules:

• same messages and codes as scripts/check-sdd-policy.sh
• the gate already embeds this check; this tool answers it on its own
• returns isError when the policy fails

Input:

• projectRoot

Structured output:

• ok, errors, warnings, messages

sdd_legacy_discovery

Purpose:

• scan an existing codebase for route/API and user-flow signals and write analysis/legacy-discovery/ (evidence files + a report with suggested first specs)

When to use:

• as the entry point for adapting a project that already has code (Case 2 in the guides), right after sdd_install_sidecar

Rules:

• TypeScript port of scripts/legacy-discovery.sh: no bash and no ripgrep needed
• heuristic parity with the script, not byte parity
• only writes inside analysis/legacy-discovery/; never touches project code

Input:

• projectRoot

Structured output:

• target, outDir, routeSignals, flowSignals, suggestedSpecs, reportPath, routesFile, flowsFile

sdd_write_spec_document

Purpose:

• write the FULL content of one bundle document (spec.md, plan.md, tasks.md, research.md or history.md), atomically

When to use:

• when you generate a whole document at once; to edit parts of spec.md, prefer sdd_update_spec_sections

Rules:

• the low-level counterpart of sdd_read_spec_document
• five-document whitelist: any other name fails without touching the filesystem
• it overwrites whatever was there: this is a full write, not a merge

Input:

• projectRoot, specId, document, content

Structured output:

• specId, document, bytes

sdd_rename_task

Purpose:

• replace the text of one task line in tasks.md, preserving its indentation and done mark

When to use:

• when a task changes wording without changing position or state

Rules:

• atomic write, same primitive as sdd_set_task_done
• the rest of the file survives byte for byte
• an out-of-range line fails loudly

Input:

• projectRoot, specId, line (zero-based, as returned by sdd_read_tasks), text

Structured output:

• specId, tasks (updated list with line numbers)

sdd_remove_task

Purpose:

• delete one task line from tasks.md

When to use:

• when a task stops making sense and ticking it is not enough

Rules:

• only that line disappears; every other line survives byte for byte
• atomic write; an out-of-range line fails loudly

Input:

• projectRoot, specId, line

Structured output:

• specId, tasks

sdd_move_task

Purpose:

• swap one task with the nearest task above or below it in tasks.md

When to use:

• to reorder work without rewriting the whole file

Rules:

• skips non-task lines (headings, notes): it moves task against task
• “move to the end” is repeated down
• atomic write

Input:

• projectRoot, specId, line, direction (up | down)

Structured output:

• specId, tasks

sdd_update_spec_status

Purpose:

• update the status, priority and/or owner cells of ONE spec’s row in specs/INDEX.md (and refresh its updated date)

When to use:

• when a spec changes state and until now that meant editing the table by hand

Rules:

• the only write INDEX accepts besides appending a new row
• match anchored to the spec number: exactly one line changes and no neighbouring row moves
• fails when the spec has no row

Input:

• projectRoot, specId, status (optional), priority (optional), owner (optional)

Structured output:

• the updated index row

sdd_board_app

Purpose:

• show the visual SDD board inside the client as an MCP App (SEP-1865, official ext-apps extension)

When to use:

• when the user wants to see the board (cards, connections, gate semaphore, dependency warnings) without leaving the chat

Rules:

• read-only view; linked to the ui://sdd/board.html resource via _meta.ui.resourceUri (text/html;profile=mcp-app)
• hosts without MCP Apps support still get the full board + gate data as JSON text
• a closed gate is data for the view, never a tool error

Input:

• projectRoot

Structured output:

• projectRoot
• board (canvas + specs, same shape as sdd_board_read)
• gate (same shape as sdd_gate_summary)

sdd_check_version

Purpose:

• compare an installed sidecar against this server’s version WITHOUT writing anything (spec 029)

When to use it:

• before any upgrade, and whenever the user asks “am I up to date?”

Rules:

• upToDate is false when file contents differ even if the version number matches: a tampered gate has survived a reinstall before (spec 021)
• a missing .sdd/TEMPLATE_VERSION is reported as unknown, never as current

Input:

• projectRoot

Structured output:

• templateVersion, packageVersion, profile, upToDate
• files, staleFramework, divergedPreserved, missing

sdd_upgrade

Purpose:

• bring an installed sidecar up to this server’s version (spec 029)

When to use it:

• after sdd_check_version, once the user has seen what would change

Rules:

• framework-owned files (the gate, validators, root resolver) are repaired without asking
• files the user owns (sdd.policy.yaml, specs/_template/*, logbook templates) are NEVER written unless named in applyPreserved
• call it with dryRun: true first and show the result to the user; an already-current sidecar performs zero writes

Input:

• projectRoot, dryRun (optional), applyPreserved (optional array of target paths)

Structured output:

• sidecarRoot, fromVersion, toVersion, alreadyCurrent, files, pending, markerUpdated

sdd_next_request

Purpose:

• claim the oldest AI-assist request published by the SDD Builder (pending → in_progress) with its full context: target field, current text and the user’s instruction (spec 031)

When to use it:

• when the operator asks you to serve the builder queue (“listen to the board”, typically in a loop with /loop)

Rules:

• an empty queue returns { request: null }, never an error; the poll itself records your presence, which the builder shows as “agent connected”
• requests cancelled by the user are never delivered
• never write spec files as an answer: reply with sdd_respond_request

Input:

• projectRoot, agent (optional, display name shown in the builder)

Structured output:

• request (id, type draft-field | structure-idea, target, currentText, instruction, status, dates) or null

sdd_respond_request

Purpose:

• attach your proposal to a claimed request (in_progress → answered)

When to use it:

• right after drafting the proposal for the request you claimed

Rules:

• the proposal is NOT written to any file: the user reviews it as a diff in the builder and only their acceptance writes, through the existing section/task routes
• answering a cancelled request fails with a clear error: drop it and claim the next one

Input:

• projectRoot, id, proposal

Structured output:

• request (the request, now answered)

Resource reference

Static resources

sdd-policy

• reads the current framework policy
• use when the AI needs the hard rules first

sdd-ai-start

• reads the fast AI onboarding guide
• use when the operator is starting from zero

sdd-easy-mcp-guide

• reads the friendly non-technical MCP guide
• use when the operator wants the easiest possible explanation first

sdd-quickstart

• reads the short quickstart guide
• use when the operator needs the shortest possible route

sdd-spec-template

• reads the base spec.md template
• use when the AI needs to understand the expected structure of a feature spec

Managed-workspace resource templates

These resource templates are for managed projects under ./www/<project-name>/.

sdd-project-index

• returns specs/INDEX.md
• expect the top-level snapshot of project specs

sdd-project-log

• returns bitacora/global/PROJECT_LOG.md
• expect the global project log

sdd-project-latest-handoff

• returns the latest file in bitacora/handoffs/
• expect the most recent handoff, if any

sdd-project-idea

• returns idea/IDEA_GENERAL.md
• expect the project intent and scope

sdd-spec-document

• returns a specific spec document by id and file name
• supported documents:
  • spec.md
  • plan.md
  • tasks.md
  • research.md
  • history.md

Resource URIs / URIs de recursos

Read a resource with resources/read using its exact URI. Static resources:

URI	What it returns
sdd://policy/current	sdd.policy.yaml — the machine-readable policy
sdd://docs/quickstart	QUICKSTART.md
sdd://docs/ai-start	AI_START_HERE.md
sdd://docs/easy-mcp	The easy MCP guide (43)
sdd://templates/spec	The spec template used by sdd_create_spec

Per-project templates — substitute {projectName} with the workspace name, and {specId} / {document} (spec.md, plan.md, tasks.md, research.md, history.md):

URI template
sdd://project/{projectName}/index
sdd://project/{projectName}/idea
sdd://project/{projectName}/project-log
sdd://project/{projectName}/latest-handoff
sdd://project/{projectName}/specs/{specId}/{document}

REST routes (SDD Builder) / Rutas REST del builder

The HTTP transport also serves the builder’s own API on the same port. It is loopback-only and rejects cross-origin mutations — see the security notes in guide 51.

Method	Route	Purpose
GET	/api/board	Canvas plus every spec with status and task progress
PUT	/api/board	Persist the canvas layout (specs/board.canvas)
GET	/api/gate	Gate summary, per-spec issues and dependency warnings
GET	/api/events	SSE stream of workspace changes (live sync)
POST	/api/spec	Create a real spec bundle
GET	/api/spec/:id	One spec: documents and parsed tasks
PUT	/api/spec/:id/tasks	Toggle a task checkbox in tasks.md
PUT	/api/spec/:id/sections	Rewrite spec.md sections (surgical)
POST	/api/spec/:id/approve	Fill the approval block
POST	/api/spec/:id/issues	Create GitHub issues for pending tasks (needs gh)
POST	/api/spec/:id/tasks	Add a task to tasks.md ({ text })
GET	/api/spec/:id/score	0-100 score with grade and notes (the same scoreSpec the MCP serves)
GET	/api/bitacora/:kind	List a logbook folder; with ?file= read one entry
POST	/api/bitacora/:kind	Write one entry: decisiones/handoffs ({ fileName, content }), diaria ({ date, content }), global ({ entry })
POST	/api/status	Regenerate STATUS.md
POST	/api/roadmap	Regenerate docs/roadmap.md
POST	/api/spec/:id/consent	Record consent for that spec ({ summary }) — the third gate condition
GET	/api/version	Installed sidecar version vs. this server, plus which files diverged (spec 029)
GET	/api/connect	The agent-client catalogue: per-client config file, snippet and serve hint (spec 032)
GET	/api/requests	The builder’s AI request queue plus the agent’s last-seen presence (spec 031)
POST	/api/request	Publish an AI request for the connected agent ({ type, instruction, target?, currentText? })
POST	/api/request/:id/resolve	Close a request: { resolution: 'accepted' | 'rejected' | 'cancelled' } — only accepted writes
GET	/builder	The visual board (also /builder/* assets)
GET	/dashboard	The read-only status page

Prompt reference

start_new_sdd_project

• use when the user wants to start a new project from this framework
• expects the AI to create the SDD base first and defer implementation until the gate is met

easy_start_project

• use when the user wants a child-friendly guided project start
• expects the AI to explain the action, touched files, expected result, and next step

easy_create_spec

• use when the user says something like /create-spec payments
• expects the AI to create the spec package and explain the result in simple language

easy_show_structure

• use when the user feels lost and needs the folder map explained simply
• expects the AI to describe the project structure like a basic map

easy_validate_project

• use when the user wants validation and gate status in simple language
• expects the AI to translate warnings and errors into one clear next step

easy_show_next_step

• use when the user wants the next safe SDD action without jargon
• expects the AI to choose one exact next step

adapt_existing_project_to_sdd

• use when the user already has a project and wants to add SDD structure
• expects the AI to preserve current behavior and add traceability

close_sdd_session

• use when ending a session
• expects a summary with objective, changes, validation, risks, and next step

easy_close_session

• use when ending a session for a non-technical user
• expects the AI to summarize in simple language and leave one exact next step

sdd_serve_requests

• delivers the SDD Builder queue-serving loop: sdd_next_request → draft a proposal → sdd_respond_request → repeat (spec 032)
• optional projectRoot argument
• in clients that surface MCP prompts as slash commands (Claude Code, VS Code) this is the zero-install path; elsewhere the same instructions arrive as the /sdd-serve skill (see guide 51)
• carries the hard rule: the agent proposes, it never writes files under specs/

Recommended user flow

flowchart LR
  A["Connect MCP"] --> B["Read policy + quickstart"]
  B --> C["Create SDD base"]
  C --> D["Create first spec"]
  D --> E["Validate"]
  E --> F["Check gate"]
  F --> G["Record consent"]
  G --> H["Implement"]
  H --> I["Write logs and handoff"]

1. Connect the MCP server.
2. Read sdd-policy and sdd-quickstart.
3. Create the SDD base with sdd_create_workspace or external bootstrap scripts.
4. Create the first spec with sdd_create_spec.
5. Validate with sdd_validate.
6. Before implementation, run sdd_check_gate.
7. If approved, record consent with sdd_record_user_consent.
8. Close the session with status, logs, and handoff tools as needed.

In short

The server exists to make an AI client predictable on your project: the same files in the same places, traceability that survives between sessions, and a hard stop when the documentation is not ready for code yet.