Sdd MCP server

Read from the package source without running it. The installed server may list more.

• sdd_add_task

  Append one unchecked task (- [ ] text) to a spec's tasks.md, right after the last existing checkbox (atomic write, same primitive as sdd_set_task_done), and return the updated task list with line numbers.

• sdd_append_project_log

  Append content to bitacora/global/PROJECT_LOG.md.

• sdd_approve_spec

  Surgically fill the existing approval block of a spec.md: Estado -> Aprobado, approval date -> today, approver -> given name, evidence when provided (always wins) or when the line is empty. Fails clearly when the block is missing.

• sdd_board_connect

  Connect two existing board cards with an optional labeled edge and persist specs/board.canvas. Idempotent for identical edges.

• sdd_board_read

  Read the visual SDD Builder board: the specs/board.canvas layout (JSON Canvas) plus every spec with its approval status and task progress.

• sdd_board_writewrite action

  Replace the specs/board.canvas layout (JSON Canvas: nodes + edges). Only layout is stored; markdown files are never touched by this tool.

• sdd_check_drift

  Spec↔code drift (spec 025) as a direct answer: did the code a spec governs change AFTER its approval date? One spec (specId) or every spec (omitted). States: clean, drifted (with offending commits), unscoped (no File scope declared), unknown (not approved / no git). Same computeSpecDrift rule the board and dashboard use.

• sdd_check_gate

  Verify whether implementation can proceed under SDD rules.

• sdd_check_policywrite action

  Run the multi-agent policy check (sdd.policy.yaml blocks, agent rule files aligned with the canonical operating system) WITHOUT running the full gate. Paired with scripts/check-sdd-policy.sh: same messages, same codes. The gate embeds this check; this tool answers it on its own.

• sdd_check_version

  Compare an installed sidecar against this server's version WITHOUT writing anything: which files the framework would repair, which user-owned files diverged from the new reference, and which are missing. `upToDate` is false when content differs even if the version number matches — a tampered gate has survived a reinstall before.

• sdd_create_specwrite action

  Create the next numbered spec folder from the template.

• sdd_create_workspacewrite action

  Create a runnable SDD workspace inside the recommended default folder ./www/<project-name>.

• sdd_gate_summary

  One-call gate semaphore: runs the SDD gate check plus the structural validation and groups every message by the spec it belongs to (the same data the SDD Builder chip and per-card badges show). Includes advisory dependencyWarnings from the board's typed edges (approved spec depending on a not-approved one).

• sdd_generate_roadmap

  Generate docs/roadmap.mmd and docs/roadmap.md from specs/INDEX.md.

• sdd_generate_status

  Generate STATUS.md from the current project specs and logbook.

• sdd_install_sidecar

  Install the compact spec/ sidecar into an EXISTING external project directory (the recommended layout for real projects outside this template), via scripts/install-spec-sidecar.sh. After this, every other tool works against that projectRoot. Refuses the template root, like every tool here.

• sdd_legacy_discovery

  Scan an existing codebase for route/API and user-flow signals and write analysis/legacy-discovery/ (evidence files + report with suggested first specs). TypeScript port of scripts/legacy-discovery.sh — no bash, no ripgrep needed. The entry point for adapting a project that already has code (Case 2 of the guides).

• sdd_lint_ears

  Lint acceptance criteria against the EARS skeleton (CUANDO/SI/MIENTRAS … EL SISTEMA DEBERÁ … / WHEN/IF/WHILE … THE SYSTEM SHALL …) plus vague-word checks. Pure and advisory — the same validateEarsCriterion the Builder uses; results are suggestions, never blockers. No filesystem access.

• sdd_list_specs

  List numbered specs and their approval status.

• sdd_move_task

  Swap one task with the nearest task above/below it in tasks.md, skipping non-task lines (atomic write). 'Move to the end' is repeated 'down'. Returns the updated task list with line numbers.

• sdd_next_request

  Claim the oldest pending AI-assist request published by the SDD Builder (pending -> in_progress) and return it with its full context: target field, its current text, and the user's instruction. Returns { request: null } when the queue is empty — polling also records agent presence, which is what the builder shows as 'agent connected'. Answer with sdd_respond_request; never write the spec files you

• sdd_read_bitacora

  Read the project logbook: without fileName, list the markdown files of one bitácora folder (handoffs, decisiones, diaria, global — sorted, so the last one is the latest); with fileName, return that file's content. The read counterpart of sdd_write_handoff/sdd_write_decision/sdd_write_daily_log/sdd_append_project_log.

