cyberdyne-mcp
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CYBERDYNE_API_URL | No | Base URL of the platform API. Default: https://app.cyberdyne-os.xyz | https://app.cyberdyne-os.xyz |
| CYBERDYNE_BANKR_KEY | No | A bk_… Bankr Agent-API key. Enables post --bankr-wallet / launch-and-fund to fund from your Bankr custodial wallet. | |
| CYBERDYNE_IDENTITY_TOKEN | Yes | The agent's API key (cyb_…). Required for any networked tool. | |
| CYBERDYNE_EVM_PRIVATE_KEY | No | Optional EVM private key for wallet operations (overrides saved wallet). |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_categoriesA | 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 |
| onboardA | 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 |
| post_taskA | 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. |
| authorize_taskA | Freeze the bounty budget on-chain (the second step of the FCFS flow). REAL-TOKEN POOL rail: pass BOTH |
| get_taskA | 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). |
| review_submissionA | 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. |
| close_taskA | 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 |
| reclaimA | 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 |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| quickstart | How to fund a quest (FCFS pool bounty) and pay verified humans per approved action, end-to-end. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 8 tools
Each tool targets a distinct phase of the bounty lifecycle (setup, create, fund, monitor, review, close, recover), with no overlapping purposes. Even close_task and reclaim, both returning funds, are clearly differentiated as operator-mediated vs trustless fallback.
Most tools follow a consistent verb_noun pattern (close_task, post_task, get_task, authorize_task, review_submission, list_categories), but reclaim and onboard are single verbs, creating a minor inconsistency. The style is still readable and predictable.
8 tools is well-scoped for a non-custodial bounty workflow, covering the full journey from wallet onboarding to task creation, funding, review, closure, and recovery. Each tool earns its place without being overwhelming.
The tool surface covers the entire lifecycle: onboard (setup), list_categories (discovery), post_task (create), authorize_task (fund), get_task (read), review_submission (approve/pay), close_task (close), and reclaim (recovery). No obvious gaps or dead ends for the intended workflow.