# Compose MCP (npm · @smartmemory/compose-mcp)

Typed feature management for compose projects: roadmap, changelog, artifacts, journal.

- Trust score: 28/100 (low)
- Change this week: −37
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-09-27

## Components

- npm · `@smartmemory/compose-mcp`: 28/100 (this document), [markdown](https://verifymcp.io/servers/ai-smartmemory-compose-mcp/smartmemory-compose-mcp.md), [page](https://verifymcp.io/servers/ai-smartmemory-compose-mcp/smartmemory-compose-mcp)

## Channel facts

- Registry: `npm`
- Package: `@smartmemory/compose-mcp`
- Version: `0.7.1`
- Transport: `stdio`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-09-27.

- **Supply Chain Security**: 88/100
  - No malware found by supply-chain analysis.
  - Known CVEs were checked across the 400 of 585 dependencies we could resolve, so this covers what we could see, not the whole tree.
  - No install/post-install scripts declared.
  - Dependency health was assessed across the 400 of 585 dependencies we could resolve, so this covers what we could see, not the whole tree.
- **Provenance & Transparency**: 6/100
  - Repository check failed: no source repository is declared.
  - Provenance check failed: no build-provenance attestation is published.
  - License check failed: the license (BUSL-1.1) isn't a recognized OSI-approved license.
  - Actively maintained (last published 0 days ago).
  - Disclosure check failed: no security disclosure policy was found in the source repository.
- **Schema Quality & AI Usability**: 0/100
  - Schema quality not yet verified: we do not have a sandbox capture of the MCP schema this version of the package serves yet.
- **Stability & Change Management**: 0/100
  - Stability not yet verified: we do not have a sandbox capture of the MCP schema this version of the package serves yet.
- **Tool Coverage**: 0/100
  - Tool coverage not yet verified: we do not have a sandbox capture of the tool definitions this version of the package serves yet.
- **Tool Safety**: 0/100
  - Tool safety not yet verified: we do not have a sandbox capture of the tool definitions this version of the package serves yet.
- **Capabilities**: 0/100
  - Protocol version not yet verified: we do not have a sandbox capture of the MCP handshake this version of the package performs yet.

**Unverified: 5 categories.** Categories scored 0 because our sandbox has not given us the schema these checks need to read. That is a gap on our side rather than a finding about the package, and we only credit what we can confirm, so the score stands at 0 until the capture succeeds. We are working through the fleet, so this normally clears without any action from you.

## Install

### How do I install the Compose MCP server?

Compose MCP runs locally as an npm package, launched with npx -y @smartmemory/compose-mcp. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add ai-smartmemory-compose-mcp -- npx -y @smartmemory/compose-mcp
```

### Cursor

```json
{
  "mcpServers": {
    "ai-smartmemory-compose-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "@smartmemory/compose-mcp"
      ]
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "ai-smartmemory-compose-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "@smartmemory/compose-mcp"
      ]
    }
  }
}
```

### Codex

```bash
codex mcp add ai-smartmemory-compose-mcp -- npx -y @smartmemory/compose-mcp
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "ai-smartmemory-compose-mcp": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "@smartmemory/compose-mcp"
      ],
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add ai-smartmemory-compose-mcp --command npx --arg -y --arg @smartmemory/compose-mcp
```

### Hermes

```yaml
mcp_servers:
  ai-smartmemory-compose-mcp:
    command: "npx"
    args: ["-y", "@smartmemory/compose-mcp"]
