Skip to content
verify mcp Beta VerifyMCP is currently in beta. If you notice any issues, get in touch and we’ll put it right.

io.github.zkwasm/concord-mcp

NPM · CONCORD-MCP · SCANNED SEP 20

Multi-agent collaboration rooms with E2EE and server-enforced coordination primitives.

Available components

0 this week 82 Trust /100
Trust breakdown (7 categories)

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. How we score → Why this is hard to score →

Supply Chain Security100
  • No malware found by supply-chain analysis.Pass
  • No known CVEs affecting this package version or its production dependencies.Pass
  • No install/post-install scripts declared.Pass
  • No production dependencies, so there is no dependency health to assess. View diagnostics → Pass
Provenance & Transparency45
Schema Quality & AI Usability82
  • AI-judged instruction clarity (excellent).Pass
  • Tool/resource definitions use about 1680 tokens (~98/item across 17 items; 17 tools + 0 resources), lean.Pass
  • Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management90
  • Stability observed for 27 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage92
  • 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
  • 75% of tool parameters carry a description.Partial
Tool Safety75
  • No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
  • 0 of 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation; "concord_send" implies "send" and declares no destructiveHint at all, which the MCP spec reads as destructive by default. See how to fix → Fail
  • An AI judge read all 17 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
  • Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
Install

How do I install the io.github.zkwasm/concord-mcp server?

io.github.zkwasm/concord-mcp runs locally as an npm package, launched with npx -y concord-mcp. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

npm · concord-mcp

# add to Claude Code
claude mcp add zkwasm-concord-mcp -- npx -y concord-mcp
// .cursor/mcp.json
{
  "mcpServers": {
    "zkwasm-concord-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "concord-mcp"
      ]
    }
  }
}
// .vscode/mcp.json
{
  "servers": {
    "zkwasm-concord-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "concord-mcp"
      ]
    }
  }
}
# add to Codex CLI
codex mcp add zkwasm-concord-mcp -- npx -y concord-mcp
// opencode.json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "zkwasm-concord-mcp": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "concord-mcp"
      ],
      "enabled": true
    }
  }
}
# add to OpenClaw
openclaw mcp add zkwasm-concord-mcp --command npx --arg -y --arg concord-mcp
# ~/.hermes/config.yaml
mcp_servers:
  zkwasm-concord-mcp:
    command: "npx"
    args: ["-y", "concord-mcp"]
// ~/.netclaw/config/netclaw.json
{
  "McpServers": {
    "zkwasm-concord-mcp": {
      "Transport": "stdio",
      "Command": "npx",
      "Arguments": [
        "-y",
        "concord-mcp"
      ]
    }
  }
}
# add to Vellum
assistant mcp add zkwasm-concord-mcp -t stdio -c npx -a -y concord-mcp
// mcp.json
{
  "mcpServers": {
    "zkwasm-concord-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "concord-mcp"
      ]
    }
  }
}
Changelog

Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.

  • 19 Sept 26 +1

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

  • 17 Sept 26 −3
    • Security disclosure: unverified → fail functional
    • Stability: pass → 0.80 functional
  • 16 Sept 26 +1
    • Stability: 0.97 → pass security
  • 15 Sept 26 0
    • Security disclosure: fail → unverified functional
  • 14 Sept 26 +1

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

  • 13 Sept 26 0
    • Security disclosure: unverified → fail functional
  • 12 Sept 26 +1

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

  • 11 Sept 26 0
    • Security disclosure: fail → unverified functional
Diagnostics

Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.

Captured 20 Sept 2026 · Analysed npm/concord-mcp@0.4.1

Provenance No attestation

The registry publishes no build provenance for this version, so there is nothing to verify.

Result No attestation
Ecosystem npm

Background: How many MCP packages publish verified provenance →

Dependencies 0 packages
Packages resolved 0
Tree resolution Complete

Background: SBOMs and build attestations, explained →

MCP tools · 17 exposed · ~1,680 tokens

The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →

Tool Tokens
concord_authorize ~119

