io.github.Cyberdyne-OS/cyberdyne-mcp
NPM · CYBERDYNE-MCP · SCANNED AUG 3
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 →
Supply Chain Security87
- No malware found by supply-chain analysis.Pass
- Only part of the dependency tree could be resolved (112 of 116), so this covers what we could see, not the whole tree.Partial
- No install/post-install scripts declared.Pass
- Only part of the dependency tree could be resolved (112 of 116), so this covers what we could see, not the whole tree. 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 49 days ago).Pass
- Disclosure check failed: no security disclosure policy was found in the source repository. See how to fix → Fail
Schema Quality & AI Usability77
- 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 Management27
- Stability observed for 8 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
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
Add this component to your MCP client. Where a client-specific snippet is available, pick your client below and copy it straight into your config; otherwise use the connection detail shown.
npm · cyberdyne-mcp
claude mcp add cyberdyne-os-cyberdyne-mcp -- npx -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": {
"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.
- 3 Aug 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 23 to 27. That category is still filling its 30-day observation window: 7 days of observed history at the previous scan, 8 at this one. The score rises as the window fills, whether or not the server changes.
- 2 Aug 26 +44
- Provenance: unverified → fail ▼ security
- Known CVEs: unverified → partial ▲ security
- Install scripts: unverified → pass ▲ security
- Malware scan: unverified → pass ▲ security
- Schema quality: 100 → unverified ▼ functional
- Security disclosure: fail → unverified ▼ functional
- Tool coverage: 100 → unverified ▼ functional
- Stability: unverified → 0.23 ▲ functional
- MCP protocol: unverified → pass ▲ functional
- Maintenance: unverified → pass ▲ functional
- Dependency health: unverified → partial ▲ functional
- License: unverified → pass ▲ functional
- Schema quality: unverified → excellent ▲ functional
- Licence: MIT functional
- 1 Aug 26 −7
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 31 Jul 26 −18
- Malware scan: pass → unverified ▼ security
- 29 Jul 26 +25
- Tool coverage: unverified → 100 ▲ functional
- Schema quality: unverified → 100 ▲ functional
- 28 Jul 26 −25
- Tool coverage: 100 → unverified ▼ functional
- Schema quality: 100 → unverified ▼ functional
- 27 Jul 26 49
First indexed and scored.
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 3 Aug 2026 · Analysed npm/[email protected]
Provenance none
Ecosystem: npm · Outcome: none
Dependencies 112 packages
112 packages in the resolved dependency tree · 111 deprecated · 29 stale.
The dependency tree was only partially resolved, so these counts may be incomplete.
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.
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.