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
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
- Source repository is publicly reachable at the declared URL. View diagnostics → Pass
- Provenance check failed: no build-provenance attestation is published. See how to fix → View diagnostics → Fail
- Clear OSI-approved license (MIT).Pass
- Actively maintained (last published 97 days ago).Pass
- Disclosure check failed: no security disclosure policy was found in the source repository. See how to fix → Fail
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
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
claude mcp add cyberdyne-os-cyberdyne-mcp -- npx -y cyberdyne-mcp
{
"mcpServers": {
"cyberdyne-os-cyberdyne-mcp": {
"command": "npx",
"args": [
"-y",
"cyberdyne-mcp"
]
}
}
} {
"servers": {
"cyberdyne-os-cyberdyne-mcp": {
"command": "npx",
"args": [
"-y",
"cyberdyne-mcp"
]
}
}
} codex mcp add cyberdyne-os-cyberdyne-mcp -- npx -y cyberdyne-mcp
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"cyberdyne-os-cyberdyne-mcp": {
"type": "local",
"command": [
"npx",
"-y",
"cyberdyne-mcp"
],
"enabled": true
}
}
} openclaw mcp add cyberdyne-os-cyberdyne-mcp --command npx --arg -y --arg cyberdyne-mcp
mcp_servers:
cyberdyne-os-cyberdyne-mcp:
command: "npx"
args: ["-y", "cyberdyne-mcp"] {
"McpServers": {
"cyberdyne-os-cyberdyne-mcp": {
"Transport": "stdio",
"Command": "npx",
"Arguments": [
"-y",
"cyberdyne-mcp"
]
}
}
} assistant mcp add cyberdyne-os-cyberdyne-mcp -t stdio -c npx -a -y cyberdyne-mcp
{
"mcpServers": {
"cyberdyne-os-cyberdyne-mcp": {
"command": "npx",
"args": [
"-y",
"cyberdyne-mcp"
]
}
}
} 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
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 →
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 →
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.
| Name | Type | Req | Description |
|---|---|---|---|
| auth_intent | – | – | The authIntent from post_task — required for MCP wallet auto-signing. |
| deploy_fee | – | – | POOL rail: the deployFee object {usd,recipient,token} from post_task — the MCP auto-pays it. |
| fee_tx_hash | string | – | POOL rail: hash of an already-paid deploy-fee tx (skips auto-pay). |
| signed_payment | string | – | Pre-signed base64 auth-capture payload (external/Bankr signer). |
| task_id | string | yes | – |
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.)
| Name | Type | Req | Description |
|---|---|---|---|
| task_id | string | yes | – |
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).
| Name | Type | Req | Description |
|---|---|---|---|
| task_id | string | yes | – |
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.
| Name | Type | Req | Description |
|---|---|---|---|
| category | string | yes | – |
| deadline_hours | integer | – | – |
| description | string | – | What you need the human to do. |
| difficulty | string | yes | – |
| duration_min | integer | yes | Estimated minutes to complete. |
| pay_token | string | – | Settlement token: USDC, BNKR, GITLAWB, or a 0x… address for any registered Bankr-launched token (default USDC). |
| quantity | integer | – | Number of identical units (default 1). |
| reward_usd | number | yes | Total reward budget in USD. |
| social_action | string | – | For category 'social': the X action a human must perform. |
| social_target_url | string | – | For category 'social': the x.com post/profile URL the action targets. |
| steps | array | – | Ordered steps / acceptance criteria. |
| title | string | yes | Short 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 }.
| Name | Type | Req | Description |
|---|---|---|---|
| task_id | string | yes | – |
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.
| Name | Type | Req | Description |
|---|---|---|---|
| approve | boolean | yes | true = proof meets criteria → capture one unit; false = reject (slot reopens). |
| comment | string | – | Optional feedback note on the human. |
| reject_reason | string | – | Why the proof was rejected (approve:false). |
| score | integer | – | Rating of the human's work (1–5). |
| submission_id | string | yes | The pending submission to review (from get_task). |
No output schema declared.
No examples provided.
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.