# io.github.codellyson/passalong (npm · passalong)

Hand tasks, bugs and finished work to AI coding agents, and get back a write-up with evidence.

- Trust score: 78/100 (medium)
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-10-04

## Components

- remote · `passalong.dev`: 36/100, [markdown](https://verifymcp.io/servers/codellyson-passalong/v1-mcp.md), [page](https://verifymcp.io/servers/codellyson-passalong/v1-mcp)
- npm · `passalong`: 78/100 (this document), [markdown](https://verifymcp.io/servers/codellyson-passalong/passalong.md), [page](https://verifymcp.io/servers/codellyson-passalong/passalong)

## Channel facts

- Registry: `npm`
- Package: `passalong`
- Version: `0.13.1`
- 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-10-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.
  - 31 of 93 dependencies flagged as unhealthy.
- **Provenance & Transparency**: 97/100
  - Source repository is publicly reachable at the declared URL.
  - Cryptographically verified build provenance (signed, bound to codellyson/passalong).
  - Clear OSI-approved license (MIT).
  - Actively maintained (last published 1 days ago).
  - Disclosure check failed: no security disclosure policy was found in the source repository.
- **Schema Quality & AI Usability**: 64/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 5242 tokens (~249/item across 21 items; 21 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 0/100
  - Stability not yet verified: not enough scan history yet (needs a 30-day window).
- **Tool Coverage**: 98/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 93% of tool parameters carry a description.
  - Structured output schemas are declared (19% of tools); any adoption earns full credit.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - All 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.
  - An AI judge read all 22 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.

**Unverified: 1 category.** A category scored 0 because we could not verify it: a data source with nothing on this package, evidence we could not reach, or a check we could not run. We only credit what we can confirm.

## Install

### How do I install the io.github.codellyson/passalong MCP server?

io.github.codellyson/passalong runs locally as an npm package, launched with npx -y passalong. 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 codellyson-passalong -- npx -y passalong
```

### Cursor

```json
{
  "mcpServers": {
    "codellyson-passalong": {
      "command": "npx",
      "args": [
        "-y",
        "passalong"
      ]
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "codellyson-passalong": {
      "command": "npx",
      "args": [
        "-y",
        "passalong"
      ]
    }
  }
}
```

### Codex

```bash
codex mcp add codellyson-passalong -- npx -y passalong
```

### opencode

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

### OpenClaw

```bash
openclaw mcp add codellyson-passalong --command npx --arg -y --arg passalong
```

### Hermes

```yaml
mcp_servers:
  codellyson-passalong:
    command: "npx"
    args: ["-y", "passalong"]
```

### Netclaw

```json
{
  "McpServers": {
    "codellyson-passalong": {
      "Transport": "stdio",
      "Command": "npx",
      "Arguments": [
        "-y",
        "passalong"
      ]
    }
  }
}
```

### Vellum

```bash
assistant mcp add codellyson-passalong -t stdio -c npx -a -y passalong
```

### Other

```json
{
  "mcpServers": {
    "codellyson-passalong": {
      "command": "npx",
      "args": [
        "-y",
        "passalong"
      ]
    }
  }
}
```

## 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-10-03 (score 78, +15)

- [security improvement] Malware scan: unverified → pass

### 2026-10-02 (score 63)

First indexed and scored.

## MCP tools (21)

### `assign` (~130 tokens)

Give it to someone else

Reassign a guide or task the user wrote, or one assigned to them, to someone else in its team, when the user asks: `to` is @handle for one person, #group for the people who do a thing, or "team" for everyone. Whoever held it and is left out has it taken back and is told; a task then only goes to the new assignee's agents. Its author, or whoever it is assigned to, can do this.

Input parameters:

- `id` (string, required): passalong id
- `to` (string, required): "@handle", "#group", or "team"

### `search_guides` (~75 tokens)

Search guides

Search transfer guides by words in the title, tags, stack, or body: the user's own (local and synced) plus every team they belong to. Empty query lists everything, newest first.

Input parameters:

- `query` (string)
- `scope` (string): "mine", "all" (default), or a team slug

### `inbox` (~44 tokens)

Inbox

Guides handed to this user (or to their teams) that they have not pulled yet. Call it when starting work so handoffs are not missed. Needs sync (passalong login).

### `board` (~84 tokens)

Board

The state of this user's transfers as queues: waiting on you (handed to you, not pulled), not working (someone gave it a failing verdict — the most urgent), in flight (handed over, nobody has taken it — `stale` means it has sat over a week), and landed (someone else has it). Use it to answer 'what is outstanding?'.

### `log` (~205 tokens)

What this user did

This user's own acts on guides, newest first: what they published, what they took delivery of, and every verdict and ack they gave. Each item has a rendered `text` line and the guide's repo. Use it to answer 'what have I been working on', to write a standup or a weekly summary, or to find work from a repo by when it happened rather than by what it was called. This is the opposite of `activity`, which is what other people did. IMPORTANT: it records what was passed along, not what was worked on — work that never became a guide has no entry, so never present it as a complete record of this user's work, and never infer that a quiet period was an idle one.

Input parameters:

- `repo` (string): narrow to guides whose source repo matches this
- `since` (string): only what happened on or after this date: 2026, 2026-09, or 2026-09-11

### `activity` (~74 tokens)

Activity

What has happened to this user's guides and handoffs: who pulled one, who archived one, who was handed what, who joined a team. Each item has a ready-made `text` line. This only reads; clear_activity is what marks the feed seen.

Input parameters:

- `all` (boolean): include what the user has already seen

### `clear_activity` (~39 tokens)

Mark activity seen

Clear the user's unread feed, after they have been shown what is in it. Read it with activity first — clearing what nobody was told about loses it.

### `plan_tasks` (~152 tokens)

Plan a goal as tasks

Write tasks for agents: one step for a single task, or a larger goal broken into steps an agent can each finish and a person can each check, written as drafts in order. The tool for any task, rather than publish_guide. Give each step a Goal and an Acceptance a person can run. `after` names the earlier steps (by position, from 0) a step needs; it waits for them to be approved, and steps that need nothing of each other can run side by side. Keep a step to one sitting of work in one repo. Nothing runs until the user makes them ready.

Input parameters:

- `cwd` (string): the repo you are planning from
- `steps` (array, required)

### `take` (~183 tokens)

Take work

Say you are doing it, and get it. With `id`, that guide — any kind: a task, a bug, a handoff. With no id, the next thing waiting for this worktree's agent. While you hold it no other agent can take it here, and its sender sees you are on it. One thing at a time: if you already hold something, finish or pass that first. If somebody else has it, the answer says who — tell the user rather than doing the work twice. Every answer ends with what to call next.

Input parameters:

- `any` (boolean): a task for another repo, or none — only when the user asks
- `cwd` (string): the worktree you are working in; default is the server's cwd
- `id` (string): passalong id or share link; leave out for the next one

### `progress` (~128 tokens)

Report progress

Say you are still on what you hold, with a one-line note the hub shows. 30 minutes without one marks it stalled. If the answer says you no longer hold it, stop.

Input parameters:

- `cwd` (string): the worktree you are working in; default is the server's cwd
- `id` (string, required): the id of what you hold
- `note` (string): one plain sentence in the first person, as you would tell the person: "Reading the settings page to find where the toggle goes." Start it with BLOCKED: when you are stopped and need an answer

Output parameters:

- `id` (string)
- `lease_until` (string)
- `note` (string)

### `hand_in` (~756 tokens)

Hand it in

Done here, with proof, sorted against the line it answers. Send `checks`: one entry per line the guide asks for — `## Acceptance` on a task, `## Verification` on a handoff or a bug — each with that line and the evidence for it. That is what its author reads, line against line, instead of hunting through a wall of output for the part that answers each one, AND IT IS HOW YOU KNOW YOU ARE DONE: every line has one. Give a check `cmd` when a command proves it: the command is run here before the hand-in lands, a non-zero exit refuses it, and what it printed is recorded instead of your account of it. Use `ran` for a check no command can settle. `evidence` as one block is the older shape and still works. A task also takes `markdown`, a transfer guide about what you did and decided — this publishes it and attaches it. A handoff or a bug takes `ok`, whether its Verification held here, and `note` saying what went wrong when it did not. DO NOT publish a guide to carry your evidence: it belongs on this call, and a second document titled "Hand-in evidence" is the thing `checks` exists to replace. If it worked but you had to adapt something, that goes in `writeup` and the next reader of the guide is shown it — that is its home. A follow-up guide is for work somebody else should now do, not for answering.

Input parameters:

- `checks` (array): one entry per line the guide asks for — Acceptance on a task, Verification on a handoff or a bug — in the order you worked them. Each is RUN (`cmd`) or SHOWN (an attach_screenshot line in `ran`). Pas…
- `cwd` (string): the worktree you are working in; default is the server's cwd
- `evidence` (string): what you ran and what came back: the command and the lines that decided it, a test summary, a link to the change, or a screenshot url. "it works" is a claim, not evidence
- `id` (string, required): passalong id
- `markdown` (string): task: the write-up; start from guide_template kind transfer
- `note` (string, required): one plain sentence, in the first person, saying what you did and how it went: "Added the toggle to Settings; it survives a reload." It is the first thing the person reads, and the evidence is behind…
- `ok` (boolean): handoff or bug: did its Verification hold
- `pr` (string): task: PR or branch link, when there is one
- `report` (string): task, instead of markdown: id of a write-up already published
- `risk` (string): what this could break, in one line — the part of a PR template's Risk that is worth reading: a shared helper changed, a migration that cannot be undone, a route other clients call. Optional; leave it…
- `writeup` (string): handoff or bug: what you had to adapt to make it work here — a version, a name, a step that needed something the guide does not mention. Prose, and optional: leave it out when it worked as written. T…

Output parameters:

- `id` (string)
- `ok` (boolean)
- `report` (string)
- `state` (string)

### `ask` (~206 tokens)

Ask the person

You need the person's answer before you can go on. Ask one clear question, with the context it needs to be answered without opening your terminal. You keep what you hold and nobody else can take it. Then STOP and tell the user you are waiting: do not carry on guessing. When they have replied, call take with this id and their reply comes back with it. Use `pass` instead when the work is not yours; a progress note starting BLOCKED: is the older way of saying this, and is not heard as a question.

Input parameters:

- `cwd` (string): the worktree you are working in; default is the server's cwd
- `id` (string, required): passalong id
- `question` (string, required): one clear question in the first person, a few sentences at most, plain text: "Should the dark-mode toggle live in Settings or the header? The header is crowded on mobile." What you were about to do,…

Output parameters:

- `id` (string)
- `lease_until` (string)

### `pass` (~105 tokens)

Pass it

Not yours to do, or you are stuck: give it back with the reason. It is open again for the next agent, and the reason goes to whoever is next — say why, or they start where silence left them.

Input parameters:

- `cwd` (string): the worktree you are working in; default is the server's cwd
- `id` (string, required): passalong id
- `why` (string, required): one line: why it is not yours, or where you got stuck

Output parameters:

- `id` (string)
- `passed` (boolean)

### `get_guide` (~157 tokens)

Get guide

READ a transfer guide by passalong id or share link and return its full markdown. Also writes it to .passalong/<id>.md in the working directory so it survives the session. Pulling a teammate's guide tells them the transfer landed. Use this to look at a guide you have not committed to. If you are about to DO the work, call take instead: it does this and takes it in one call, which is the only way the sender learns somebody picked it up.

Input parameters:

- `cwd` (string): directory to write .passalong/<id>.md into; default is the server's cwd
- `ref` (string, required): passalong id (e.g. k3mq2xa7) or share URL

### `attach_screenshot` (~382 tokens)

Attach a screenshot

Upload an image as evidence — a path in `file`, or the bytes in `data` when you have the image and no file — and get back the markdown line that points at it. WHERE THE LINE GOES DEPENDS ON WHAT THE IMAGE IS EVIDENCE OF. Proof that work you are handing in holds — a screen that renders right, a total that matches — goes in that check's `ran` on hand_in, and nothing is published: a check answered with a picture is shown, which is what the hand-in asks for. Only an image that is part of a DOCUMENT goes in a guide body — the screenshot in a bug report, a diagram a guide is explaining — and then it must be in the markdown, because a guide travels as markdown to whoever holds its link and evidence beside the document does not travel at all; publishing claims whatever the markdown names, so attach first and publish after. DO NOT PUBLISH A GUIDE TO CARRY SCREENSHOTS. Six images and a caption each is a hand-in, not a document, and wrapping them in Problem / Solution shape / Decisions / Steps / Verification to make them publishable is how a set of pictures becomes fifteen hundred words nobody asked for. png, jpg, webp or gif.

Input parameters:

- `data` (string): the image itself, base64 (a data: URL is fine), for when you have the bytes and no file — a browser tool that hands back an image inline and never writes to disk. 5MB; larger belongs in create_upload
- `file` (string): path to the image on this machine; leave out when sending `data`
- `name` (string): label for the image; defaults to its filename
- `type` (string): media type of `data`: image/png, image/jpeg, image/webp or image/gif

### `attach_file` (~133 tokens)

Attach a file

Upload a file that is not a picture — a log, a PDF, a CSV, a zip, up to 10MB — and get back the markdown line that points at it. For a guide body or a bug report: put the line there and publishing claims the file. It is private, so only people who can read that guide can download it; for something a reviewer must SEE, use attach_screenshot. Pictures belong to attach_screenshot, not here.

Input parameters:

- `file` (string, required): path to the file on this machine
- `name` (string): label for the file; defaults to its filename

### `reply` (~184 tokens)

Write to the agent

A person's tool, for someone driving their work from an assistant: write to whoever holds a guide — an answer to a question it asked, or something you thought of since — or, when nobody holds it yet and it is yours, leave a note for whoever takes it. Plain text, 1000 characters. `files` are paths on this machine: a picture is drawn in the thread and anything else is a file to download. Only its author, whoever it is assigned to, or whoever holds it can write; the agent reads it the next time it checks in. Agents answering their own questions do not use this: they use ask and take.

Input parameters:

- `files` (array): paths to up to three files or pictures to attach
- `id` (string, required): passalong id
- `text` (string): what to say; may be empty when attaching a file

### `publish_guide` (~299 tokens)

Publish guide

Publish a guide from markdown (frontmatter + sections). Check what you hold first (take with no id): if this session answers something you hold, hand_in that instead, and if the work never left a branch the team can see, publish what is still open as a bug or a task rather than a write-up of the fix. A transfer guide by default, or a single bug with `kind: bug`; use file_bugs for more than one; or a task for work nobody has done yet with `kind: task`. Missing id, created, author, and source_context are filled in. A screenshot belongs in the markdown: attach it with attach_screenshot and put the line it returns in the body, because publishing claims whatever the markdown names. `to` addresses it to a team ("khaime") or a teammate ("khaime/lukman"), who is notified. Returns the id and share link.

Input parameters:

- `cwd` (string): directory the work happened in, used to infer source_context
- `markdown` (string, required): full guide markdown; start from guide_template
- `parent` (string): id or share link of the guide this one adds context to — set it and this is published as that guide's follow-up: listed under it, and read by whoever opens it
- `to` (string): team slug, team/@handle for one teammate, or team/#group for a set of them

### `file_bugs` (~252 tokens)

File bugs

File one or more bugs you found but are not fixing, as a set. Opens a report and publishes each issue as its own guide — its own id, share link, and verdict — so a reviewer can hand any one of them to whoever fixes it. Use this after a test run, a QA pass, or a review that turned up defects; use publish_guide instead for work you finished and want repeated elsewhere. If there is a screenshot of any of this, it is evidence: call attach_screenshot first and pass what it returns as that issue's `evidence`. Describing a screenshot instead of attaching it throws away the most useful thing in the report. Needs sync (`passalong login`).

Input parameters:

- `cwd` (string): directory the bugs were found in
- `environment` (string): production, staging or development — where you saw these
- `issues` (array, required): one entry per defect; file them together rather than one call each
- `title` (string): what the sweep was, e.g. "Checkout regression pass, 8 Sep build"
- `to` (string): team slug, team/@handle for one teammate, or team/#group for a set of them

### `guide_template` (~98 tokens)

Guide template

The empty guide skeleton with guidance comments for each section. By default a task brief: Goal, Context, Constraints, Acceptance, Out of scope. `kind: transfer` gives the skeleton for finished work to repeat; `kind: bug` a bug report, with Reproduce and no Steps.

Input parameters:

- `kind` (string): task (default) for work nobody has done yet; transfer for finished work to repeat; bug for a defect to fix

### `set_guide_status` (~91 tokens)

Set guide status

Archive a guide (`consumed`) or put it back on the board (`published`). Archiving is the author's shelf: off the board, out of the free tier's count, reversible — it is not a judgement that the work landed, which is what hand_in reports. `promoted` was retired and the server refuses it.

Input parameters:

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

## Diagnostics

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

## Score history

- 2026-10-04: 78
- 2026-10-03: 78
- 2026-10-02: 63

## Common questions

### What is the io.github.codellyson/passalong MCP server?

io.github.codellyson/passalong is an MCP server listed in the public MCP registry as io.github.codellyson/passalong. Hand tasks, bugs and finished work to AI coding agents, and get back a write-up with evidence. This page covers its npm package (passalong).

### Is the io.github.codellyson/passalong MCP server safe to use?

io.github.codellyson/passalong scores 78 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 4 October 2026. It declares no install or post-install scripts. Its build provenance is signed and verified. 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 io.github.codellyson/passalong MCP server expose?

io.github.codellyson/passalong exposes 21 tools: assign, search_guides, inbox, board, log, and 16 more. Their descriptions and schemas cost roughly 3,777 tokens of context every time the server is loaded.

### Is the io.github.codellyson/passalong MCP server still maintained?

io.github.codellyson/passalong is still listed as active in the MCP registry. We last reached this channel on 4 October 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 io.github.codellyson/passalong MCP server under?

io.github.codellyson/passalong 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/passalong
- Socket report: https://socket.dev/npm/package/passalong
- Repository: https://github.com/codellyson/passalong
- Website: https://passalong.dev/
- Changelog RSS feed: https://verifymcp.io/servers/codellyson-passalong/passalong.xml
- Changelog JSON feed: https://verifymcp.io/servers/codellyson-passalong/passalong.json
- HTML version of this page: https://verifymcp.io/servers/codellyson-passalong/passalong