```

### Netclaw

```json
{
  "McpServers": {
    "ai-smartmemory-compose-mcp": {
      "Transport": "stdio",
      "Command": "npx",
      "Arguments": [
        "-y",
        "@smartmemory/compose-mcp"
      ]
    }
  }
}
```

### Vellum

```bash
assistant mcp add ai-smartmemory-compose-mcp -t stdio -c npx -a -y @smartmemory/compose-mcp
```

### Other

```json
{
  "mcpServers": {
    "ai-smartmemory-compose-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "@smartmemory/compose-mcp"
      ]
    }
  }
}
```

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-09-27 (score 28, −29)

- [security regression] Stability: fail → unverified
- [security regression] Tool safety: pass → unverified
- [security improvement] Known CVEs: unverified → partial
- [functional regression] Capabilities: pass → unverified
- [functional regression] Tool coverage: 100 → unverified
- [functional improvement] Dependency health: unverified → partial
- [functional] Package version: 0.7.0 → 0.7.1

### 2026-09-26 (score 57, +37)

- [security regression] Stability: unverified → fail
- [security improvement] Injection markers: unverified → pass
- [security improvement] Known CVEs: unverified → partial
- [functional improvement] Tool coverage: unverified → 100
- [functional improvement] Dependency health: unverified → partial
- [functional improvement] MCP protocol: unverified → pass
- [functional] Package version: 0.6.5 → 0.7.0

### 2026-09-25 (score 20, −31)

- [security regression] Known CVEs: partial → unverified
- [security regression] Stability: fail → unverified
- [security regression] Tool safety: pass → unverified
- [security improvement] Malware scan: unverified → pass
- [functional regression] Capabilities: pass → unverified
- [functional regression] Tool coverage: 100 → unverified
- [functional regression] Dependency health: partial → unverified
- [functional regression] License: pass → fail
- [functional] First check of Schema quality: unverified
- [functional] Licence: MIT → BUSL-1.1
- [functional] Package version: 0.6.3 → 0.6.5
- [functional] Package version: 0.6.3 → 0.6.4
- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-09-24 (score 51, −15)

- [security regression] Malware scan: pass → unverified
- [security regression] Stability: 0.57 → fail
- [functional] Package version: 0.4.1 → 0.6.3

### 2026-09-22 (score 66, +1)

- [functional regression] Security disclosure: unverified → fail

### 2026-09-20 (score 65, +1)

No change was recorded against any check on this day. Stability & Change Management went from 43 to 47. That category is still filling its 30-day observation window: 13 days of observed history at the previous scan, 14 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-18 (score 64, +1)

No change was recorded against any check on this day. Stability & Change Management went from 37 to 40. That category is still filling its 30-day observation window: 11 days of observed history at the previous scan, 12 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-16 (score 63, +1)

No change was recorded against any check on this day. Stability & Change Management went from 30 to 33. That category is still filling its 30-day observation window: 9 days of observed history at the previous scan, 10 at this one. The score rises as the window fills, whether or not the server changes.

## MCP tools (51)

### `get_vision_items` (~152 tokens)

Query Compose tracker items. Filter by phase, status, type, or keyword. Returns id, title, type, phase, status, confidence, description.

Input parameters:

- `keyword` (string): Search keyword matched against title and description
- `limit` (number): Max results to return (default 30)
- `phase` (string): Filter by phase: vision, requirements, design, planning, implementation, verification, release
- `status` (string): Filter by status (comma-separated for multiple): planned, in_progress, complete, blocked, parked, killed
- `type` (string): Filter by type: task, decision, evaluation, idea, spec, thread, artifact, question, feature, track

### `get_item_detail` (~39 tokens)

Get full detail for a single tracker item including all its connections.

Input parameters:

- `id` (string, required): Item ID (UUID) or semanticId/slug

### `get_phase_summary` (~59 tokens)

Get status and type distribution for a phase (or all phases). Useful for understanding overall project health.

Input parameters:

- `phase` (string): Phase to summarize: vision, requirements, design, planning, implementation, verification, release. Omit for all phases.

### `get_blocked_items` (~23 tokens)

List all tracker items that are blocked by non-complete items.

### `get_current_session` (~50 tokens)

Get the most recent session: tool count, items touched, error count, and recent Haiku summaries of what was accomplished.

Input parameters:

- `featureCode` (string): Optional: get context for a specific feature

### `bind_session` (~63 tokens)

Bind the current agent session to a lifecycle feature. Call once per session after creating/identifying the feature. Binding is one-shot — calling again on a bound session returns already_bound.

Input parameters:

- `featureCode` (string, required): The feature code (e.g., "gate-ui")

### `set_workspace` (~48 tokens)

Bind this MCP session to a workspace. Required when cwd contains multiple workspaces. Lives in process memory; lost on MCP restart.

Input parameters:

- `workspaceId` (string, required): Workspace ID (kebab-case)

### `get_workspace` (~21 tokens)

Get the current MCP workspace binding plus all candidates discovered from cwd.

### `get_feature_lifecycle` (~42 tokens)

Get the lifecycle state of a feature: current phase, phase history, artifacts, warnings.

Input parameters:

- `id` (string, required): Item ID (UUID) or slug

### `kill_feature` (~45 tokens)

Kill a feature from any phase. Records reason and sets status to killed.

Input parameters:

- `id` (string, required): Item ID
- `reason` (string, required): Why the feature is being killed

### `complete_feature` (~223 tokens)

Mark a feature as complete. Only callable from the ship phase. For a managed build-mode feature (one with a feature.json) this goes through the completion gate (COMP-COMPLETION-GATE): the commit is verified and tests attested when capabilities.guard is on, ONE guarded transition is ledgered, and the gate writes the completion record, feature.status COMPLETE, ROADMAP.md and the cockpit item. A refusal (bad evidence, KILLED feature, guard refused) returns 422 and writes nothing. commit_sha is required under the guard; with the guard off a commit-less completion records a no-commit completion. Fix/plan items and items with no feature.json transition as before.

Input parameters:

- `commit_sha` (string): Full 40-char commit SHA. Required to write a completion record.
- `files_changed` (array): Repo-relative paths committed in the SHA.
- `id` (string, required): Item ID
- `notes` (string): One-line note for the completion record.
- `tests_pass` (boolean): Defaults to true when commit_sha is provided.

### `start_iteration_loop` (~65 tokens)

Start a review or coverage iteration loop on a feature. Returns loop state.

Input parameters:

- `id` (string, required): Item ID or semanticId
- `loopType` (string, required): Type of iteration loop
- `maxIterations` (number): Override max iterations (optional, defaults from settings)

### `report_iteration_result` (~68 tokens)

Report one iteration result. Compose evaluates exit criteria and returns whether to continue.

Input parameters:

- `id` (string, required): Item ID or semanticId
- `result` (object, required): Iteration result. Review: {clean: bool, findings: []}, Coverage: {passing: bool, failures: []}

### `abort_iteration_loop` (~40 tokens)

Abort the current iteration loop early.

Input parameters:

- `id` (string, required): Item ID or semanticId
- `reason` (string): Why the loop was aborted

### `assess_feature_artifacts` (~47 tokens)

Assess quality signals for all artifacts of a feature: section completeness, word count, last modified.

Input parameters:

- `featureCode` (string, required): Feature folder name (e.g. "artifact-awareness")

### `scaffold_feature` (~65 tokens)

Create feature folder with template stubs for all phase artifacts. Existing files are never overwritten.

Input parameters:

- `featureCode` (string, required): Feature folder name
- `only` (array): Limit to specific artifacts (e.g. ["design.md", "blueprint.md"]). Omit for all.

### `approve_gate` (~62 tokens)

Resolve a pending policy gate. Outcomes: approved (proceed), revised (stay in phase), killed (abandon feature).

Input parameters:

- `comment` (string): Optional human feedback
- `gateId` (string, required): Gate ID
- `outcome` (string, required): Resolution outcome

### `get_pending_gates` (~39 tokens)

List pending policy gates. Optionally filter by item ID.

Input parameters:

- `itemId` (string): Filter to gates for a specific item (optional)

### `add_roadmap_entry` (~355 tokens)

Register a new feature in the project. Writes feature.json and regenerates ROADMAP.md (audit-log append is best-effort). Use this instead of editing ROADMAP.md by hand.

Input parameters:

- `code` (string, required): Unique feature code (e.g. "COMP-FOO-1"). Must be uppercase A-Z, digits, dashes; cannot start or end with a dash.
- `complexity` (string)
- `description` (string, required): One-line description for the ROADMAP cell
- `force` (boolean): Bypass the pre-commit roundtrip guard (commit even if ROADMAP.md would not be a generation fixed point).
- `idempotency_key` (string): Optional caller-provided key. Same key replays return the cached result without re-mutating.
- `impact` (string): Estimated impact, carried from the plan/ideabox estimation step.
- `parent` (string): Parent feature code, for cross-references
- `phase` (string, required): Phase heading (e.g. "Phase 6: MCP Writers"). Required.
- `plannedBy` (string): Originating plan session code (e.g. "PLAN-WIDGET"). Marks a plan-authored, build-ready feature.
- `position` (number): Sort order within phase
- `profile` (object): Triage build profile (needs_prd/needs_architecture/etc.). Set by the plan lifecycle so build can skip fresh triage.
- `status` (string): Initial status (default PLANNED)
- `tags` (array)
- `triageTimestamp` (string): Triage cache stamp (ISO 8601). Set AFTER design.md is written so build treats triage as a cached no-op.

### `set_feature_status` (~135 tokens)

Flip a feature status. Updates feature.json and regenerates ROADMAP.md. Enforces a transition policy (use force: true to bypass). Appends an audit event (best-effort).

Input parameters:

- `code` (string, required)
- `commit_sha` (string): Optional commit binding
- `force` (boolean): Bypass the transition policy AND the roundtrip fixed-point guard (commits even if ROADMAP.md would not be a generation fixed point). Recorded in audit.
- `idempotency_key` (string)
- `reason` (string): Free-form reason persisted in the audit event
- `status` (string, required)

### `roadmap_diff` (~90 tokens)

Read the feature-management audit log for a window. Returns events plus derived added[] and status_changed[] arrays.

Input parameters:

- `feature_code` (string)
- `since` (string): Window: shorthand like "24h"/"7d"/"30m", or an ISO date. Default 24h.
- `tool` (string): Filter to one tool name, e.g. "set_feature_status"

### `get_roadmap` (~302 tokens)

Read the current roadmap rendered from canon (feature.json) WITHOUT writing. Returns a status summary, the active/blocked convenience lists, and a staleness flag vs on-disk ROADMAP.md. Pass a status/phase filter or a limit to also get a general `rows` list (e.g. {status:"PLANNED", limit:10} for "what to work on next") — structured rows so callers never re-parse the markdown. Narrative-owned workspaces return the hand-authored file verbatim. Read-only — prefer this over reading ROADMAP.md directly.

Input parameters:

- `check_drift` (boolean): Compare the render against on-disk ROADMAP.md and set stale/drift (default true)
- `format` (string): "summary" (default — counts + lists, token-safe) or "markdown" (full rendered text)
- `limit` (integer): Cap on the general `rows` list (default 50). Supplying status/phase/limit emits rows[]/rowsTotal/rowsTruncated; without any of them rows is omitted (token-safe summary). A finite value is floored and…
- `phase` (string): Filter active/blocked + rows to a single phase (matched against phaseId)
- `status` (string): Filter active/blocked + rows by status (comma-separated): PLANNED, IN_PROGRESS, PARTIAL, BLOCKED, COMPLETE, …

### `validate_feature` (~145 tokens)

Cross-check a single feature against ROADMAP, vision-state, feature.json, folder contents, linked artifacts, and cross-references. Returns structured findings with severity (error/warning/info). FEATURE_NOT_FOUND emitted as a finding (not thrown) when the code matches strict regex but exists in no source.

Input parameters:

- `external_prefixes` (array): Code prefixes (e.g. ["STRAT-"]) treated as external; downgrades ORPHAN_FOLDER to info
- `feature_code` (string, required): Strict feature code, e.g. "COMP-MCP-VALIDATE"
- `feature_json_mode` (boolean): Default true. Set false to skip feature.json comparisons in legacy projects.

### `validate_project` (~263 tokens)

Run validate_feature for every code in vision-state, ROADMAP, and folders, plus cross-cutting checks (orphan folders, dangling cross-refs, CHANGELOG references, journal index drift) and read-only external-reference staleness (kind:"external" links + xref: roadmap citations). external:true enables network resolution of github refs (off by default — github refs then emit XREF_RESOLUTION_SKIPPED). Returns the union of all findings.

Input parameters:

- `apply` (boolean): With fix:true, write the fixes and re-validate. Default false (dry-run plan only).
- `external` (boolean): Resolve github external refs over the network (read-only). Default false: github refs degrade to XREF_RESOLUTION_SKIPPED.
- `external_prefixes` (array)
- `feature_json_mode` (boolean)
- `fix` (boolean): COMP-MCP-VALIDATE-2: reconcile mechanical drift. Returns a fix plan under `reconcile` (dry-run unless apply:true). Local-provider only.
- `fix_classes` (array): Override the enabled fix classes: dangling_link, invalid_link_kind, status_fj_vision, partial_age, roadmap_status_rewrite, invalid_link_kind_repair. Default: the non-destructive set.

### `roadmap_graph` (~143 tokens)

COMP-ROADMAP-GRAPH-1: generate a self-contained roadmap dependency-graph HTML from feature.json status/phase + per-feature deps.yaml edges + display frontmatter. Drops COMPLETE/SUPERSEDED/KILLED nodes; refuses (DANGLING_EDGE) when any edge points at an unknown feature. Deterministic/idempotent. Returns a small summary (path + counts + warnings), never the HTML body.

Input parameters:

- `out` (string): Output HTML path (relative to project root unless absolute). Default: compose.json#roadmap_graph.out or roadmap-graph.html.
- `project` (string): Project root path. Default: current workspace.

### `roadmap_graph_check` (~116 tokens)

COMP-ROADMAP-GRAPH-1: render the roadmap graph in-memory and diff against the on-disk HTML without writing. Returns { matches, exists, diffSummary, counts, warnings }. matches:false means the file is stale/missing — run roadmap_graph. Raises DANGLING_EDGE on a bad edge.

Input parameters:

- `out` (string): Output HTML path to compare against. Default: compose.json#roadmap_graph.out or roadmap-graph.html.
- `project` (string): Project root path. Default: current workspace.

### `roadmap_xref_push` (~224 tokens)

COMP-ROADMAP-XREF-PUSH: write external trackers to match feature.json declared `expect=`/`expect_labels` intent or lifecycle-derived intent (`derive_expect: true`; GitHub/Forgejo). DRY-RUN by default — returns {pushed, skipped, unchanged, scanned} describing what WOULD change. Only links with `push: true` are eligible. apply:true performs the writes: GitHub issue open/closed + additive labels (never removes; PR-backed refs skipped); Forgejo issue state + additive labels through independent operations, with partial-success rows reporting {statePushed, labelsPushed, errors[]}; and local refs via the sibling repo's own setFeatureStatus. Resolution failures are skipped; GitHub write failures and local disallowed transitions also skip, while successful Forgejo operations remain reported if another operation fails. Returns a small summary, never a large body.

Input parameters:

- `apply` (boolean): Perform the writes. Default false (dry-run — report only).
- `project` (string): Project root path. Default: current workspace.

### `propose_followup` (~223 tokens)

File a follow-up feature against a parent. Auto-numbers the next code in the parent's namespace (parent_code-N), adds the ROADMAP row, links surfaced_by from new → parent, and scaffolds design.md with a "## Why" rationale block. Idempotent on (parent_code, idempotency_key); resumes across partial failures via an inflight ledger.

Input parameters:

- `complexity` (string)
- `description` (string, required): One-line description for the ROADMAP cell.
- `idempotency_key` (string): Optional retry-safety key. Without it, repeated calls allocate new codes.
- `parent_code` (string, required): Parent feature code (e.g. "COMP-MCP-MIGRATION"). Must exist; must not be KILLED/SUPERSEDED.
- `phase` (string): Phase heading. Defaults to the parent's phase if omitted.
- `rationale` (string, required): Why this follow-up exists. Persisted as a "## Why" block in the new design.md and in the audit event.
- `status` (string)

### `link_artifact` (~173 tokens)

Register a non-canonical artifact (snapshot, journal entry, finding, etc.) on a feature. Canonical artifacts (design.md, plan.md, …) inside the feature folder are auto-discovered and rejected here. Stores in feature.json artifacts[]; dedups on (type, path); appends an audit event (best-effort).

Input parameters:

- `artifact_type` (string, required): e.g. "journal", "snapshot", "finding", "report-supplement", "link", "external"
- `feature_code` (string, required)
- `force` (boolean): Overwrite an existing entry with the same (type, path)
- `idempotency_key` (string)
- `path` (string, required): Repo-relative path. Must exist; cannot contain ".." after normalization.
- `status` (string)

### `link_features` (~478 tokens)

Register a typed cross-feature relationship. Two shapes: (1) SAME-PROJECT — kind ∈ surfaced_by|blocks|depends_on|follow_up|supersedes|related, requires to_code; self-links rejected; dedups on (kind,to_code). (2) EXTERNAL (kind:"external") — a cross-project pointer, NOT a same-project link: requires provider; four resolvable sub-shapes — github or forgejo (repo "owner/name" + integer issue), local (repo token + to_code), url (url); plus reserved url-class providers jira|linear|notion|obsidian (parse-valid, require url, NOT resolved in v1). External dedups on (kind=external, provider, repo, issue|to_code|url). Stores on the source feature; query inverse via get_feature_links(direction:"incoming").

Input parameters:

- `derive_expect` (boolean): For github/forgejo, derive open|closed from the owning feature status at validation and push time instead of storing expect.
- `expect` (string): Optional expected state. github/forgejo: open|closed. local: a status token. url-class: recorded, never resolved.
- `expect_labels` (array): Optional labels to add without removing existing labels. Supported by github and forgejo links.
- `force` (boolean)
- `from_code` (string, required)
- `idempotency_key` (string)
- `issue` (integer): External github/forgejo: issue/PR number.
- `kind` (string, required)
- `note` (string)
- `provider` (string): Required when kind:"external". Resolvable: github|forgejo|local|url. Reserved url-class (require url, not resolved in v1): jira|linear|notion|obsidian.
- `push` (boolean): Opt this external link into roadmap_xref_push. Default false.
- `repo` (string): External github/forgejo: "owner/name". External local: workspace-relative repo token.
- `to_code` (string): Same-project: target feature code (required unless kind:"external"). External local: the cited feature code. Need not exist yet.
- `url` (string): External url-class (url|jira|linear|notion|obsidian): the pointer URL.

### `get_feature_artifacts` (~61 tokens)

Read both canonical (auto-discovered: design.md, plan.md, …) and linked (snapshots, journals, findings) artifacts for a feature in one call. Each linked entry includes a current existence check.

Input parameters:

- `feature_code` (string, required)

### `get_feature_links` (~50 tokens)

Read outgoing and/or incoming feature links. Default returns both directions; filter by kind if needed.

Input parameters:

- `direction` (string)
- `feature_code` (string, required)
- `kind` (string)

### `add_changelog_entry` (~257 tokens)

Insert (or replace, with force: true) a typed entry in compose/CHANGELOG.md. Idempotent on (date_or_version, code) at storage level; optional caller-supplied idempotency_key for retry safety. Audit-log append is best-effort. Use this instead of editing CHANGELOG.md by hand.

Input parameters:

- `body` (string): Free paragraphs between header and labeled subsections.
- `code` (string, required): Feature code (e.g. "COMP-FOO-1"). Uppercase A-Z, digits, dashes; cannot start or end with a dash.
- `date_or_version` (string, required): ISO date "YYYY-MM-DD" or semver "vX.Y.Z"
- `force` (boolean): If true and an entry with the same (date_or_version, code) exists, replace it in place.
- `idempotency_key` (string): Optional caller-supplied key. Same key replays return the cached result without re-mutating.
- `sections` (object): Optional labeled subsections; emitted in fixed order Added → Changed → Fixed → Snapshot.
- `summary` (string, required): One-line summary; renders as the "— summary" tail of the entry header.

### `get_changelog_entries` (~114 tokens)

Read parsed entries from compose/CHANGELOG.md. Filter by code (exact) or since (shorthand "24h"/"7d"/"30m" or ISO date — date-only; version surfaces always pass through).

Input parameters:

- `code` (string)
- `limit` (number): Default 50; capped at 500.
- `since` (string): Window: shorthand like "24h"/"7d"/"30m" or ISO date. Date-only filter; version surfaces are always returned.

### `write_journal_entry` (~216 tokens)

Write a typed entry to compose/docs/journal/ with auto-numbered global session and inserted index row. Idempotent on (date, slug) at storage level; optional caller idempotency_key for retry safety. Audit-log append is best-effort.

Input parameters:

- `closing_line` (string): Optional final italicized one-liner.
- `date` (string, required): ISO date "YYYY-MM-DD".
- `feature_code` (string): Optional feature code stamped in entry frontmatter.
- `force` (boolean): If true and an entry with the same (date, slug) exists, overwrite in place.
- `idempotency_key` (string): Optional caller-supplied key. Same key replays return the cached result without re-mutating.
- `sections` (object, required)
- `slug` (string, required): Kebab-case slug for the filename, e.g. "mcp-journal-writer".
- `summary_for_index` (string, required): Single-line summary for the README index row. No newlines, no "|".

### `get_journal_entries` (~88 tokens)

Read parsed entries from compose/docs/journal/. Filter by feature_code (exact), session (exact), or since (shorthand "24h"/"7d"/"30m" or ISO date).

Input parameters:

- `feature_code` (string)
- `limit` (number): Default 50; capped at 500.
- `session` (number)
- `since` (string)

### `backfill_completion` (~123 tokens)

Reconstruct a completion through the running Compose server from historical evidence. With no configured guard.testCommand, tests_pass must be explicitly true. Each occurrence must cite either a verified commit SHA or a repo-relative file already inside the repository. This is HTTP delegation like complete_feature, so the Compose server must be running.

Input parameters:

- `commit_sha` (string, required)
- `files_changed` (array, required)
- `id` (string, required)
- `notes` (string)
- `occurrences` (array)
- `reason` (string, required)
- `tests_pass` (boolean, required)

### `record_completion` (~280 tokens)

Record a completion bound to a commit SHA — THROUGH the completion gate (COMP-COMPLETION-GATE): under capabilities.guard the commit is server-verified and tests attested (no silent default), ONE guarded transition is ledgered, then the gate writes completions[], status COMPLETE, ROADMAP.md, the cockpit item and the audit event. A refusal (bad evidence, KILLED/SUPERSEDED feature, guard refused/unreachable) errors with COMPLETION_REFUSED and writes NOTHING. Projection failures (ROADMAP/vision) return success with partial:true + failures[]. set_status:false records evidence only (no status change, no guard transition). Idempotent on (feature_code, commit_sha).

Input parameters:

- `commit_sha` (string, required): Full 40-char hex SHA (Decision 9). Short prefixes are rejected before any guard write. Stored lowercase; commit_sha_short is derived for display only.
- `feature_code` (string, required)
- `files_changed` (array, required)
- `force` (boolean): If true and a record with the same (feature_code, commit_sha) exists, replace it in place.
- `idempotency_key` (string)
- `notes` (string)
- `set_status` (boolean): Default true. When true, flips status to COMPLETE via set_feature_status.
- `tests_pass` (boolean, required)

### `get_completions` (~80 tokens)

Read completion records from feature.json files. Filter by feature_code (exact), commit_sha (short or full prefix), or since (shorthand or ISO date).

Input parameters:

- `commit_sha` (string)
- `feature_code` (string)
- `limit` (number): Default 50; capped at 500.
- `since` (string)

### `write_checkpoint` (~194 tokens)

COMP-RESUME: write a durable build checkpoint anchored to a deterministic environment fingerprint. Omit `soft` for a cheap anchor checkpoint — the response then includes a `scribePrompt` you can answer (returning {goal,nextStep,risks} anchored to the fingerprint) and re-submit as `soft` for a narrative checkpoint. Pass `soft` directly to skip that. Returns {checkpoint, scribePrompt}. Direct-to-disk (works when the server is down).

Input parameters:

- `confidence` (number): Only on resume-sync checkpoints (0..1).
- `featureCode` (string, required)
- `flowId` (string): Stratum flow id, if any.
- `phase` (string): Lifecycle phase label; falls back to feature.json then "unknown".
- `soft` (object): Narrative intent; omit for an anchor checkpoint. Every factual claim should reference a fingerprint anchor.
- `trigger` (string, required)

### `compose_resume` (~88 tokens)

COMP-RESUME: reconcile a build against ground-truth environment state and return the resume decision. Rebuilds derived state, classifies drift (clean/advanced/diverged), and returns action resume|needs-sync|gate. On needs-sync the caller runs the reconciliation agent with the returned prompt. Requires the Compose server (reconciles live lifecycle state).

Input parameters:

- `featureCode` (string, required)

### `judgment_position_create` (~162 tokens)

Create a judgment position revision (new chain, update, supersession via supersedes, or tombstone via retracted). ASSERT grounding requires an elicitation block. Provenance is writer-stamped.

Input parameters:

- `claims` (array, required): Claims: {id, text, grounding EXT|INT|ASSERT|DERIVED|AGENT, supports[], elicitation?}.
- `conviction` (object, required): {level high|medium|low, source stated|inferred}
- `idempotency_key` (string)
- `rejected_alternatives` (array): {what, why}[]
- `retracted` (boolean): true → tombstone revision.
- `slug` (string, required)
- `supersedes` (string): <slug>#r<N> being superseded.

### `judgment_position_amend` (~97 tokens)

Scoped amendment (P6): new revision changing ONE claim's grounding and/or the conviction block. Anything else is supersession via judgment_position_create.

Input parameters:

- `claim_id` (string)
- `conviction` (object)
- `elicitation` (object): Required if new grounding is ASSERT.
- `grounding` (string): New grounding for claim_id.
- `idempotency_key` (string)
- `slug` (string, required)

### `judgment_joint_add` (~182 tokens)

Add a judgment joint (born open). Both branches and a coarse cost bucket are required; EXT/STRADDLE method packages may be attached now or at dispose time.

Input parameters:

- `branch_false` (string, required)
- `branch_true` (string, required)
- `cost` (string, required): hours|days|weeks|months
- `ext` (object): EXT package: {sharpened_question, bar, falsifier} or {judgment_dispatch: true, reason}.
- `flags` (array)
- `idempotency_key` (string)
- `question` (string, required)
- `rank` (string, required): high|medium
- `resolve_by` (string, required): EXT|INT|CONSTRUCT|ASSERT|STRADDLE
- `slug` (string, required)
- `straddle` (object): {discriminating_signal, kill_criteria}

### `judgment_transition` (~227 tokens)

Joint state machine (edge→artifact table enforced; Stratum-guarded where capabilities.guard). Provide the target state plus its required artifact (resolution/dissolution/reopen/redispose), and/or a rank change (atomic rank ledger event).

Input parameters:

- `dissolution` (object): {decomposed_into[]}
- `ext` (object): EXT package attached at dispose time.
- `idempotency_key` (string)
- `rank` (object): {to: high|medium}
- `redispose` (object): {new_resolve_by, ext?, straddle?} (retry inconclusive with a different method)
- `reopen` (object): {shaken_evidence_ref} (P6)
- `resolution` (object): {outcome resolved|inconclusive|failed_to_run|superseded, …outcome-specific fields, ext_result?, elicitation?}
- `slug` (string, required)
- `straddle` (object)
- `to` (string): open|under_test|resolved|inconclusive|superseded|dissolved

### `judgment_ledger_append` (~304 tokens)

Append a judgment ledger event (kind-specific required fields enforced: commit-decide needs trigger+open_joints+prediction; postmortem needs recall_verdict+attribution and grades prediction_ref; override needs reason). Commit/CONSTRUCT events spawn prediction records.

Input parameters:

- `anchor` (string): On note: projection anchor (register-header, joint:<slug>, …).
- `attribution` (string)
- `body` (string)
- `conviction` (object)
- `disposition` (string): Method disposed with; CONSTRUCT requires prediction.
- `idempotency_key` (string)
- `kind` (string, required): decide|kill|override|escalate|calibrate|postmortem|rank|note|correct|open
- `open_joints` (array)
- `prediction` (object): {text, outcome_criteria}
- `prediction_grade` (string): right|right-wrong-reason|wrong
- `prediction_ref` (string)
- `reason` (string)
- `recall_verdict` (string)
- `refs` (array)
- `rejected` (array)
- `rests_on` (array): On commit-moment decide: goal clause refs (goal:v<N>#c<N>) the commit rests on; resolved through the effective goal chain.
- `title` (string, required)
- `trigger` (string): On decide: earned|forced|exhausted (marks a commit-moment decide).

### `judgment_person_write` (~305 tokens)

Write person canon by op. create adds a person; open_field supports create, fill, and reopen; edge/load_link support create and remove; correct supports divergence pair/clear. Provenance is writer-stamped.

Input parameters:

- `at` (string): ISO date (YYYY-MM-DD).
- `carries` (string)
- `channel` (string): said|observed|secondhand|inferred
- `clear` (array): On correct: exactly ["diverges_with"].
- `display_name` (string)
- `edge_id` (string)
- `fact` (string): load_link create branch fact ID.
- `fact_id` (string)
- `filled_by` (string)
- `idempotency_key` (string)
- `kind` (string): edge create branch kind.
- `load_link_id` (string)
- `name` (string): open_field create branch.
- `op` (string, required)
- `open_field_id` (string)
- `pair_with` (string): Pair stated↔revealed divergence on correct.
- `reason` (string)
- `remove` (boolean)
- `reopen` (boolean)
- `section` (string): role|life|stated|revealed
- `slug` (string)
- `text` (string)
- `to` (string): edge create branch target person slug.
- `via` (string): Source attribution for a secondhand fact; not provenance.

### `judgment_situation_write` (~226 tokens)

Write situation-entity canon by op. create adds an entity; owed supports create, give, and reopen; load_link supports create and remove. Provenance is writer-stamped.

Input parameters:

- `at` (string): ISO date (YYYY-MM-DD).
- `carries` (string)
- `channel` (string): said|observed|secondhand|inferred
- `display_name` (string)
- `fact` (string): load_link create branch fact ID.
- `fact_id` (string)
- `filled_by` (string)
- `idempotency_key` (string)
- `load_link_id` (string)
- `name` (string): owed create branch.
- `op` (string, required)
- `owed_id` (string)
- `reason` (string)
- `remove` (boolean)
- `reopen` (boolean)
- `slug` (string)
- `text` (string)
- `via` (string): Source attribution for a secondhand fact; not provenance.
- `why_load_bearing` (string)

### `judgment_goal_write` (~259 tokens)

Write goal canon by op. Ordinary cuts require elicited clauses, provocation, and owner ratification. Every non-migrate op is migration-locked while a live legacy objective requires migration; migrate is the one-shot, fail-closed cutover that lifts the lock and takes no payload. joint_link/load_link support create and remove. Provenance and intents are writer-owned.

Input parameters:

- `carries` (string)
- `clause` (string): load_link create branch v<N>#c<N> reference.
- `clause_id` (string): correct branch clause ID.
- `clauses` (array): cut: {text, channel, elicitation, secondhand source attribution?}[]
- `diff_note` (string)
- `idempotency_key` (string)
- `joint` (string): joint_link create branch joint slug.
- `joint_link_id` (string)
- `load_link_id` (string)
- `op` (string, required)
- `provocation` (object): cut: {quote, at}
- `ratification` (object): cut: {asked, answered_at, answer_ref, quote}
- `reason` (string)
- `remove` (boolean)
- `text` (string): correct branch replacement wording.

### `get_judgment_state` (~38 tokens)

Judgment canon snapshot: positions (derived status), joints, under-test, open predictions, recent ledger. Replays pending judgment intents first.

### `get_judgment_trace` (~76 tokens)

Causal ancestry of one judgment position: every revision in order, what it superseded (walked recursively), and what superseded it. Read-only; answers "what did we believe when we made that call", which get_judgment_state cannot (it returns latest-only).

Input parameters:

- `slug` (string, required): Position slug

## Diagnostics

Captured diagnostic sections: Provenance, Dependencies. The full working is on the page: https://verifymcp.io/servers/ai-smartmemory-compose-mcp/smartmemory-compose-mcp#diagnostics

## Score history

- 2026-09-27: 28
- 2026-09-26: 57
- 2026-09-25: 20
- 2026-09-24: 51
- 2026-09-23: 66
- 2026-09-22: 66
- 2026-09-21: 65
- 2026-09-20: 65
- 2026-09-19: 64
- 2026-09-18: 64
- 2026-09-17: 63
- 2026-09-16: 63
- 2026-09-15: 62
- 2026-09-14: 62
- 2026-09-13: 58
- 2026-09-12: 58
- 2026-09-11: 58
- 2026-09-10: 58
- 2026-09-09: 58
- 2026-09-08: 58
- 2026-09-07: 58
- 2026-09-06: 43

## Common questions

### What is the Compose MCP server?

Compose MCP is listed in the public MCP registry as ai.smartmemory/compose-mcp. Typed feature management for compose projects: roadmap, changelog, artifacts, journal. This page covers its npm package (@smartmemory/compose-mcp).

### Is the Compose MCP server safe to use?

Compose MCP scores 28 out of 100 on VerifyMCP. It declares no install or post-install scripts. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the Compose MCP server expose?

Compose MCP exposes 51 tools: get_vision_items, get_item_detail, get_phase_summary, get_blocked_items, get_current_session, and 46 more. Their descriptions and schemas cost roughly 7,225 tokens of context every time the server is loaded.

### Is the Compose MCP server still maintained?

Compose MCP is still listed as active in the MCP registry. We last reached this channel on 27 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

### What licence is the Compose MCP server under?

Compose MCP declares the BUSL-1.1 licence, which is not on the OSI-approved list. Read the terms before using it at work, and note this covers the source only, not the cost of any service it calls.

## Links

- npm package: https://www.npmjs.com/package/@smartmemory/compose-mcp
- Socket report: https://socket.dev/npm/package/@smartmemory/compose-mcp
- Changelog RSS feed: https://verifymcp.io/servers/ai-smartmemory-compose-mcp/smartmemory-compose-mcp.xml
- Changelog JSON feed: https://verifymcp.io/servers/ai-smartmemory-compose-mcp/smartmemory-compose-mcp.json
- HTML version of this page: https://verifymcp.io/servers/ai-smartmemory-compose-mcp/smartmemory-compose-mcp