# Yeti (npm · yeti-mcp)

Product design with Claude: phases, requirements, user stories, RICE, flows, dashboard, Jira.

- Trust score: 71/100 (medium)
- Change this week: +6
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-11-04

## Components

- npm · `yeti-mcp`: 71/100 (this document), [markdown](https://verifymcp.io/servers/macorifice-yeti/yeti-mcp.md), [page](https://verifymcp.io/servers/macorifice-yeti/yeti-mcp)

## Channel facts

- Registry: `npm`
- Package: `yeti-mcp`
- Version: `1.1.0`
- 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-11-04.

- **Supply Chain Security**: 98/100
  - No malware found by supply-chain analysis.
  - No known CVEs affecting this package version or its production dependencies.
  - No install/post-install scripts declared.
  - 30 of 92 dependencies flagged as unhealthy.
- **Provenance & Transparency**: 48/100
  - Source repository is publicly reachable at the declared URL.
  - Provenance check failed: no build-provenance attestation is published.
  - Clear OSI-approved license (MIT).
  - Actively maintained (last published 4 days ago).
  - Publishes a security disclosure policy (SECURITY.md).
- **Schema Quality & AI Usability**: 65/100
  - AI-judged instruction clarity (good).
  - Tool/resource definitions use about 2164 tokens (~61/item across 35 items; 35 tools + 0 resources), lean.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 37/100
  - Stability observed for 11 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 79/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 36% of tool parameters carry a description.
- **Tool Safety**: 75/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - 0 of 4 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation; "delete_requirement" implies "delete" and declares no destructiveHint at all, which the MCP spec reads as destructive by default.
  - An AI judge read all 35 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

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

Yeti runs locally as an npm package, launched with npx -y yeti-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 macorifice-yeti -- npx -y yeti-mcp
```

### Cursor

```json
{
  "mcpServers": {
    "macorifice-yeti": {
      "command": "npx",
      "args": [
        "-y",
        "yeti-mcp"
      ]
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "macorifice-yeti": {
      "command": "npx",
      "args": [
        "-y",
        "yeti-mcp"
      ]
    }
  }
}
```

### Codex

```bash
codex mcp add macorifice-yeti -- npx -y yeti-mcp
```

### opencode

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

### OpenClaw

```bash
openclaw mcp add macorifice-yeti --command npx --arg -y --arg yeti-mcp
```

### Hermes

```yaml
mcp_servers:
  macorifice-yeti:
    command: "npx"
    args: ["-y", "yeti-mcp"]
```

### Netclaw

```json
{
  "McpServers": {
    "macorifice-yeti": {
      "Transport": "stdio",
      "Command": "npx",
      "Arguments": [
        "-y",
        "yeti-mcp"
      ]
    }
  }
}
```

### Vellum

```bash
assistant mcp add macorifice-yeti -t stdio -c npx -a -y yeti-mcp
```

### Other

```json
{
  "mcpServers": {
    "macorifice-yeti": {
      "command": "npx",
      "args": [
        "-y",
        "yeti-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-11-04 (score 71, +1)

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

### 2026-11-02 (score 70, +1)

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

### 2026-11-01 (score 69, +1)

- [functional improvement] Security disclosure: fail → pass

### 2026-10-31 (score 68, +15)

- [security improvement] Malware scan: unverified → pass

### 2026-10-30 (score 53, −12)

- [security regression] Malware scan: pass → unverified
- [functional regression] Schema quality: 1940 → 2164
- [functional improvement] Stability: unverified → 0.20
- [functional] Package version: 1.0.3 → 1.1.0

### 2026-10-26 (score 65, 0)

- [functional regression] Security disclosure: unverified → fail

### 2026-10-25 (score 65, +15)

- [security improvement] Malware scan: unverified → pass
- [functional regression] Security disclosure: fail → unverified

### 2026-10-24 (score 50)

First indexed and scored.

## MCP tools (35)

### `create_project` (~107 tokens)

Create a design project. It starts in the 'discovery' phase: problem, users and goal are required. Mode 'strict' (default) blocks advancing until each phase is complete; 'free' allows advancing and reports what was skipped.

Input parameters:

- `goal` (string, required): What the user or business should achieve
- `mode` (string)
- `name` (string, required)
- `problem` (string, required): The problem it solves
- `users` (string, required): Who it is for

### `list_projects` (~59 tokens)

List projects with their id, name, phase and status. Use it to find a projectId.

Input parameters:

- `includeArchived` (boolean): Set to true to also list archived projects
- `includeClosed` (boolean): Set to false to hide closed projects

### `update_requirement` (~54 tokens)

Change a requirement's title, description or priority. Only the fields you pass are changed.

Input parameters:

- `description` (string)
- `id` (integer, required)
- `priority` (string)
- `title` (string)

### `delete_requirement` (~35 tokens)

Delete a requirement. It is also removed from the requirementIds of any user story that covered it.

Input parameters:

- `id` (integer, required)

### `delete_user_story` (~21 tokens)

Delete a user story.

Input parameters:

- `id` (integer, required)

### `set_criterion_status` (~60 tokens)

Mark one acceptance criterion of a user story as done or not done. The index is 0-based, in the order of the criteria.

Input parameters:

- `done` (boolean, required)
- `index` (integer, required)
- `storyId` (integer, required)

### `archive_project` (~44 tokens)

Archive or unarchive a project. Archived projects are hidden from list_projects by default. Nothing is deleted.

Input parameters:

- `archived` (boolean)
- `projectId` (integer, required)

### `set_project_mode` (~43 tokens)

Change a project's mode: 'strict' or 'free'. Applies from the next phase change.

Input parameters:

- `mode` (string, required)
- `projectId` (integer, required)

### `update_project` (~63 tokens)

Change a project's name, problem, users or goal. Only the fields you pass are changed.

Input parameters:

- `goal` (string)
- `name` (string)
- `problem` (string)
- `projectId` (integer, required)
- `users` (string)

### `search_items` (~51 tokens)

Search requirements and user stories by text (case-insensitive). Optionally limit to one project.

Input parameters:

- `projectId` (integer): Id of the project to link this item to
- `query` (string, required)

### `duplicate_project` (~63 tokens)

Create a new project from an existing one, copying its requirements and user stories as open items. Useful as a template for a new client or product. Statuses and RICE scores are not copied.

Input parameters:

- `name` (string, required)
- `projectId` (integer, required)

### `import_requirements` (~76 tokens)

Import requirements and user stories from CSV text, in the format produced by export_backlog. Requirement rows need type and title; story rows need persona, goal, benefit and criteria (separated by ' | '). Story-to-requirement links are not restored.

Input parameters:

- `csv` (string, required)
- `projectId` (integer, required)

### `push_to_jira` (~130 tokens)

Create Jira issues for a project: one Task per requirement and one Story per user story. Items already sent are skipped. With update: true, also refreshes the issues already linked. dryRun (default true) only lists what would be sent.

Input parameters:

- `dryRun` (boolean)
- `limit` (integer): Send at most this many new issues; useful to test with one
- `projectId` (integer, required)
- `projectKey` (string, required): Jira project key, e.g. PROJ
- `update` (boolean): Also update issues already linked to a requirement or story

### `sync_from_jira` (~56 tokens)

Read the status of linked Jira issues and mark items done in Yeti when their Jira issue is done. Requirements become done; stories get all their criteria ticked. Read-only on Jira.

Input parameters:

- `projectId` (integer, required)

### `project_summary` (~52 tokens)

Summarise a project's progress: requirements by priority and status, story coverage of musts, acceptance criteria done, RICE leader, Jira links and what is missing to close.

Input parameters:

- `projectId` (integer, required)

### `list_stories` (~53 tokens)

List user stories, optionally for one project, with their ids, criteria state and Jira key. Use it to find a storyId.

Input parameters:

- `projectId` (integer): Id of the project to link this item to

### `delete_project` (~59 tokens)

Permanently delete a project with its requirements and user stories. Requires confirm: true. This cannot be undone; issues already created in Jira are not touched.

Input parameters:

- `confirm` (boolean, required): Must be true to delete
- `projectId` (integer, required)

### `update_user_story` (~85 tokens)

Change a user story's persona, goal, benefit, linked requirements or acceptance criteria. Only the fields you pass change. Changing the criteria resets their done state.

Input parameters:

- `acceptanceCriteria` (array)
- `benefit` (string)
- `goal` (string)
- `id` (integer, required)
- `persona` (string)
- `requirementIds` (array)

### `list_flows` (~39 tokens)

List the flow diagrams saved in a project, with their index. Use the index to refer to a diagram.

Input parameters:

- `projectId` (integer, required)

### `delete_flow` (~41 tokens)

Delete one saved flow diagram from a project, by the index shown by list_flows.

Input parameters:

- `index` (integer, required)
- `projectId` (integer, required)

### `export_dashboard` (~64 tokens)

Write a read-only HTML dashboard to data/exports/dashboard.html: phases, what is missing, musts covered by stories, RICE scores and flow diagrams. Open the file in a browser.

Input parameters:

- `projectId` (integer): Id of the project to link this item to

### `open_dashboard` (~70 tokens)

Start the local, read-only Yeti dashboard and return its address (http://127.0.0.1:...). It shows phases, what is missing, musts and their stories, RICE and flows, and refreshes by itself. It runs on this computer only, while Yeti runs.

### `add_decision` (~97 tokens)

Record a design decision for a project: what was chosen, why, and which alternatives were rejected. Decisions are kept with the project, so the reasons outlive the chat.

Input parameters:

- `alternatives` (string): What was considered and rejected
- `decision` (string, required): What was chosen
- `projectId` (integer, required)
- `reason` (string, required): Why it was chosen
- `title` (string, required): Short name of the decision

### `list_decisions` (~29 tokens)

List the design decisions recorded for a project, oldest first.

Input parameters:

- `projectId` (integer, required)

### `list_templates` (~32 tokens)

List the starter project templates: a marketplace MVP and a customer self-service portal. Use one with create_project_from_template.

### `create_project_from_template` (~66 tokens)

Create a project from a starter template. It starts in discovery with its requirements and user stories open, linked to each other. Adapt them afterwards with the usual tools.

Input parameters:

- `name` (string): Project name; defaults to the template name
- `templateId` (string, required)

### `get_project` (~34 tokens)

Show a project's status: current phase, what is missing to advance, and linked items.

Input parameters:

- `projectId` (integer, required)

### `advance_phase` (~61 tokens)

Move to the next phase. In 'strict' mode, it lists what is missing and does not advance. In 'free' mode, it advances and reports what was skipped. After 'verification' it closes the project.

Input parameters:

- `projectId` (integer, required)

### `add_requirement` (~76 tokens)

Record a product requirement with a MoSCoW priority (must, should, could, wont).

Input parameters:

- `description` (string, required): What the system must do and why
- `priority` (string)
- `projectId` (integer): Id of the project to link this item to
- `title` (string, required): Short requirement title

### `list_requirements` (~56 tokens)

List requirements, optionally filtered by priority, status and project. Most important first.

Input parameters:

- `priority` (string)
- `projectId` (integer): Id of the project to link this item to
- `status` (string)

### `set_requirement_status` (~31 tokens)

Mark a requirement as open or done.

Input parameters:

- `id` (integer, required)
- `status` (string, required)

### `add_user_story` (~126 tokens)

Create a user story in the format 'As a <persona> I want <goal> so that <benefit>', with acceptance criteria.

Input parameters:

- `acceptanceCriteria` (array, required): Verifiable conditions that define done
- `benefit` (string, required): Why they want it
- `goal` (string, required): What they want to do
- `persona` (string, required): Who uses the feature, e.g. 'craftsman'
- `projectId` (integer): Id of the project to link this item to
- `requirementIds` (array): Ids of the requirements this story covers

### `prioritize_rice` (~68 tokens)

Compute RICE scores (Reach × Impact × Confidence ÷ Effort) for a list of ideas and sort them. With projectId, saves the result to the project.

Input parameters:

- `items` (array, required)
- `projectId` (integer): Id of the project to link this item to

### `map_user_flow` (~105 tokens)

Generate a Mermaid flowchart from a list of steps. Steps are linked in order; a decision (diamond) gets a 'Yes' edge to the next step, or to 'yes' if set, and a 'No' edge to 'no' if set. With projectId, saves the diagram to the project.

Input parameters:

- `name` (string, required)
- `projectId` (integer): Id of the project to link this item to
- `steps` (array, required)

### `export_backlog` (~58 tokens)

Export a project backlog as Markdown or CSV: requirements (most important first) and user stories.

Input parameters:

- `format` (string)
- `projectId` (integer, required)
- `save` (boolean): Also write the file to data/exports/

## Diagnostics

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

## Score history

- 2026-11-04: 71
- 2026-11-03: 70
- 2026-11-02: 70
- 2026-11-01: 69
- 2026-10-31: 68
- 2026-10-30: 53
- 2026-10-29: 65
- 2026-10-28: 65
- 2026-10-27: 65
- 2026-10-26: 65
- 2026-10-25: 65
- 2026-10-24: 50

## Common questions

### What is the Yeti MCP server?

Yeti is an MCP server listed in the public MCP registry as io.github.macorifice/yeti. Product design with Claude: phases, requirements, user stories, RICE, flows, dashboard, Jira. This page covers its npm package (yeti-mcp).

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

Yeti scores 71 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 4 November 2026. 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 Yeti MCP server expose?

Yeti exposes 35 tools: create_project, list_projects, update_requirement, delete_requirement, delete_user_story, and 30 more. Their descriptions and schemas cost roughly 2,164 tokens of context every time the server is loaded.

### Is the Yeti MCP server still maintained?

Yeti is still listed as active in the MCP registry. We last reached this channel on 4 November 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 Yeti MCP server under?

Yeti declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.

## Links

- npm package: https://www.npmjs.com/package/yeti-mcp
- Socket report: https://socket.dev/npm/package/yeti-mcp
- Repository: https://github.com/macorifice/yeti
- Changelog RSS feed: https://verifymcp.io/servers/macorifice-yeti/yeti-mcp.xml
- Changelog JSON feed: https://verifymcp.io/servers/macorifice-yeti/yeti-mcp.json
- HTML version of this page: https://verifymcp.io/servers/macorifice-yeti/yeti-mcp