# Paigy (npm · @paigy/mcp)

Lets your AI agents call you when they need a decision, and hear your answer.

- Trust score: 62/100 (medium)
- Change this week: 0
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-11-05

## Components

- npm · `@paigy/mcp`: 62/100 (this document), [markdown](https://verifymcp.io/servers/paigy-ai-mcp/paigy-mcp.md), [page](https://verifymcp.io/servers/paigy-ai-mcp/paigy-mcp)

## Channel facts

- Registry: `npm`
- Package: `@paigy/mcp`
- Version: `0.40.42`
- 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-05.

- **Supply Chain Security**: 81/100
  - No malware found by supply-chain analysis.
  - CVE check failed: a known high-severity CVE affects zod 3.25.76, a direct dependency. A fixed version is available.
  - No install/post-install scripts declared.
  - 30 of 95 dependencies flagged as unhealthy.
- **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 0 days ago).
  - Disclosure check failed: no security disclosure policy was found in the source repository.
- **Schema Quality & AI Usability**: 73/100
  - 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 3818 tokens (~381/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**: 0/100
  - Stability not yet verified: not enough scan history yet (needs a 30-day window).
- **Tool Coverage**: 94/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 82% 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 2 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation; "contact" implies "send" and declares no destructiveHint at all, which the MCP spec reads as destructive by default.
  - An AI judge read all 11 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 Paigy MCP server?

Paigy runs locally as an npm package, launched with npx -y @paigy/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 paigy-ai-mcp -- npx -y @paigy/mcp
```

### Cursor

```json
{
  "mcpServers": {
    "paigy-ai-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "@paigy/mcp"
      ]
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "paigy-ai-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "@paigy/mcp"
      ]
    }
  }
}
```

### Codex

```bash
codex mcp add paigy-ai-mcp -- npx -y @paigy/mcp
```

### opencode

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

### OpenClaw

```bash
openclaw mcp add paigy-ai-mcp --command npx --arg -y --arg @paigy/mcp
```

### Hermes

```yaml
mcp_servers:
  paigy-ai-mcp:
    command: "npx"
    args: ["-y", "@paigy/mcp"]