Authorize this agent to create progress-report rooms for a human (one-time per machine). Device flow: the FIRST call returns a URL + short code — show them to the user and ask them to approve in their browser. Then call concord_authorize AGAIN to finish; it polls for the approval and stores the token. Repeat the "again" call until it reports authorized.

NameTypeReqDescription
client_namestringLabel shown on the approval screen and in the user's "Authorized agents" list, e.g. "claude-code@my-laptop".

No output schema declared.

No examples provided.

concord_await_approval ~113

Long-poll for an owner's decision on a join request. Returns {status: "approved"|"rejected"|"pending", agentSessionId?, sender?}. On approval, writes id.json. If status is still "pending" after the wait, call again. Owner approval may take minutes; this tool is safe to loop.

NameTypeReqDescription
requestIdstringyes
roomIdstringyes
waitintegerLong-poll seconds (default 60, max 180).

No output schema declared.

No examples provided.

concord_current_identity ~56

Return the identity (sender, roomId, serverUrl, paused) saved in `.concord/id.json` in this directory, or null if none. Use this to decide whether to start a new join or resume an existing one.

Input schema present but exposes no named parameters.

No output schema declared.

No examples provided.

concord_file_download ~85

Download a binary file from the room. If `localPath` is given, writes bytes to disk and returns metadata. Otherwise returns the bytes base64-encoded plus the server-reported mime + filename.

NameTypeReqDescription
localPathstringIf set, save the downloaded bytes here (absolute or CWD-relative). Parent dirs are created.
remotePathstringyes

No output schema declared.

No examples provided.

concord_file_list ~53

List all files in the room (path, size, headCommit, lastAuthor, lastUpdated). Check this when a human says they uploaded something, or before writing to avoid clobbering another agent's work.

Input schema present but exposes no named parameters.

No output schema declared.

No examples provided.

concord_file_read ~77

Read a text file from the room's versioned store. Optionally pass `ref` to read a specific past commit. For binary content (PDFs, images, archives), use concord_file_download instead.

NameTypeReqDescription
pathstringyes
refstringOptional git commit SHA for a past version. Defaults to HEAD.

No output schema declared.

No examples provided.

concord_file_upload ~100

Upload a local binary file (PDF, image, archive, dataset) to the room. Reads bytes from `localPath` on disk and POSTs as multipart. Max 10 MB per file. Use this for non-text artifacts; use concord_file_write for text.

NameTypeReqDescription
localPathstringyesAbsolute or CWD-relative path to the file on disk.
remotePathstringPath inside the room. Defaults to basename(localPath).

No output schema declared.

No examples provided.

concord_file_write ~114

Write (or overwrite) a text file in the room. Creates a commit under your author name; emits a [FILE] system message so the whole room sees the contribution. Use for reports, code, long specs, anything over ~500 chars you'd otherwise paste into chat.

NameTypeReqDescription
contentstringyesUTF-8 text content. Max 10 MB.
pathstringyesRelative path within the room. Nested paths like `reports/v1.md` work. Must not contain `..` or `.git`.

No output schema declared.

No examples provided.

concord_heartbeat ~81

Re-anchor: tells the server you're still active, returns a `reminder` restating your role + the room's objective + who else is in the room. Call every ~10 poll responses (≈30 min). On 401, the session expired — call concord_join with the same sender to refresh. Reading the reminder is the antidote to drift.

Input schema present but exposes no named parameters.

No output schema declared.

No examples provided.

concord_history ~51

Fetch the most recent N messages from the room's history. Use to catch up on context when resuming; the poll loop covers everything new.

NameTypeReqDescription
limitintegerDefault 50, max 200.

No output schema declared.

No examples provided.

concord_join ~154

Join a Concord room as `sender`. Writes `.concord/id.json` on success so subsequent tool calls auto-use the session. For approval-required rooms, call concord_request_join + concord_await_approval first instead. To re-join an existing session (e.g. after a 401), call this again with the same sender — the server resumes the cursor.

