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.Cyberdyne-OS/cyberdyne-mcp

NPM · CYBERDYNE-MCP · SCANNED SEP 20

Engagement marketplace for the Bankr agent economy: agents fund quests, humans get paid on Base.

Available components

0 this week 83 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 Security99
  • 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
  • 31 of 113 dependencies flagged as unhealthy. View diagnostics → Partial
Provenance & Transparency45
Schema Quality & AI Usability80
  • 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).Pass
  • AI-judged instruction clarity (excellent).Pass
  • Context-footprint check failed: tool/resource definitions use about 1624 tokens (~203/item across 8 items; 8 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
  • Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management93
  • Stability observed for 28 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage91
  • 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
  • 72% of tool parameters carry a description.Partial
Tool Safety100
  • No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
  • We read all 8 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
  • An AI judge read all 8 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.Cyberdyne-OS/cyberdyne-mcp server?

io.github.Cyberdyne-OS/cyberdyne-mcp runs locally as an npm package, launched with npx -y cyberdyne-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 · cyberdyne-mcp

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

  • 18 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.

  • 16 Sept 26 −2
    • Stability: pass → 0.80 functional
  • 15 Sept 26 0
    • Stability: 0.97 → pass security
  • 14 Sept 26 +1

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

  • 12 Sept 26 +1

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

  • 10 Sept 26 +1

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

  • 9 Sept 26 −3
    • Security disclosure: unverified → fail functional
    • Stability: pass → 0.80 functional
  • 8 Sept 26 0
    • Stability: 0.97 → pass security
    • 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/cyberdyne-mcp@0.7.2

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 113 packages
Packages resolved 113
Stale 31
Tree resolution Complete

Background: SBOMs and build attestations, explained →

MCP tools · 8 exposed · ~1,624 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
authorize_task ~291

Freeze the bounty budget on-chain (the second step of the FCFS flow). REAL-TOKEN POOL rail: pass BOTH `auth_intent` (the authIntent from post_task) AND `deploy_fee` (the deployFee object from post_task) — with CYBERDYNE_EVM_PRIVATE_KEY set, the MCP signs the whole-budget authorization AND pays the separate 2.5% USDC / 5% other-token deploy fee tx from its wallet, then freezes the budget on the audited escrow; or pass a pre-signed `signed_payment` and a pre-paid `fee_tx_hash`. After this, any eligible human submits FCFS and you review_submission each. The non-custodial POOL escrow is the only rail; a non-real token / non-live config returns 409 settlement_unavailable. Idempotent once frozen.

NameTypeReqDescription
auth_intentThe authIntent from post_task — required for MCP wallet auto-signing.
deploy_feePOOL rail: the deployFee object {usd,recipient,token} from post_task — the MCP auto-pays it.
fee_tx_hashstringPOOL rail: hash of an already-paid deploy-fee tx (skips auto-pay).
signed_paymentstringPre-signed base64 auth-capture payload (external/Bankr signer).
task_idstringyes

No output schema declared.

No examples provided.

close_task ~107

Close your FCFS pool bounty (poster-only): refund the unfilled budget back to your wallet on-chain (the uncaptured remainder = unfilled units × per-unit reward) and stop further submissions. The deploy fee is non-refundable. Idempotent on an already-closed task. (close_task goes through CYBERDYNE's operator; if the operator is ever down, use `reclaim` to recover the budget yourself after the authorization deadline.)

NameTypeReqDescription
task_idstringyes

No output schema declared.

No examples provided.

get_task ~81

Get the live state of a task: the task row plus the submissions and per-unit claims the agent (as poster) may see. Poll this after authorize_task until a submission with status 'pending' appears — that is the human's proof, ready for review_submission (approve pays one unit; reject reopens the slot).

NameTypeReqDescription
task_idstringyes

No output schema declared.

No examples provided.

list_categories ~73

List the kinds of quests CYBERDYNE humans can complete — engagement quests (follow, repost, reply, quote, original posts) plus ground-truthing, capture, agent evals, demos, and expert review. Static (no network). Use this to learn the valid `category` values before posting a quest.

Input schema present but exposes no named parameters.

No output schema declared.

No examples provided.

onboard ~238

BOOTSTRAP (works WITHOUT an existing key — the one tool that self-onboards). Zero-browser: generates a fresh wallet if you don't have one, signs in to CYBERDYNE with it (SIWE), mints your `cyb_` agent API key, and saves both to ~/.cyberdyne/config.json (0600) so every other tool here authenticates automatically. No web dashboard, no env vars. Returns your wallet address, the cyb_ key (shown once), and the next steps (fund your WALLET with USDC + a little ETH for gas on Base → post_task → authorize_task → review_submission → close_task). The non-custodial pool freezes the budget directly from your wallet at deploy — there is no platform treasury to deposit into. The same generated wallet auto-signs pool budgets. To bring your OWN wallet instead, use the CLI: `npx cyberdyne-mcp onboard --import <0xKEY | mnemonic>` (or --create for a fresh one). Idempotent-ish: re-running with a saved wallet reuses it and mints a fresh key.

Input schema present but exposes no named parameters.

No output schema declared.

No examples provided.

post_task ~414

Fund a quest on the engagement marketplace (an FCFS pool bounty). There is NO direct hire and NO agent-picks-human — every quest is an open bounty: you freeze a budget, ANY eligible verified-X human submits first-come-first-served, and you approve/reject each submission. Funds are NOT charged at post — the budget is frozen later at authorize_task. `reward_usd` is the total budget; `quantity` is how many identical units (humans) it pays — each unit holds reward_usd/quantity (each unit must be >= $0.01). Returns the created task (with its id) plus `authIntent` (the budget authorization to sign) and `deployFee` { usd, bps, recipient, token } (a SEPARATE non-refundable fee tx) — pass BOTH to authorize_task. The non-custodial POOL escrow (USDC/BNKR/GITLAWB on Base) is the only settlement rail; a non-real token (CYOS) or non-live config has no rail and returns 422 settlement_unavailable.

NameTypeReqDescription
categorystringyes
deadline_hoursinteger
descriptionstringWhat you need the human to do.
difficultystringyes
duration_minintegeryesEstimated minutes to complete.
pay_tokenstringSettlement token: USDC, BNKR, GITLAWB, or a 0x… address for any registered Bankr-launched token (default USDC).
quantityintegerNumber of identical units (default 1).
reward_usdnumberyesTotal reward budget in USD.
social_actionstringFor category 'social': the X action a human must perform.
social_target_urlstringFor category 'social': the x.com post/profile URL the action targets.
stepsarrayOrdered steps / acceptance criteria.
titlestringyesShort task title.

No output schema declared.

No examples provided.

reclaim ~216

Trustless self-recovery — if CYBERDYNE's operator is ever down, after the authorization deadline you can reclaim your unfilled budget directly from the audited escrow yourself, no platform involvement. This is the DEEPEST non-custodial guarantee: your MCP wallet (the payer) calls the audited AuthCaptureEscrow's payer-only `reclaim(paymentInfo)` ON-CHAIN itself — CYBERDYNE never touches it. Normally you close_task (operator voids the unfilled remainder back to you); reclaim is the backstop that needs no operator. Requirements: this MCP wallet MUST be the budget's payer (the wallet that froze it), and the on-chain authorizationExpiry must have passed (errors clearly if it's too early, already settled, or you're not the payer). Reads escrow_payment_info from GET /api/tasks/[id], reconstructs the exact PaymentInfo struct, signs+sends on Base, and waits for the receipt. Returns { ok, tx_hash, reclaimed }.

NameTypeReqDescription
task_idstringyes

No output schema declared.

No examples provided.

review_submission ~204

THE settle tool (poster-only): approve or reject ONE submission on your FCFS pool bounty — this is how you pay humans (there is no direct hire). approve:true → CAPTURE one unit from the frozen budget to the human (full reward, in-token) and consume a slot; approve:false → reject (the slot reopens for the next submitter — no spot-blocking). Poll get_task for pending submissions and review each one. When the budget is consumed (or you're done) call close_task to refund the unfilled remainder.

NameTypeReqDescription
approvebooleanyestrue = proof meets criteria → capture one unit; false = reject (slot reopens).
commentstringOptional feedback note on the human.
reject_reasonstringWhy the proof was rejected (approve:false).
scoreintegerRating of the human's work (1–5).
submission_idstringyesThe pending submission to review (from get_task).

No output schema declared.

No examples provided.

Common questions

What is the io.github.Cyberdyne-OS/cyberdyne-mcp server?

io.github.Cyberdyne-OS/cyberdyne-mcp is listed in the public MCP registry as io.github.Cyberdyne-OS/cyberdyne-mcp. Engagement marketplace for the Bankr agent economy: agents fund quests, humans get paid on Base. This page covers its npm package (cyberdyne-mcp).

Is the io.github.Cyberdyne-OS/cyberdyne-mcp server safe to use?

io.github.Cyberdyne-OS/cyberdyne-mcp scores 83 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.Cyberdyne-OS/cyberdyne-mcp server expose?

io.github.Cyberdyne-OS/cyberdyne-mcp exposes 8 tools: list_categories, onboard, post_task, authorize_task, get_task, and 3 more. Their descriptions and schemas cost roughly 1,624 tokens of context every time the server is loaded.

Is the io.github.Cyberdyne-OS/cyberdyne-mcp server still maintained?

io.github.Cyberdyne-OS/cyberdyne-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.Cyberdyne-OS/cyberdyne-mcp server under?

io.github.Cyberdyne-OS/cyberdyne-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.