```

### Netclaw

```json
{
  "McpServers": {
    "paigy-ai-mcp": {
      "Transport": "stdio",
      "Command": "npx",
      "Arguments": [
        "-y",
        "@paigy/mcp"
      ]
    }
  }
}
```

### Vellum

```bash
assistant mcp add paigy-ai-mcp -t stdio -c npx -a -y @paigy/mcp
```

### Other

```json
{
  "mcpServers": {
    "paigy-ai-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "@paigy/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-10-29 (score 62, +15)

- [security improvement] Malware scan: unverified → pass

### 2026-10-28 (score 47)

First indexed and scored.

## MCP tools (10)

### `configure` (~657 tokens)

Set this agent up with Paigy — call it FIRST, before contact, and any time you're unsure who you are. One call does whatever the situation needs: NOT SET UP → if this machine holds a device credential (the user ran the Paigy desktop app or harness) it hatches an identity INSTANTLY, no code and no approval; otherwise it starts the code ceremony. ALREADY SET UP → returns your current identity and the two things left to decide, renaming it or logging out. TOKEN NO LONGER VALID → says so, then re-pairs. Pass { name, voice } to choose who you are when hatching, or to RENAME yourself when already set up (pick your own; voices: rachel, george, jessica, brian, lily). Safe to call any time: idempotent, and it never writes settings.

THE CODE CEREMONY does not open a browser; the user enters the code in the Paigy app (or scans `qr`). A result with { user_code, device_code, qr, user_message } has already started polling for approval in the background: you MUST immediately print the `user_message` (the bare code) to the user, AND in that same turn call configure again with that `device_code` to collect the result. It returns the moment the user approves; on { status:'pending' } call again to keep waiting; on { status:'awaiting_confirmation' } (E2EE) show the bare `user_message` verify code and call again to finish. Every result's first text block states the code plainly.

On { status:'paired' }, or whenever it returns `enable_command`, ALWAYS follow the `enable_prompt`: PRINT that command for the user to run, so Paigy's tools stop prompting each time. You cannot apply it yourself (it writes your own permission allowlist, which hosts block as privilege escalation), so print it, don't wait for it, and carry on.

LOG OUT with { logOut: true }: it logs out THIS agent only — its token is revoked server-side and its local entry removed. Other agents and this device's credential are untouched, and a later configure re-hatches instantly while the device credential exists. Disconnectin…

Input parameters:

- `device_code` (string): Continue a code ceremony already in flight: the device_code a previous configure returned. Omit it otherwise.
- `logOut` (boolean): true: log THIS agent out — its token is revoked and its local entry removed. Other agents and this device's credential are untouched.
- `name` (string): Who you are: the name you choose when hatching, or the new one to RENAME yourself to when already set up. Pick your own — ONE or TWO words, the way you'd introduce yourself on a call (it is spoken al…
- `scope` (string): Which tool allowlist to report on (user or project settings). Read-only.
- `voice` (string): Your voice on calls — one of rachel, george, jessica, brian, lily.

### `contact` (~1028 tokens)

Send to and receive from the person: completions, updates, questions, answers to questions addressed to you, withdrawals, and what a question holds up. Every Goal named must exist: an unknown one refuses the whole contact. Each item applies on its own: read `results`, where a failed one names why.

HOW TO ASK:
1\. One question per object in `questions`, so each is answered on its own.
2\. `goalId` names the existing Goal it is about (create one with manage_goals first); the answer comes back there.
3\. `workItBlocks` only when you are truly blocked: it asks for a call.
4\. No while-loops. While any Call is open, even one your question joined from their items, keep receiving through empty windows; otherwise stop at one: the answer reaches you on the Goal. Yield only with a listener or wakeup.
5\. One question, one row: never re-send one still waiting; take back one that no longer matters with `withdrawQuestionIds`.
6\. Read the Goal before asking; never re-ask what was answered or shipped. `replied` means they chose no option: it is still yours to settle.
7\. Give options when you have them. Each label names its choice in full (never "Option 2"); never add "Other". `pickMode`: one (default), many, rank.
8\. A diagnosis says when, why and how it happens, then proposes one fix.
9\. Give a report its `reply`: one line in THEIR voice for THAT report, so you learn whether they verified it or only received it. Required when it is delivered or its Goal is done.

LENGTH: the question, message or answer is the one point, at most 80 characters; the rest goes in `units`, one idea each. Over a cap is refused by name and nothing is sent. Several results are several updates.

UPDATES ask nothing. One reaches the person only when they asked for it, it answers something they said, or its Goal is done; else it is kept as progress. One that reaches them joins an open report card or a live call.

RECEIVING: contact({}) waits ~45 s; contact({wait:false}) returns `events` at once. Confirm the on…

Input parameters:

- `ackEventIds` (array): The exact eventIds of the events you have handled: an acknowledgment (ACK). Reading alone acknowledges nothing, so an event comes back until you acknowledge it; after that the next batch can come. Ea…
- `answers` (array): Answers to Questions addressed to you.
- `bumpQuestionIds` (array): Your own questions still waiting on the person that you want them to notice again. Each moves back to the top of its card with one new notification; nothing is resent and no second card is made.
- `completions` (array): COMPLETIONS close and report in one operation, the same contract as manage_goals kind:complete: closure and the report commit together or neither does. Required children and dependencies must already…
- `questionDependencies` (array): Add or remove what a Question you asked holds up, after asking it.
- `questions` (array): Questions for the person, one per object, each sent exactly as written, with no reading in between.
- `updates` (array): News: progress, findings, a result. An update asks nothing. It reaches the person only when they asked for it (userExplicitlyRequested), when it answers something they said, or once its Goal is done;…
- `wait` (boolean): Only controls when this returns. Sending: false (the default) returns at once; true waits up to about 45 seconds for a response to what you sent. Sending nothing: true (the default) waits up to about…
- `withdrawQuestionIds` (array): Questions you asked that no longer need an answer: you acted on them yourself, they no longer matter, or you asked wrongly. Each is cancelled, not answered: its card closes and nothing rings for it.

### `manage_goals` (~419 tokens)

Create, edit, assign, organize or close work. Every change here changes Goals; answering, withdrawing or asking Questions stays in contact. Each change applies independently: a refused one names why (`results[i].error`, e.g. goal_revision_conflict, goal_children_open, goal_not_found) and the rest still apply, so read every result: a partial result is never a complete success. Kinds: complete (goalId, message capped at 50 characters, units, reply, optional next-step options {label, hint}) closes and reports atomically, exactly as contact.completions; create (title, outcome, ownerId, parentGoalId, sourceEntryIds) returns the new Goal's id in `results[i].goalId`, in the order requested, to use in later calls (an outcome is one paragraph, at most 500 characters: split more into child Goals with parentGoalId); edit (title and/or outcome); state (open, completed, canceled); assign (ownerId); defer (until: the Goal waits until then and its owner is woken when it passes; null takes it back); move (parentGoalId, or null for a root: only this Goal moves); dependency (add or remove: goalId waits on dependsOnGoalId to start or to complete). A Goal cannot be completed while its required children or dependencies remain open: finish or move them first. Finishing the children does not prove the parent's own work is done. An edit applies at the version you last read: if someone changed the Goal since, it is refused as goal_revision_conflict, so read it again (get_goals) and reconsider. You may change any Goal of your person; a change puts you on it. Returns `ok` (every change applied), `results` per change (applied or failed), and `goals`, each changed Goal's id, state, title, outcome and revision.

Input parameters:

- `changes` (array, required): The changes, applied in order, each on its own.

### `get_delivery` (~185 tokens)

Read a Delivery in full: its whole ask, units, options and answers, plus current callState and callOutcome for a Call. For a Call, transcript: true adds what was said: each spoken line in order, who said it, and when from pickup, a page at a time. A line from the room, not the person, is marked room. Any agent of the same account may read it; another account is not disclosed. Reading never acknowledges or resends anything. Use this after a call or when receive names a Call you are waiting on.

Input parameters:

- `after` (string): With transcript: the next value the previous page returned, to read the next page.
- `deliveryId` (string, required): The Delivery id returned by contact or receive.
- `transcript` (boolean): For a Call: also return what was said on it, one page of spoken lines.

### `get_goals` (~280 tokens)

Read one to ten Goals by goalIds, returned in the same order under goals (a read never puts you on them). history applies to every requested Goal. A refused read fails the call with its original refusal; no partial result is presented as complete. Each Goal includes its ten most recent other contributors (names, latest entry headlines and times), outcome, state, revision, progress, blockers, the conversation on it (each question with its options and what was decided), `next`, the one step to take, and `more`, where to read further. A question in that conversation reads `open` (nothing yet), `answered` (a choice was made, and `answer` carries it), `replied` (they said something and the read settled the question on their words — NO option of yours was chosen, and the words are the reply line beside it, so read that before you act), or `closed`. The conversation carries everything the person said, every open question and your newest entry; your older entries are left out and counted — history: true reads every entry in full. Every Goal of your person is readable, whichever of their agents owns it; another account's Goals are not disclosed.

Input parameters:

- `goalIds` (array, required): The Goals to read, in order; one to ten IDs.
- `history` (boolean)

### `search` (~297 tokens)

Search your person's history across all of their agents: Entries (what anyone said or wrote, typed or spoken on a call), Goals (by title and outcome) and replies -- the person's answers, acknowledgements and deferrals (type answer; found by their summary, by the question or report they reply to, or by the words that gave them). query is words to look for; records sharing more of its words rank first, and exact names work. types narrows it to entry, goal and/or answer (default: all three). goalId searches under one Goal: its Entries, the replies to its items, and it and its immediate children. limit is matches per type, 1 to 20 (default 8). Read-only. Each match carries its whole saved words, its ID and its links (a reply carries its kind -- answered, acknowledged or deferred -- whether it is closed (a deferral is not), its summary in under ten words, its question or report, the choice made and the Entries that support it); `omitted` counts what matched but was left out, so narrow the words or add a goalId to see it. Nothing found is not proof that nothing exists; a refused search says why. Sealed (encrypted) content is never searched or returned.

Input parameters:

- `goalId` (string)
- `limit` (integer)
- `query` (string, required)
- `types` (array)

### `check_activity` (~68 tokens)

Read your person's agents that contributed in the last 24 hours, newest first: at most 30 agents and their five most recently touched Goals, with their latest entry headline and time. Use get_goals to read a Goal and its other contributors before starting overlapping work. Read-only; no arguments.

### `send_feedback` (~156 tokens)

Send feedback about Paigy itself (a bug report, an idea) straight to the Paigy team. Send it only when the person asked you to, or agreed when you offered: it goes to Paigy, never to the person, and nobody answers it here. Not for your work or a question for the person: use contact for those. Returns whether it was stored.

Input parameters:

- `kind` (string): bug: something Paigy does wrong. idea: something it should do. other: anything else.
- `text` (string, required): The report, in markdown: what happened, what was expected, how to reproduce it, versions, evidence. At most 50000 characters.
- `title` (string): One line naming it.

### `help` (~70 tokens)

Start here: how to use Paigy, in full — pairing, listening, receiving, asking, updates and completions, Goals and calls. Pass a topic for one section. Read-only; needs no setup.

Input parameters:

- `topic` (string): One section of the guide. Omit it for the whole guide.

### `listen` (~174 tokens)

Am I listening for answers, and can Paigy resume this session? Takes no arguments. Returns status `listening` for harness delivery or a running listener with a ready wake adapter; `receiving` means a process is running but automatic resume is not confirmed (read its wake error or watch its output); `unpaired` means call configure; `start` gives the exact command to run NOW with your harness's Monitor tool (not a background command, which speaks only when it exits). Start it once. Codex queues into CODEX_THREAD_ID automatically when its CLI supports queue; PAIGY_ON_WAKE overrides it. A successful queue is not evidence the agent handled the answer: receive with contact({ wait: false }) and read the relevant Goal, then respond with contact. This tool never subscribes or starts anything itself.

## Diagnostics

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

## Score history

- 2026-11-05: 62
- 2026-11-04: 62
- 2026-11-03: 62
- 2026-11-02: 62
- 2026-11-01: 62
- 2026-10-31: 62
- 2026-10-30: 62
- 2026-10-29: 62
- 2026-10-28: 47

## Common questions

### What is the Paigy MCP server?

Paigy is an MCP server listed in the public MCP registry as io.github.paigy-ai/mcp. Lets your AI agents call you when they need a decision, and hear your answer. This page covers its npm package (@paigy/mcp).

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

Paigy scores 62 out of 100 on VerifyMCP. We recorded 1 known advisory against it as of 5 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 Paigy MCP server expose?

Paigy exposes 10 tools: configure, contact, manage_goals, get_delivery, get_goals, and 5 more. Their descriptions and schemas cost roughly 3,334 tokens of context every time the server is loaded.

### Is the Paigy MCP server still maintained?

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

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

### What did VerifyMCP test on the Paigy MCP server?

VerifyMCP ran 15 checks on Paigy, covering Malware scan, Known CVEs, Install scripts, Dependency health and 11 more. One item could not be completed, a gap on our side rather than a finding about Paigy: Stability. One category scores 0 for that reason, because we only credit what we can confirm. Endpoint Security and Transport & Reachability do not apply to an npm package, so they were not tested. The score does not measure everything, and the scoring documentation lists what it leaves out.

## Links

- npm package: https://www.npmjs.com/package/@paigy/mcp
- Socket report: https://socket.dev/npm/package/@paigy/mcp
- Repository: https://github.com/paigy-ai/mcp
- Website: https://paigy.ai/
- Changelog RSS feed: https://verifymcp.io/servers/paigy-ai-mcp/paigy-mcp.xml
- Changelog JSON feed: https://verifymcp.io/servers/paigy-ai-mcp/paigy-mcp/changelog.json
- Trust report (JSON): https://verifymcp.io/servers/paigy-ai-mcp/paigy-mcp.json
- HTML version of this page: https://verifymcp.io/servers/paigy-ai-mcp/paigy-mcp