{"slug": "yeti-an-mcp-server-that-guides-product-design-from-requirements-to-jira", "title": "Yeti, an MCP server that guides product design from requirements to Jira", "summary": "Yeti, an MCP server for product design with Claude, was released as the npm package yeti-mcp, taking a project from problem statement through requirements, MoSCoW priorities, user stories, RICE scoring and Mermaid flow diagrams before pushing the work to Jira. Yeti runs five ordered phases (discovery, definition, prioritization, flows, verification) in a default strict mode that blocks phase advancement until requirements are met, or a free mode that advances and lists what was skipped, and requires Node.js 22.13 or later with a PRODUCT_DESIGN_DB SQLite path set outside the npx cache.", "body_md": "An [MCP](https://modelcontextprotocol.io) server for product design with Claude. It takes a project from the problem to a verified scope: requirements, user stories, RICE priorities and flow diagrams. Then it sends the work to Jira.\n\nAdd Yeti to Claude Desktop, in `claude_desktop_config.json`, then restart Claude Desktop:\n\n```\n{\n  \"mcpServers\": {\n    \"yeti\": {\n      \"command\": \"npx\",\n      \"args\": [\"-y\", \"yeti-mcp\"],\n      \"env\": { \"PRODUCT_DESIGN_DB\": \"/Users/you/yeti/yeti.sqlite\" }\n    }\n  }\n}\n```\n\nSet `PRODUCT_DESIGN_DB` to a file in a folder you keep. With `npx` the package lives in a cache that can be cleared, and a database stored there would go with it. Yeti needs Node.js 22.13 or later.\n\nThen ask Claude:\n\nCreate a project \"Quotes for craftsmen\" with Yeti. Problem: writing quotes takes hours. Users: plumbers and painters. Goal: a quote in five minutes.\n\nOpen the Yeti dashboard.\n\nA project goes through five phases, in order:\n\n1. **discovery** : problem, users and goal\n2. **definition** : requirements (MoSCoW) and user stories\n3. **prioritization** : RICE scoring of ideas\n4. **flows** : Mermaid flow diagrams\n5. **verification** : every`must` requirement completed and covered by a user story, then the project closes\n\nProjects have a mode, chosen at creation:\n\n- **`strict`** (default): a phase advances only when its requirements are met.`advance_phase` tells you what is missing.\n- **`free`** : phases advance regardless, and the response lists what was skipped.\n\n**Projects**\n\n| Tool | What it does | \n|---|---|\n| `create_project` | Start a project in the discovery phase, in `strict` or`free` mode | \n| `list_projects` | List projects with id, name, phase and mode; archived ones are hidden unless `includeArchived` is set | \n| `get_project` | Show phase, what is missing, and linked items | \n| `project_summary` | Progress overview: requirements by priority and status, musts covered by stories, criteria done, RICE leader, Jira links, and what is missing to close | \n| `update_project` | Change a project's name, problem, users or goal | \n| `advance_phase` | Move to the next phase, or list what is missing | \n| `set_project_mode` | Switch a project between `strict` and`free` | \n| `duplicate_project` | Copy a project's requirements and stories into a new project, as open items (a template) | \n| `archive_project` | Hide a project from `list_projects` without deleting it | \n| `delete_project` | Permanently delete a project and its items. Requires `confirm: true` ; Jira issues are not touched | \n\n**Requirements and user stories**\n\n| Tool | What it does | \n|---|---|\n| `add_requirement` | Add a requirement with a MoSCoW priority | \n| `list_requirements` | List requirements, filtered by priority, status or project | \n| `update_requirement` | Change a requirement's title, description or priority | \n| `set_requirement_status` | Mark a requirement `open` or`done` | \n| `delete_requirement` | Delete a requirement and unlink it from stories | \n| `add_user_story` | Create a user story with acceptance criteria, optionally linked to requirements ( `requirementIds` ) | \n| `list_stories` | List user stories with their ids, links, criteria state and Jira key | \n| `update_user_story` | Change a story's persona, goal, benefit, linked requirements or criteria. Changing criteria resets their done state | \n| `set_criterion_status` | Mark one acceptance criterion of a user story as done or not done | \n| `delete_user_story` | Delete a user story | \n| `search_items` | Search requirements and stories by text, optionally within one project | \n\n**Prioritization and flows**\n\n| Tool | What it does | \n|---|---|\n| `prioritize_rice` | Compute and sort RICE scores | \n| `map_user_flow` | Generate a Mermaid flow diagram, with Yes/No branches, `next` and`ends` | \n| `list_flows` | List the flow diagrams saved in a project, with their index | \n| `delete_flow` | Delete one saved flow diagram, by the index shown by `list_flows` | \n\n**Import, export and dashboard**\n\n| Tool | What it does | \n|---|---|\n| `export_backlog` | Export a project backlog as Markdown or CSV; with `save` , also writes it to`data/exports/` | \n| `import_requirements` | Import requirements and user stories from CSV in the `export_backlog` format. Story-to-requirement links are not restored | \n| `open_dashboard` | Start the live, read-only dashboard and return its local address | \n| `export_dashboard` | Write a static HTML snapshot of the dashboard to `data/exports/dashboard.html` | \n\n**Jira**\n\n| Tool | What it does | \n|---|---|\n| `push_to_jira` | Create Jira issues for a project (Task per requirement, Story per user story). Dry-run by default; `limit` sends a subset;`update` refreshes issues already linked; items already sent are skipped | \n| `sync_from_jira` | Mark requirements and stories done when their Jira issue is done, and reopen them when it goes back. Items closed by hand in Yeti are not reopened. Read-only on Jira | \n\nRequirements, stories, RICE scores and flows accept an optional `projectId` to link them to a project.\n\nYou need Node.js 22.13 or later (Yeti uses the built-in `node:sqlite` module).\n\n```\ngit clone https://github.com/macorifice/yeti.git\ncd yeti\nnpm install\nnpm run build\n```\n\nThen add it to `claude_desktop_config.json`, using the absolute path to `dist/index.js` on your machine:\n\n```\n{\n  \"mcpServers\": {\n    \"yeti\": {\n      \"command\": \"node\",\n      \"args\": [\"/absolute/path/to/yeti/dist/index.js\"]\n    }\n  }\n}\n```\n\nRestart Claude Desktop after editing the file.\n\nOnce connected, you work with Yeti by talking to Claude. A typical project looks like this.\n\n**1. Create a project**\n\nCreate a project \"Quotes for craftsmen\". Problem: writing quotes takes hours. Users: plumbers and painters. Goal: a quote in five minutes.\n\nYeti creates the project in the `discovery` phase.\n\n**2. Move through the phases**\n\n- **definition** : add at least one requirement and one user story linked to it.\n- **prioritization** : score the ideas with RICE.\n- **flows** : draw at least one flow diagram.\n- **verification** : every`must` requirement is done and covered by a user story.\n\nIn `strict` mode (the default), Yeti will not advance until the phase is complete, and it tells you what is missing. In `free` mode, it advances and lists what it skipped. You can switch with `set_project_mode`.\n\n**3. Work on the backlog**\n\n- Edit or delete requirements and stories.\n- Mark acceptance criteria as done.\n- Search across a project.\n- Duplicate a project to reuse it as a template.\n- Import requirements from a CSV file.\n\n**4. Export**\n\nExport the project backlog as Markdown and save it to a file.\n\nWith `save: true`, the file is written to `data/exports/` next to the database.\n\n**Good to know**\n\n- Data is stored locally, in `data/yeti.sqlite` . The content still passes through the chat, so do not put sensitive data in it.\n- RICE scores are the numbers you enter. Yeti sorts them; it does not estimate them.\n\nA small project from requirements to Jira, using the Mastro example: creating the project, requirements and user stories, RICE prioritisation, a flow diagram, the verification gate, sending to Jira, and keeping the status in sync.\n\nYeti has a read-only dashboard for the design side of your projects: the phase each project is in, what is missing to move on, which musts are covered by user stories, acceptance criteria, RICE scores and flow diagrams. It does not show a task board: execution belongs in Jira.\n\nOpen it from Claude:\n\nOpen the Yeti dashboard.\n\nClaude calls `open_dashboard` and gives you an address such as `http://127.0.0.1:4321`. Or start it from a terminal:\n\n```\nnpx yeti-mcp dashboard --port 4321\n```\n\n- It listens on `127.0.0.1` only, so it is not reachable from other machines, and it refuses requests for other host names.\n- It reads the same database as the MCP server and refreshes every 10 seconds.\n- Jira keys become links when `JIRA_SITE` is set.\n- Diagrams are drawn with Mermaid, loaded from a CDN. Without a connection they are shown as text.\n\n`export_dashboard` still writes a static snapshot to `data/exports/dashboard.html`, for sharing.\n\nYeti works without any account. Only one tool talks to an external service:\n\n- **Everything else** (projects, requirements, stories, RICE, flows, verification, export, search) runs locally and needs no credentials.\n- **`push_to_jira`** creates issues in Jira. It needs three environment variables:\n\n| Variable | Value | \n|---|---|\n| `JIRA_SITE` | Your Jira site, e.g. `https://your-team.atlassian.net` | \n| `JIRA_EMAIL` | The email of your Atlassian account | \n| `JIRA_API_TOKEN` | An API token created at [id.atlassian.com](https://id.atlassian.com) → Security → API tokens | \n\nSet them in your shell profile, for example in `~/.zshrc`:\n\n```\nexport JIRA_SITE=\"https://your-team.atlassian.net\"\nexport JIRA_EMAIL=\"you@example.com\"\nexport JIRA_API_TOKEN=\"your-token-here\"\n```\n\nNever put the token in the repository, in a config file you commit, or in a chat. If a token is exposed, revoke it in the same page and create a new one.\n\nWithout these variables, `push_to_jira` refuses to send and tells you which one is missing. Dry-run previews work without them as well.\n\nData is stored in SQLite. From a source checkout the default is `data/yeti.sqlite` inside the project folder; with `npx`, set `PRODUCT_DESIGN_DB` as shown in the quick start. Earlier versions used `data/db.json`: it is imported automatically the first time the new version runs, and then left untouched. To use another location, set the `PRODUCT_DESIGN_DB` environment variable:\n\n```\n\"env\": { \"PRODUCT_DESIGN_DB\": \"/absolute/path/to/yeti.sqlite\" }\nnpm test\n```\n\nThe test starts the server on a temporary database and checks every tool and the phase flow.\n\nStable since 1.0.0. The tools, their inputs and the data format are covered by semantic versioning: breaking changes will come with a new major version.\n\nIf Yeti is useful to you, you can support its development through [GitHub Sponsors](https://github.com/sponsors/macorifice).\n\nMIT. See [LICENSE](https://github.com/macorifice/yeti/blob/main/LICENSE).", "url": "https://wpnews.pro/news/yeti-an-mcp-server-that-guides-product-design-from-requirements-to-jira", "canonical_source": "https://github.com/macorifice/yeti", "published_at": "2026-10-24 11:53:26+00:00", "updated_at": "2026-10-24 12:11:08.980319+00:00", "lang": "en", "topics": ["ai-agents", "agent-protocols", "ai-tools", "developer-tools"], "entities": ["Yeti", "yeti-mcp", "Claude", "Claude Desktop", "Jira", "Model Context Protocol", "Node.js", "Mermaid"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/yeti-an-mcp-server-that-guides-product-design-from-requirements-to-jira", "markdown": "https://wpnews.pro/news/yeti-an-mcp-server-that-guides-product-design-from-requirements-to-jira.md", "text": "https://wpnews.pro/news/yeti-an-mcp-server-that-guides-product-design-from-requirements-to-jira.txt", "jsonld": "https://wpnews.pro/news/yeti-an-mcp-server-that-guides-product-design-from-requirements-to-jira.jsonld"}}