# Decantr > Decantr AI design intelligence layer for AI-generated web applications - **Type:** MCP server - **Install:** `agentstack add mcp-decantr-ai-decantr` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [decantr-ai](https://agentstack.voostack.com/s/decantr-ai) - **Installs:** 0 - **Category:** [AI & ML](https://agentstack.voostack.com/c/ai-and-ml) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [decantr-ai](https://github.com/decantr-ai) - **Source:** https://github.com/decantr-ai/decantr - **Website:** https://decantr.ai ## Install ```sh agentstack add mcp-decantr-ai-decantr ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # Decantr **AI Frontend Governance for production codebases touched by AI agents.** Decantr is the governance layer between product intent and AI-edited frontend code. It gives coding assistants three things they don't have on their own: typed contracts, route-scoped context, and machine-actionable evidence, so UI changes stay coherent instead of drifting prompt by prompt. The model still writes the code; Decantr defines the contract, context, and verification loop around it. > AI generates the interface. Decantr proves, with local evidence, whether the outcome stayed aligned. ## Pick your path | Path | Use when | Start with | | --- | --- | --- | | **[Brownfield adoption](docs/reference/workflow-model.md#brownfield-adoption)**  ⭐ | Attaching Decantr to an existing Angular/React/Vue/etc. project | `decantr scan` -> `decantr adopt --yes` | | **[Hybrid operating layer](docs/reference/workflow-model.md#hybrid-operating-layer)** | An attached app wants selected Decantr or project-owned UI law, without source takeover | `decantr codify`, `decantr doctor`, `decantr task` | | **[Greenfield content contract](#greenfield-content-contracts)** | New project, official content-corpus composition as governance context | `decantr new my-app --blueprint= --workflow=greenfield` | | **Greenfield contract-only** | New project or repo that wants Decantr governance but no blueprint/runtime takeover | `decantr init --workflow=greenfield --adoption=contract-only` | --- ## Greenfield Content Contracts ### 1. Scaffold from a blueprint ```bash npx @decantr/cli new my-app --blueprint=esports-hq cd my-app ``` A blueprint is official corpus content: theme, sections, pages, layouts, voice, and personality that compile into Decantr contracts and execution packs. It is reference material for governance, not a public marketplace or runtime takeover. Try `esports-hq`, `agent-studio`, or `carbon-ai-portal`, or run `decantr list blueprints --blueprint-set featured` to browse the curated set. > **Adapter availability.** Greenfield defaults to contract-only governance. The legacy `@decantr/css` runnable adapters (`react-vite`, `next-app`, `vanilla-vite`, `vue-vite`, `sveltekit`, `angular`, and `solid-vite`) remain available only when explicitly requested with `--adoption=decantr-css`. Other targets initialize through `generic-web` contract-only mode. ### 2. What just got generated ``` my-app/ ├── decantr.essence.json # the durable contract: theme, sections, routes, features ├── DECANTR.md # methodology primer your AI assistant reads first ├── .decantr/context/ │ ├── scaffold.md # full app overview: topology, voice, personality │ └── section-*.md # per-section spec: shell, patterns, spacing └── src/styles/ ├── tokens.css # CSS variables from the theme ├── treatments.css # shared visual treatment classes └── decorators.css # theme-specific decorator classes ``` Decantr produces the contract. Your AI assistant produces the implementation against it. ### 3. Hand it to your AI assistant Open the project in Claude Code, Cursor, Windsurf, or any AI-aware editor. For Cursor, run `decantr connect cursor` once from the opened workspace; in monorepos use `decantr connect cursor --project apps/web`. It writes `.cursor/mcp.json` and `.cursor/rules/decantr.mdc`, preserving existing MCP servers, so Cursor Agent knows to call Decantr task context before route edits. Other assistants can read `DECANTR.md` first for the methodology, then load section context files on demand. For route-level work, run `decantr task ""` before editing so the assistant gets the active authority block, local law, evidence, and verify command. The split keeps the assistant focused on the right scope at the right time. ### 4. Make your first change and verify ```bash # Edit decantr.essence.json — add a section, swap the theme, etc. decantr refresh # regenerate context files from the updated essence decantr graph # generate the typed Contract graph, source index, and contract capsule decantr verify # run the canonical local reliability gate decantr verify --evidence decantr studio # open the local-only health dashboard ``` `refresh` keeps the generated context files in sync with the essence. `graph` writes `.decantr/graph/graph.snapshot.json`, `.decantr/graph/snapshots/.json`, `graph.manifest.json`, `graph.diff.json`, and `contract-capsule.json` for typed agent context and replayable local history. `verify` is the day-to-day reliability gate over Project Health, Brownfield checks, health baselines, and optional evidence; health findings include stable diagnostic codes, typed repair IDs, component reuse drift such as `COMP001` when an agent reimplements a project-owned primitive, behavior-obligation drift such as `A11Y010` when an accepted confirmation dialog loses its accessible name, and accepted style bridge drift such as `TOKEN010` when arbitrary Tailwind, inline style, or stylesheet values bypass project-owned style authority. When a graph snapshot exists, findings also include graph anchors back to the contract node they came from. `--evidence` writes the privacy-redacted Evidence Bundle that AI agents and CI can use for repair context, including those codes, repair IDs, and graph anchors when available. `decantr studio` gives the same signal in a small localhost dashboard, and `decantr studio --workspace` expands that view across many Decantr projects in a monorepo. > Starting from a different point? See the full [workflow model](docs/reference/workflow-model.md). --- ## The model Decantr separates design governance into two layers: - **DNA** — durable visual and system axioms: theme, spacing, motion, accessibility, personality. - **Blueprint** — product topology: sections, page routes, shells, layouts, features. That split matters because not every change should be treated the same way. A theme swap or accessibility regression is different from adding an auxiliary section or reshaping a route map. Decantr lets governance be strict where it should be strict (DNA, errors by default) and flexible where it should be flexible (Blueprint, warnings only). Canonical shapes live in the [published schemas](https://decantr.ai/schemas/); the command-level flow is in the [workflow model](docs/reference/workflow-model.md). ## Surfaces | Surface | What it does | | --- | --- | | CLI | Guides users through workflow commands (`setup`, `adopt`, `doctor`, `task`, `verify`, `resolve`, `ci`, `codify`, `connect cursor`), keeps advanced primitives available, writes v2 Evidence Bundles, runs workspace health, installs CI, opens Studio Control Room locally, configures Cursor activation, and audits official-vocabulary supply-chain health | | MCP server | Exposes Decantr directly to AI tools - essence reads, vocabulary resolution, context reads, pack compilation, drift checks, critique, audit, v2 evidence bundles, workspace health, health-loop guidance, and repair prompts | | Content API | Fly-hosted helper for official corpus search, schemas, intelligence summaries, showcase metadata, and execution-pack compilation | | Verifier | Shared audit, critique, Project Health, Evidence Bundle, component reuse drift, behavior-obligation drift, style bridge drift, stable diagnostic code, typed repair ID, graph-anchored finding, contract assertion, and report-schema engine | | Showcase apps | Audited benchmark corpus and verification targets for Decantr-generated scaffolds | Decantr 3.7 introduced the shared Brownfield discovery substrate that Decantr 3.8 now uses across verifier, CLI, MCP, and app-scoped workflows. `scan`, `setup`, `workspace list`, `adopt`, `doctor`, `task`, `verify`, `ci`, and MCP project/task/evidence reads agree on selected app scope, workspace package manager, framework, language, route signals, taskable routes, component inventory confidence, styling authority, assistant rules, and limitations. This is especially important in mixed monorepos: a React/Vite app beside an Angular app should scan as React/TypeScript/pnpm when `--project apps/web` targets the React app, not as the repository root or sibling framework. `scan --json` emits `scan-report.v2` by default; `scan-report.v1` remains published as a historical schema reference. Security review starts with the installed npm surface, not the whole monorepo. The package permission matrix documents filesystem, network, process, telemetry, hosted-upload, and MCP write-tool behavior for every public package: [docs/reference/security-permissions.md](docs/reference/security-permissions.md). ## Packages | Package | Role | | --- | --- | | `@decantr/essence-spec` | Essence schemas, validation, migration, and TypeScript types | | `@decantr/content` | Official content corpus, schemas, validation, search, resolution, and content health helpers | | `@decantr/registry` | Legacy compatibility package for content/API client naming in Decantr 3.x | | `@decantr/css` | Legacy optional CSS atom adapter; not a default adoption path | | `@decantr/core` | Execution-pack compiler primitives, typed Contract graph builders, graph diffs, snapshot history, hybrid graph ranking, evidence/proof ingestion, and Contract capsules | | `@decantr/verifier` | Shared audit, critique, v2 Evidence Bundle, loop readiness, authority resolution, component reuse drift, behavior-obligation drift, style bridge drift, stable diagnostic code, typed repair ID, graph-anchored finding, contract assertion, and report-schema engine | | `@decantr/mcp-server` | MCP delivery surface for assistants and agent tooling | | `@decantr/cli` | Local contract, content, Project Health CI/Studio, audit, and maintenance workflows | | `@decantr/vite-plugin` | Experimental local guard feedback overlay for Vite | Full release/support status lives in [docs/reference/package-support-matrix.md](docs/reference/package-support-matrix.md). ## Repo layout | Path | Role | | --- | --- | | `apps/api` | Fly-hosted content API for corpus, schemas, search, intelligence, showcase metadata, and execution packs | | `apps/showcase-host` | Shared Vite host for live blueprint showcase capsules | | `apps/showcase/` | Showcase manifest and verification reports used by the content API | | `packages/*` | Core Decantr packages and supporting runtime surfaces | | `docs/` | Public docs, audits, architecture notes, schemas, and runbooks | | `scripts/` | Audit, release, showcase, schema, and packaging automation | Showcase capsule architecture is documented in [docs/reference/showcase-host.md](docs/reference/showcase-host.md). ## Development Requires **Node.js `>=20.19.0`** and **pnpm `>=9`**. ```bash pnpm install pnpm build pnpm test pnpm lint pnpm audit:public-api pnpm audit:package-permissions pnpm audit:content-package pnpm showcase:verify:shortlist pnpm benchmark:realworld-corpus -- --config scripts/realworld-corpus.first-mile.json --cli packages/cli/dist/index.js --out /tmp/decantr-realworld-corpus-3.8 pnpm release:verify pnpm release:closeout ``` ### Release stewardship Release work is script-led. Use `pnpm release:commands` for publish handoff, `pnpm release:verify` for public npm verification, and `pnpm release:closeout` before calling a release done. Closeout verifies npm version/dist-tag parity plus git tag and release-note parity so versioned docs cannot drift away from origin tags. After closeout, `pnpm release:announce -- --version X.Y.Z --send` can dispatch the changelog to `community-ops` for Discord posting. See [docs/runbooks/release-stewardship.md](docs/runbooks/release-stewardship.md). ## More CLI Intent and discovery: ```bash decantr setup decantr magic "AI chatbot with a bold terminal-inspired workspace" decantr search dashboard decantr list blueprints --blueprint-set certified decantr list blueprints --blueprint-set labs decantr suggest leaderboard decantr suggest "recipe feed with infinite scroll" --route /feed --from-code decantr suggest --from-code --file app/page.tsx --project apps/web decantr suggest "standardize buttons" --project apps/web ``` Source-code suggestions rank official content patterns and accepted `.decantr/local-patterns.json` against the selected app's file contents. From an app root, `decantr suggest "button" --from-code --file src/App.tsx` surfaces project-owned law without extra flags; from a monorepo root, add `--project apps/web`. Brownfield adoption: ```bash decantr scan decantr adopt --yes decantr studio decantr doctor decantr codify --from-audit --style-bridge decantr codify --map-pattern hero decantr codify --accept decantr graph decantr graph --file src/app/page.tsx --impact --json decantr resolve decantr connect cursor decantr task /feed "add saved recipe actions" decantr verify --brownfield --local-patterns decantr verify --since-baseline ``` In a monorepo, install Decantr at the workspace root, but attach it to an app: ```bash decantr setup decantr workspace list decantr scan --project apps/web decantr adopt --project apps/web --yes cd apps/web && decantr studio decantr doctor --project apps/web decantr codify --from-audit --style-bridge --project apps/web decantr codify --map-pattern hero --project apps/web decantr graph --project apps/web decantr graph --project apps/web --file src/app/page.tsx --impact --json decantr resolve --project apps/web decantr connect cursor --project apps/web decantr task /feed "add saved recipe actions" --project apps/web decantr verify --brownfield --local-patterns --project apps/web decantr ci init --project apps/web decantr ci --project apps/web decantr add page app/settings --route /settings --project apps/web decantr health --project apps/web --prompt ``` For observed Brownfield apps, `app/settings` can resolve to the single primary section, such as `observed-primary`, so route additions remain ergonomic after attach. If the app is already running and you want local screenshots, add visual evidence later: ```bash decantr verify --project apps/web --base-url http://localhost:3000 --evidence ``` `analyze` now writes Brownfield intelligence artifacts in addition to the proposal: `.decantr/brownfield-intelligence.json`, `.decantr/theme-inventory.json`, and `.decantr/enrichment-backlog.md`. Essence V4 stays unchanged; multi-theme apps are observed in the inventory and kept as local task context until the team explicitly promotes that model. When local law, a style bridge, or Decantr CSS is accepted, Decantr calls that out as Hybrid instead of pretending every existing app is still only contract-only. `scan` is the safe first look: it is read-only and tells you whether Decantr sees a plausible UI app before anything is written. `adopt` orchestrates the primitive Brownfield flow (`analyze`, proposal acceptance, optional content pack hydration when online, first typed Contract graph baseline, Project Health, optional browser evidence, optional CI) so users do not need to memorize the internal command chain. In contract-only/offline adoption, content packs can be deferred; `doctor`, `health`, and `refresh --check` treat missing packs as optional context unless a present `pack-manifest.json` references missing files. `studio` gives a local visual view of what Decantr found, while `doctor` explains project/workspace state, generated artifacts, typed graph freshness, CI wiring, and the active adoption lane: Brownfield contract-only, Hybrid local law, Hybrid style bridge, Hybrid Decantr CSS, Hybrid composition, or Greenfield. `codify --from-audit` proposes project-owned local law in `.decantr/local-patterns.proposal.json` and `.decantr/rules.proposal.json`, with source evidence, confidence tiers, likely variants for button/card/form/theme families, and optional `behavior_obligations` for observed forms or destructive confirmation dialogs; `codify --style-bridge` proposes `.decantr/style-bridge.proposal.json`, mapping Decantr intent to project-owned tokens/classes without installing Decantr CSS; `codify -- … ## Source & license This open-source MCP server is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [decantr-ai](https://github.com/decantr-ai) - **Source:** [decantr-ai/decantr](https://github.com/decantr-ai/decantr) - **License:** MIT - **Homepage:** https://decantr.ai Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/mcp-decantr-ai-decantr - Seller: https://agentstack.voostack.com/s/decantr-ai - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.