Yeti, an MCP server that guides product design from requirements to Jira

Macorifice released Yeti, an open-source Model Context Protocol server connecting Claude Desktop to local product design workflows and Jira tracking. As detailed in github.com's report, the utility guides projects from problem discovery to verified scopes. Running on Node.js 22.13 or newer with native SQLite, Yeti directs Claude through user stories, RICE scoring, and Mermaid flow diagrams before publishing tickets.

This report examines the architecture, tools, phase constraints, and configuration introduced in Yeti 1.0.0. Geared for technical product managers and engineers using Claude Desktop, it details how conversational prompts convert into MoSCoW requirements and exportable backlogs, covering installation, local dashboard monitoring, and Jira synchronization rules.

Yeti: what actually changed

With the stable 1.0.0 release, Macorifice moved Yeti to the native node:sqlite module in Node.js 22.13, replacing the earlier data/db.json storage format. On its first run, the updated server automatically imports data from data/db.json and leaves that file untouched. When adding Yeti to claude_desktop_config.json via npx, operators must set PRODUCT_DESIGN_DB to a permanent path like data/yeti.sqlite. Because npx package caches can clear unpredictably, isolating the SQLite file outside transient directories protects requirements, stories, and summaries from unintended deletion during routine system cleanups.

Yeti also introduces a read-only dashboard alongside its Model Context Protocol tools. Operators can launch this local interface from Claude using open_dashboard or from a terminal with npx yeti-mcp dashboard --port 4321. The dashboard binds strictly to 127.0.0.1, refuses requests targeting other hostnames, and polls the SQLite database every ten seconds. It renders flow diagrams using Mermaid loaded from a content delivery network, falling back to plain text offline. In addition, export_dashboard writes a static snapshot directly to data/exports/dashboard.html for sharing across teams.

Yeti: how it works

Projects advance through five ordered phases: discovery, definition, prioritization, flows, and verification. In discovery, teams establish the problem, users, and goal, such as quoting in five minutes for plumbers and painters. The definition phase requires adding MoSCoW requirements and linking user stories with acceptance criteria. Next, prioritization ranks concepts by computing and sorting user-entered RICE scores, while flows uses map_user_flow for Mermaid branching diagrams. Finally, verification confirms every must requirement is marked complete and covered by an active user story before the project closes.

Execution is governed by strict and free modes. In default strict mode, advance_phase halts transitions when items are missing, reporting exact omissions. In free mode, phases advance regardless while listing skipped elements. Items can be edited, searched, duplicated as project templates, or exported as Markdown or CSV to data/exports/. When exporting work, push_to_jira defaults to dry-run mode, creating Jira Tasks for requirements and Stories for user stories. Downstream, sync_from_jira marks matching Yeti items completed or reopened according to Jira status while leaving manually closed items untouched.

Yeti: why it matters now

Conversational artificial intelligence often suffers from context drift during planning, causing dropped constraints and unranked backlogs. Yeti introduces structured discipline to Claude Desktop by functioning as a deterministic gatekeeper for product definitions. Instead of allowing conversational assistants to generate unverified task lists, Yeti requires ideas to pass through MoSCoW prioritization and user story mapping. Because prioritize_rice sorts manually entered numerical values rather than generating speculative estimates, human operators retain control over priority scores. This framework converts conversational prompts into auditable specifications before engineering tasks reach external boards.

Data isolation provides clear boundaries because the server functions locally without requiring third-party cloud user accounts. Core operations including project modeling, story tracking, criterion updates, diagram rendering, and backlog exports execute entirely on the local machine using SQLite. External networking occurs exclusively through push_to_jira, which demands JIRA_SITE, JIRA_EMAIL, and JIRA_API_TOKEN environment variables. If these credentials are missing, the tool halts remote transmission while continuing to support local dry-run previews. Furthermore, displaying Jira links on the local dashboard when JIRA_SITE is supplied gives product teams immediate visibility across design artifacts and development tickets.

Yeti: who is affected

Technical product managers and system designers using Claude Desktop gain formal guardrails for scoping complex initiatives. Teams can duplicate existing projects via duplicate_project to reuse proven requirement and story patterns as templates. For teams with existing backlogs, import_requirements ingests CSV data exported by export_backlog, though story links must be reconnected manually after import. Engineering leads benefit from the verification phase gate, which prevents unfinished requirements from prematurely reaching active engineering queues, ensuring that every critical feature has validated user stories and completed acceptance criteria before implementation begins.

Jira administrators and engineering teams maintain standard board operations because Yeti intentionally avoids implementing a duplicate task board. Active execution belongs in Jira, while Yeti confines its dashboard to design progress. When dispatching tickets, push_to_jira includes a limit parameter to send controlled subsets and an update option to refresh previously linked tickets. Remote sync maintains board alignment through sync_from_jira, which reads Jira issue states, automatically marking completed tickets done in Yeti while reopening tickets if status regresses, without overriding items that operators manually marked complete.

Yeti: what to watch

Organizations adopting Yeti must establish proper local storage hygiene and environment variable configurations. Running the server requires Node.js 22.13 or newer, whether built from source using npm run build targeting dist/index.js or executed through npx yeti-mcp. Operators must persistently set PRODUCT_DESIGN_DB in shell configuration files to ensure the SQLite database is never placed within temporary caches that clear automatically. Teams must also recognize that while local database records remain private, requirement text passes through the Claude conversational interface, meaning sensitive company secrets or internal credentials must be kept out of chat prompts.

Development teams should evaluate the Mastro case study provided in the repository to observe how requirement gates and Jira sync cycles function in practice. Test suites executed via npm test allow engineers to validate phase transitions and tool operations against temporary databases before committing to production planning workflows. As teams choose between strict gating and free iteration, monitoring how well the local dashboard maintains visibility over MoSCoW priorities, Mermaid diagrams, and RICE leaders will indicate whether Model Context Protocol servers can permanently bridge the gap between conversational AI design and enterprise issue trackers.