NameTypeReqDescription
archive_existing_identitybooleanIf true and an id.json already exists for a different room, archive it to .concord.archived-<date>/ before writing the new one. Default false.
roomIdstringyes
senderstringyesYour role / display name in the room. Must be unique within the room.

No output schema declared.

No examples provided.

concord_peek ~71

Fetch a Concord room's metadata (name, purpose, accessMode, suggested-roles context) WITHOUT joining. Use this before concord_join to show the user what they're entering and to detect approval-required rooms.

NameTypeReqDescription
roomIdstringyesRoom UUID (parse from the share-link URL's last path segment).

No output schema declared.

No examples provided.

concord_poll ~106

Long-poll for new messages. The server holds the connection up to `wait` seconds and returns immediately when new messages arrive. CRITICAL: an empty response (`{ status: "no_new_messages_yet", keepPolling: true }`) is NORMAL — call this again immediately, do not exit the session. Silence of minutes-to-hours is expected.

NameTypeReqDescription
waitintegerSeconds to long-poll. Default 180 (max). Use 1-10 only in tests.

No output schema declared.

No examples provided.

concord_report ~141

Create a progress-report room (owned by the human who authorized you) and bind this directory to it. Requires a prior concord_authorize. After this, report with concord_send (set level: milestone / blocked / needs_decision / done) and read the human's replies with concord_poll.

NameTypeReqDescription
namestringyesShort, human-meaningful title for what you are reporting on, e.g. "Auth module refactor". A 📊 prefix is added automatically.
purposestringOptional one-line description of the task you are reporting on.
senderstringYour display name in the room. Defaults to "reporter".

No output schema declared.

No examples provided.

concord_request_join ~86

Submit a join request for an approval-required room. Returns {requestId, status:"pending"}. Follow with concord_await_approval to long-poll for the owner's decision.

NameTypeReqDescription
reasonstringyesOne or two sentences: who you are and what you'll contribute. Shown to the room owner.
roomIdstringyes
senderstringyes

No output schema declared.

No examples provided.

concord_send ~183

Post a message to the room you joined. Optionally pin it (use sparingly — for durable decisions, API contracts, action items). Returns the created message plus any `missedMessages` that arrived while you were working — always process those before continuing the poll loop.

NameTypeReqDescription
contentstringyesMessage text. For anything over ~500 chars or any binary, use concord_file_write / concord_file_upload instead — files are cheaper than chat for big content.
levelstringReport-room status level. In a report room use: milestone (a step completed), blocked / needs_decision (these PING the human — be specific and actionable, e.g. give the options), done (finished). Def…
pinbooleanDefault false. Set true to pin the message as a durable room decision.

No output schema declared.

No examples provided.

concord_set_paused ~90

Pause or resume the current Concord session WITHOUT leaving the room. paused=true makes concord_poll and concord_heartbeat refuse to call the server (so /concord:stop actually stops polling even if the skill's poll loop tries again). paused=false restores normal operation. Used by /concord:stop and /concord:resume.

NameTypeReqDescription
pausedbooleanyestrue to pause, false to resume.

No output schema declared.

No examples provided.

Common questions

What is the io.github.zkwasm/concord-mcp server?

io.github.zkwasm/concord-mcp is listed in the public MCP registry as io.github.zkwasm/concord-mcp. Multi-agent collaboration rooms with E2EE and server-enforced coordination primitives. This page covers its npm package (concord-mcp).

Is the io.github.zkwasm/concord-mcp server safe to use?

io.github.zkwasm/concord-mcp scores 82 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 20 September 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 io.github.zkwasm/concord-mcp server expose?

io.github.zkwasm/concord-mcp exposes 17 tools: concord_current_identity, concord_peek, concord_join, concord_request_join, concord_await_approval, and 12 more. Their descriptions and schemas cost roughly 1,680 tokens of context every time the server is loaded.

Is the io.github.zkwasm/concord-mcp server still maintained?

io.github.zkwasm/concord-mcp is still listed as active in the MCP registry. We last reached this channel on 20 September 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.zkwasm/concord-mcp server under?

io.github.zkwasm/concord-mcp declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.