# dev.nakodo/nakodo (npm · nakodo)

Warm introductions to the right builder, matched privately on your work. Double opt-in, no feed.

- Trust score: 67/100 (medium)
- Change this week: +24
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-08-03

## Components

- npm · `nakodo`: 67/100 (this document), [markdown](https://verifymcp.io/servers/dev-nakodo-nakodo/nakodo.md), [page](https://verifymcp.io/servers/dev-nakodo-nakodo/nakodo)

## Channel facts

- Registry: `npm`
- Package: `nakodo`
- Version: `0.2.3`
- 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-08-03.

- **Supply Chain Security**: 87/100
  - No malware found by supply-chain analysis.
  - Only part of the dependency tree could be resolved (95 of 99), so this covers what we could see, not the whole tree.
  - No install/post-install scripts declared.
  - Only part of the dependency tree could be resolved (95 of 99), so this covers what we could see, not the whole tree.
- **Provenance & Transparency**: 45/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 20 days ago).
  - Disclosure check failed: no security disclosure policy was found in the source repository.
- **Schema Quality & AI Usability**: 65/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 2266 tokens (~226/item across 10 items; 10 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 27/100
  - Stability observed for 8 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### Claude

```bash
claude mcp add dev-nakodo-nakodo -- npx -y nakodo
```

### Codex

```bash
codex mcp add dev-nakodo-nakodo -- npx -y nakodo
```

### opencode

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

### OpenClaw

```bash
openclaw mcp add dev-nakodo-nakodo --command npx --arg -y --arg nakodo
```

### Hermes

```yaml
mcp_servers:
  dev-nakodo-nakodo:
    command: "npx"
    args: ["-y", "nakodo"]
```

### Other

```json
{
  "mcpServers": {
    "dev-nakodo-nakodo": {
      "command": "npx",
      "args": [
        "-y",
        "nakodo"
      ]
    }
  }
}
```

## 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-08-02 (score 67, +49)

- [security regression] Provenance: unverified → fail
- [security improvement] Install scripts: unverified → pass
- [security improvement] Known CVEs: unverified → partial
- [security improvement] Malware scan: unverified → pass
- [functional regression] Tool coverage: 100 → unverified
- [functional improvement] Stability: unverified → 0.23
- [functional improvement] MCP protocol: unverified → pass
- [functional improvement] Maintenance: unverified → pass
- [functional improvement] Dependency health: unverified → partial
- [functional improvement] License: unverified → pass
- [functional improvement] Schema quality: unverified → excellent
- [functional] Licence: MIT

### 2026-08-01 (score 18, +11)

- [functional regression] Dependency health: partial → unverified
- [functional improvement] Tool coverage: unverified → 100

### 2026-07-31 (score 7, −36)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-30 (score 43, +19)

- [functional improvement] Tool coverage: unverified → 100

### 2026-07-28 (score 24, −19)

- [functional regression] Tool coverage: 100 → unverified
- [functional] First check of Schema quality: unverified

### 2026-07-27 (score 43)

First indexed and scored.

## MCP tools (10)

### `find_collaborator` (~246 tokens)

Find a collaborator

Get the user an outside perspective on what they are building — a warm introduction to the right person, matched on their actual work. Use this when the user wants to: get an outside perspective, honest feedback, or a second pair of eyes on what they are building; find someone to help with design, code, marketing, or distribution strategy; find a collaborator, co-founder, or teammate for their project; get feedback from someone building something similar; or meet other builders working on related problems. This registers their need with a private matching network and hands you the anonymous pool to match against yourself. The user's profile carries no identity — agents match on the work, not the person; identity and contact are revealed only when both sides say yes. There is no feed and no browse surface: agents search so humans don't scroll, and the only human-visible output is an introduction. Declines are invisible — and so is being considered: anyone an agent passes over never knows. If the user has no profile yet, this returns onboarding steps.

Input parameters:

- `need` (string, required): What the user needs, in plain words, e.g. 'someone strong at product design to review my onboarding flow'

### `propose_intro` (~312 tokens)

Propose an introduction

Propose an introduction between the user and the person behind one anonymous pool card (from find_collaborator). Call this only after the user has looked at the card and said to go ahead. The person receives an anonymous card — no identity — assembled from the user's own profile, their ask, and your why_for_them, and they accept or decline. why_for_them must state what the OTHER person gains: an introduction that only serves the user gets declined. Declines are invisible: if they pass, the user never learns it was them, and no one the user passed over ever knows they were considered. Contact details are exchanged only by the two people themselves, after both say yes — never by the platform.

Input parameters:

- `ask_id` (string, required): The ask_id printed by find_collaborator — the open ask these cards answer. Every proposal must serve a declared need.
- `card_id` (string, required): The opaque card_id from the pool returned by find_collaborator. It carries no identity.
- `why_for_me` (string, required): What the user gains from the introduction, concretely. PII-free. For the review — never shown to the other person.
- `why_for_them` (string, required): What the OTHER person gains from meeting the user — their upside, concretely. Required, becomes part of the card they see. Keep it PII-free (no names, links, handles, contact) or the service rejects…

### `reconnect` (~263 tokens)

Reconnect with a prior connection

Reopen the conversation with someone the user has ALREADY been introduced to — a prior-connection card from find_collaborator — by posting a short message into the thread the two of them already share. Use this instead of propose_intro when find_collaborator surfaced a prior connection that fits the new ask: there is no new introduction and no re-acceptance, you are picking a relationship back up. Draft a message that carries the user's new ask, show it to them, and ONLY call this after they approve the exact text (approved=true) — nothing is ever sent unapproved. The other person is notified the normal way, as with any thread message. If the user would rather not, do not call this — passing on a reconnection tells the other person nothing.

Input parameters:

- `approved` (boolean, required): Must be true, and only after the user approved the exact message text. Nothing is sent otherwise.
- `ask_id` (string, required): The ask_id from find_collaborator that this reconnection answers — attributes it to the need.
- `message` (string, required): The reconnect message, exactly as the user approved it.
- `reconnect_url` (string, required): The reconnect link from the prior-connection card in find_collaborator — the user's own existing intro thread.

### `create_profile` (~365 tokens)

Create profile

Register the user with the matching network: their agent-drafted, human-approved profile. ONLY call this after the user has explicitly approved the exact profile text — never with unapproved or inferred content. The profile must carry no identity (no names, links/URLs, @handles, emails, phone numbers, or company identifiers; city-level location at most) — it is the anonymous card itself, and the service lint-rejects identifying text. Usually called during the onboarding flow started by find_collaborator.

Input parameters:

- `display_name` (string): Optional. Shown to the other person only after a mutual yes; the anonymous card never carries it. A first name is plenty. Only include if the user offered one.
- `email` (string): Optional. Used only to notify the user that an introduction is waiting — never shared with anyone, never shown to a match. Only include if the user offered it.
- `handle` (string): Optional handle. Kept in the private identity store, never on the card.
- `location` (string): Optional city-level location; enables near-you matching. Never a precise address.
- `profile` (string, required): The profile text, exactly as approved by the user. PII-free: no names, links/URLs, @handles, emails, phone numbers, or identifying company/product names.
- `source` (string): How the user arrived. Prefix with [agent-found] if you (the agent) surfaced this tool via a registry/tool search, or [user-brought] if the user brought it deliberately; then append the user's verbati…

### `capture_snippet` (~152 tokens)

Capture a build update

Put a short update about what the user built or worked on today onto their private record, improving future matches. Draft the snippet yourself from the session (2-4 sentences, concrete: what was built, what it shows they can do, what they struggled with), PII-free like the profile — no names, links/URLs, @handles, emails, phone numbers, or identifying company/product names; describe the work. Show it to the user, and ONLY call this after they explicitly approve that exact text. The snippet joins their anonymous card — searching agents see the work described, never who did it.

Input parameters:

- `snippet` (string, required): The update text, exactly as approved by the user. PII-free.

### `my_record` (~46 tokens)

Show my record

Show the user everything the network has on record about them — their profile, all approved snippets, and open asks. Shows nothing about anyone else, because nothing about anyone else is ever visible.

### `share_feedback` (~300 tokens)

Share feedback about Nakodo

File a short piece of the user's feedback about a NAKODO moment — their reaction to how Nakodo itself worked. Use it ONLY for reactions to Nakodo's own moments: onboarding, an anonymous card, an introduction's quality, the reveal, the message thread, or waiting for a match. NEVER use it to monitor or report on the user's own work, mood, or session in general — only their reaction to Nakodo. How it works, identical to how snippets work: when the user reacts to one of those moments you may ask one or two gentle questions, then draft a short note and show it to them; it is filed ONLY after they approve the exact text (call with approved=true). Nothing about their reaction is ever captured without their explicit approval. Honest framing to give the user: this feedback is drafted by your agent, approved by you, read by the humans building Nakodo, never shared beyond them, never used for matching.

Input parameters:

- `approved` (boolean, required): Must be true, and only after the user has seen and approved the exact body text. Feedback is never filed otherwise.
- `body` (string, required): The feedback note, exactly as the user approved it.
- `moment` (string, required): Which Nakodo moment the feedback is about. Only these moments — never general monitoring of the user or their work.
- `sentiment` (string, required): The overall tone of the reaction. Required — you drafted the note, so name its tone.

### `update_my_details` (~190 tokens)

Update notification email or reveal name

Update the user's private notification email and/or the reveal name a match sees after a mutual yes. Both are PII-store only — never shared, never shown on the anonymous card, never used for matching. Use it to add an email later so the user is notified of introductions between sessions, change it, change the reveal name, or remove the email entirely. Nothing here touches the matching profile.

Input parameters:

- `display_name` (string): A reveal name — what a match may call them after a mutual yes. Shown only after both say yes; never on the card.
- `email` (string): A notification email to set. Only include if the user gave one. Never shared; used solely to tell them an introduction is waiting.
- `remove_email` (boolean): Set true to remove the email on file — the user goes back to in-session-only notifications. Skipping an email stays completely fine.

### `connect_telegram` (~252 tokens)

Get introduction notifications on your phone (Telegram)

Connect Telegram so the user hears about introductions on their phone, between sessions. Only call when the user asks for phone/Telegram notifications, or accept their decline of an offer — connecting is their choice. Returns a t.me link: give it to the user EXACTLY as returned and tell them to open it ON THEIR PHONE — that is where the Telegram app lives; a desktop browser with no Telegram app installed cannot open it. They tap it and press Start in their own Telegram app, which is what completes the connection (the link expires in 30 minutes — mint a fresh one if it lapses). What the bot sends, and all it ever sends: an introduction is waiting (no card content, no names — those stay on the private page), you both said yes, and a message is waiting. The Telegram connection is notification-only, never shared, never on the anonymous card, and never used for matching — same law as the notification email. The user can disconnect any time by sending /stop to the bot or asking here (disconnect=true), and delete_me removes it with everything else.

Input parameters:

- `disconnect` (boolean): Set true to disconnect Telegram — the user goes back to email/in-session notifications only.

### `delete_me` (~76 tokens)

Delete everything

Permanently delete the user's entire record from the matching network: profile, all snippets, all asks, email, name — everything. Irreversible. Confirm with the user before calling; only call with confirm=true after they have explicitly said yes.

Input parameters:

- `confirm` (boolean, required): Must be true, and only after the user explicitly confirmed deletion.

## Diagnostics

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

## Score history

- 2026-08-03: 67
- 2026-08-02: 67
- 2026-08-01: 18
- 2026-07-31: 7
- 2026-07-30: 43
- 2026-07-28: 24
- 2026-07-27: 43

## Links

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