• sdd_read_spec_document

  Read one document of a numbered spec bundle (spec.md, plan.md, tasks.md, research.md or history.md) as raw markdown. The read counterpart of sdd_approve_spec/sdd_update_spec_sections, for agents without filesystem access (HTTP/Desk).

• sdd_read_tasks

  Read the checkbox tasks of a spec's tasks.md with their line numbers and done state.

• sdd_record_user_consent

  Record explicit user consent before implementation starts. Pass specId so the consent is bound to that spec; without it the entry is a legacy, markerless line that only covers specs approved before it.

• sdd_remove_taskwrite action

  Delete one task checkbox line from tasks.md; every other line survives byte for byte (atomic write). Returns the updated task list with line numbers.

• sdd_rename_task

  Replace the text of one task checkbox line in tasks.md, preserving its indentation and done mark (atomic write, same primitive as sdd_set_task_done). Returns the updated task list with line numbers.

• sdd_respond_request

  Attach a proposal to a claimed AI-assist request (in_progress -> answered). The proposal is plain text for the target field; for structure-idea and review-spec requests it is exactly the JSON the instruction asks for, with no markdown around it. A review-spec answer is a list of findings anchored to the spec sections — findings, never a rewritten spec. It is NOT written to any spec file: the user

• sdd_score_spec

  Score a spec bundle 0-100 with grade (A/B/C/D) and improvement notes: required files present, spec sections, plan signals (milestones/dependencies/risks), task breakdown, research rationale, dated history. One spec (specId) or every spec (omitted). Heuristics-parity port of scripts/score-spec.sh.

• sdd_set_task_done

  Toggle one checkbox line in a spec's tasks.md (surgical edit, atomic write) and return the updated tasks.

• sdd_update_spec_sectionswrite action

  Replace ONLY the content under the guided-editor headings of a spec.md (user story, acceptance scenarios, EARS criteria, requirements, spec properties, success criteria, out of scope — the full template) preserving everything else, the approval block included. Tolerant to the EN/ES headings of the canonical repo template (specs/_template/spec.md).

• sdd_update_spec_statuswrite action

  Update the status, priority and/or owner cells of ONE spec's row in specs/INDEX.md (and refresh its updated date). The only write INDEX accepts besides appending a new row — until now a status change meant editing the table by hand. Fails when the spec has no row.

• sdd_upgrade

  Bring an installed SDD sidecar up to the version of this server. Framework-owned files (the gate, validators, root resolver) are repaired; files the user owns (sdd.policy.yaml, specs/_template/*, logbook templates) are NEVER written unless named in applyPreserved. Call with dryRun: true first — it reports what would change and writes nothing. An already-current sidecar performs zero writes.

• sdd_validate

  Validate the SDD structure and required files of a project.

• sdd_write_daily_logwrite action

  Create or replace a daily log entry in bitacora/diaria.

• sdd_write_decisionwrite action

  Create or replace a decision file in bitacora/decisiones.

• sdd_write_handoffwrite action

  Create or replace a handoff file in bitacora/handoffs.

• sdd_write_spec_documentwrite action

  Write the FULL content of one spec bundle document (spec.md, plan.md, tasks.md, research.md or history.md), atomically. The low-level counterpart of sdd_read_spec_document; prefer sdd_update_spec_sections for structured edits of spec.md. Any name outside the five fails without touching the filesystem.

• Code scan40 source files scanned25/25
• –Live reliabilityno gateway calls yet and no remote to proben/a
• –Tool poisoningtools not inspected (local package is not executed); not countedn/a
• Auth qualitylocal package, no credentials required12/15
• Maintenancelast push 62 days ago12/15
• Maintainer identityregistry namespace matches repository owner; GitHub account older than a year8/10

Safety score

88/100

higher than 75% of 48,255 servers

Tools

38

the typical server has 7

Tools that change things

29%

typical: 0%. Fewer write tools means less an agent can break

GitHub stars

21

more than 91% of 28,688 servers

Downloads a week

108

more than 65% of 12,191 servers with a package

Sdd: common questions

Is Sdd MCP server safe?

Yes, by our scan: it is graded A (88/100). Read the Sdd safety report

How do I install Sdd?

It runs on your machine. Copy the Claude Code, Cursor, VS Code or Claude Desktop config from the install section.

Does Sdd need an API key?

No secret keys are declared. It reads 2 settings from the environment.

Is Sdd maintained?

The last commit was 66 days ago (2026-08-30). The latest release is v2.8.0.

How does Sdd compare with other MCP servers?

safety score 88/100 (higher than 75% of 48,255 servers); tools 38 (the typical server has 7); tools that change things 29% (typical: 0%. Fewer write tools means less an agent can break). Full comparison.