Physical Capability Cloud

Reviewed Jan 1, 2000.

• tools: 200 tools scanned
• metadata: scanned

No findings.

Tools (200)

• provision_api_key

  CALL THIS FIRST. Provisions an API key for the operator. Returns a pcc_live_* key that must be included as 'Authorization: Bearer <key>' on all subsequent requests. Accepts either email OR walletAddress. The key is shown once — save it. Without it, all other endpoints return 401.

• list_api_keys

  List all active API keys for the authenticated operator. Returns key IDs, prefixes, scopes, rate limits, usage counts, and creation/expiry timestamps. Requires a valid API key or SIWE session.

• revoke_api_key

  Revoke an API key permanently. The key will immediately stop working. You must own the key. Use list_api_keys to find the key ID.

• setup_detect

  Auto-detect current setup state: env vars, database, adapters, chain connectivity, storage, identity. Use this to see what's configured and what's missing before onboarding.

• setup_generate_config

  Generate a KERNEL_CONFIG JSON from device descriptions. Tell it what machines you have and it produces the config ready to paste into your environment.

• setup_validate

  Validate a kernel config (20+ checks: JSON structure, device connectivity, adapter compatibility). Returns validation errors and warnings.

• setup_register_device

  Register a device in the database with adapter config and capabilities. Part of Step 3 in the onboarding flow. Required: kernelId, deviceId, type and adapterType (400 missing_required_fields otherwise).

• setup_test_job

  Submit a test job to verify the full pipeline works end-to-end (Step 4 of onboarding). Returns job ID and result.

• setup_status

  Comprehensive setup status across 6 categories: gateway, database, adapters, chain, storage, identity. Use to confirm everything is green before going live.

• list_capability_types

  List all capability types registered on the network (FDM, SLA, CNC, HPLC, etc.) with metadata.

• search_capabilities

  Search capability templates by type or keyword. Returns templates with pricing, assurance tiers, and availability.

• get_build_options

  Get configuration options for a capability type (materials, dimensions, tolerances, assurance tiers). Use before calling calculate_price.

• calculate_price

  Calculate price for a capability configuration. Returns base price, tier premiums, and estimated total cost.

• build_contract

  Build and submit a capability contract with on-chain milestone escrow. Returns job ID and escrow address.

• list_kernels

  List all Shop Kernels on the network with status and capability types. Optionally filter by status.

• get_kernel

  Get kernel details including full capability objects, devices, and queue.

• get_kernel_devices

  List all devices registered under a specific kernel, including adapter configs and device types.

• get_kernel_jobs

  List all jobs submitted to a specific kernel, including job status and progress.

• create_kernel

  Register a new Shop Kernel (physical site) on the PCC network. Part of Step 2 in the onboarding flow.

• list_jobs

  List all jobs with status. Optionally filter by kernelId or status.

• get_job

  Get job details including progress, evidence bundles, and milestones.

• update_job_status

  Update a job's status and optional progress percentage. Used by kernels to report job progress.

• list_escrows

  List escrow contracts with milestones and bonds. Optionally filter by status.

• get_escrow

  Get escrow details. Pass a DB ID for database record (with milestones and disputes), or an EVM address (0x...) to read directly from the blockchain.

• get_escrow_chain_state

  Read full on-chain escrow state with all milestone details from the blockchain. More detailed than get_escrow for on-chain contracts.

• get_escrow_events

  Get on-chain event history for an escrow contract. Returns funding, release, dispute, and bond events.

• get_token_balance

  Read an ERC-20 token balance for an account address from the blockchain.

• get_token_allowance

  Read the ERC-20 token allowance granted by an owner to a spender from the blockchain.

• get_escrow_dispute

  Read dispute state for a specific milestone from the blockchain.

• get_write_status

  Check if on-chain write operations are enabled (requires PCC_GATEWAY_PRIVATE_KEY to be configured). Returns write status and signer address.

• fund_escrow

  Fund a protocol-created escrow on-chain. Approval is handled INTERNALLY by the gateway for protocol-created escrows (audit C-03 removed the public approve step) — do NOT call a separate approve first; fund directly. Returns transaction hash.

• release_milestone

  Release a milestone payment on-chain after the challenge window has expired. Returns transaction hash.

• file_escrow_dispute

  File a dispute against a milestone on-chain. Challenger must post a bond and provide evidence hash. Returns transaction hash.

• deposit_bond

  Deposit an operator bond for a milestone on-chain. Required for Assurance Tier 3 jobs. Returns transaction hash.

• submit_evidence_hash

  Submit an evidence bundle hash for a milestone on-chain. Links the physical evidence to the on-chain settlement record. Returns transaction hash.

• submit_attestation

  Submit a verifier attestation for a milestone on-chain. Used by third-party verifiers (Bittensor subnet) to confirm evidence quality. Returns transaction hash.

• archive_evidence

  Archive an evidence bundle to IPFS/Storacha for permanent decentralized storage. Returns the content-addressed CID.

• get_evidence_bundle

  Get an encrypted evidence bundle by its bundle ID. Returns the encrypted payload and key capsules.

• grant_evidence_access

  Grant a new recipient access to an encrypted evidence bundle. Creates a re-encrypted key capsule for the recipient.

• list_evidence_grants

  List all evidence access grants for an address. Returns bundles the address has been granted access to.

• archive_encrypted_bundle

  Archive an encrypted evidence bundle to IPFS and store the resulting CID in the database. Idempotent — returns existing CID if already archived.

• get_bundle_ipfs

  Get IPFS CIDs for a bundle — returns the primary CID, metadata CID, and Filecoin deal ID if available.

• retrieve_ipfs

  Retrieve raw data from IPFS by CID. Used to fetch archived evidence bundles from decentralized storage.

• get_lit_conditions

  Get Lit Protocol access conditions for a Lit-encrypted evidence bundle. Returns the conditions that gate decryption.

• lit_decrypt

  Decrypt a Lit Protocol-encrypted evidence bundle using a Lit auth signature. Returns the decrypted bundle payload.

• verify_evidence_zk

  Verify a ZK proof by its proof ID. Checks the proof against its verification key and public inputs.

• commit_evidence

  Create a Merkle commitment for an evidence bundle hash. Used as the first step in ZK proof generation for Tier 3 assurance.

• get_telemetry_stats

  Get aggregate pipeline telemetry statistics including phase timings, success rates, and throughput metrics across all jobs.

• get_active_telemetry

  List currently active jobs with their current pipeline phase and telemetry status.

• get_job_telemetry

  Get full event timeline for a specific job — all pipeline phase transitions with timings and metadata.

• get_telemetry_logs

  Query structured logs with filters for level, source, jobId, kernelId, time range, and full-text search.

• emit_telemetry

  Manually emit a telemetry event for a job pipeline phase. Used by kernels and agents to report execution progress.

• submit_for_human_verification

  Submit an evidence bundle for human verification. Selects a panel of verifiers from the network and returns assigned verifier IDs.

• get_verification_assignments

  Get pending verification assignments for a verifier node. Returns requests this verifier has been assigned but not yet responded to.

• get_verification_status

  Get verification status for a request. Returns vote tally, consensus state, dispute list, and pending response count.

• respond_to_verification

  Submit a verifier's verdict for a verification request. Returns consensus state after this vote.

• dispute_verification

  File a dispute against the consensus verdict. Only verifiers who submitted a response can dispute. Requires additional evidence CID.

• register_capability_ip

  Register a capability as a Story Protocol IP Asset. Returns an ipId and NFT token. The designer earns royalties whenever this capability is used.

• register_job_evidence_ip

  Register job evidence as a derivative IP asset on Story Protocol, linking it to the parent capability's IP. Operators earn royalties from derivative use.

• distribute_royalties

  Set revenue splits for an IP asset among stakeholders (designer, operator, verifier, assembler, curator). Splits must sum to 100.

• pay_ip_royalty

  Pay royalties to an IP asset vault. The payer sends tokens that flow to stakeholders via the royalty splits.

• claim_ip_revenue

  Claim earned revenue from an IP asset vault. Returns the claimed amount and transaction hash.

• get_ip_revenue

  Get a revenue snapshot for an IP asset — total earned, pending claims, and recent payments.

• get_ip_lineage

  Get the full IP lineage chain for an asset — parent capabilities and all derivative job registrations.

• get_capability_ip

  Get the Story Protocol IP registration for a capability by its capability ID.

• raise_ip_dispute

  Raise a Story Protocol IP dispute against an asset. Provide evidence hash and reason.

• list_protocols

  List protocol templates in the library. Filter by tags, required capabilities, search query, or status.

• get_protocol

  Get protocol template details by ID. Returns steps, transfers, parameters, and metadata.

• create_protocol

  Create a new protocol template draft. Returns the new template ID.

• update_protocol

  Update an existing protocol template (must be in draft status). Returns updated name and version.

• publish_protocol

  Publish a draft protocol template, making it visible in the protocol library for others to discover and use.

• fork_protocol

  Fork a protocol template to create your own version with parameter overrides. Returns the new fork ID.

• get_protocol_forks

  List all forks of a protocol template. Shows who forked it and what parameters they changed.

• validate_protocol

  Validate a protocol template against a specific kernel — checks capability availability, transfer compatibility, and automation level feasibility.

• list_protocol_runs

  List protocol runs. Filter by status or kernelId.

• get_protocol_run

  Get protocol run status including step progress, transfer status, current phase, and evidence hashes.

• create_protocol_run

  Instantiate a protocol template as a run on a specific kernel with given parameter values.

• start_protocol_run

  Start execution of a protocol run that is in 'ready' or 'binding' state.

• pause_protocol_run

  Pause a running protocol run. Use resume_protocol_run to continue.

• resume_protocol_run

  Resume a paused protocol run from where it stopped.

• cancel_protocol_run

  Cancel a protocol run. Cannot be cancelled once completed or already cancelled.

• get_workflows

  List active instrument workflows in the orchestrator. Optionally filter by status.

• get_workflow

  Get detailed workflow information including steps, node assignments, and progress.

• get_transfer_graphs

  Get resource transfer graphs showing instrument topology, transfer edges, and mechanisms for all kernels.

• list_automation_status

  List automation status for all instrument transfer pairs. Shows current automation level, episode count, and training readiness. Filter by kernelId.

• get_automation_status

  Get automation status for a specific instrument-to-instrument transfer pair.

• record_episode

  Record a transfer episode for a node pair. Increments episode count toward VLA training threshold.

• advance_automation

  Advance the automation level for a transfer pair (manual → teleoperated → pilot_operated → vla_assisted → fully_autonomous). Requires sufficient training episodes.

• list_transfer_agents

  List all transfer agents (robots and human operators) available for instrument-to-instrument transfers.

• get_logistics_overview

  Logistics hub overview: active shipments, pending installations, and upcoming bookings.

• get_shipments

  List equipment shipments with tracking status. Optionally filter by status.

• create_shipment

  Create a new equipment shipment with origin, destination, package details, and provider.

• get_shipment_quote

  Get shipping quotes from logistics providers based on origin, destination, weight, and priority.

• get_installations

  List equipment installation orders with step progress and status.

• get_space_bookings

  List space bookings for hosting equipment. Optionally filter by status or space.

• search_spaces

  Search for lab/workshop hosting spaces. Filter by size, access schedule, and other requirements.

• get_space

  Get detailed information about a hosting space including power, amenities, safety features, and pricing.

• match_spaces

  Find hosting spaces that match specific machine requirements (voltage, area, etc.). Returns scored matches.

• get_marketplace_overview

  Equipment marketplace overview with demand/supply metrics across all capability types.

• get_equipment_classes

  List equipment classes (FDM printers, CNC mills, etc.) with market snapshot data including utilization, demand, and pricing.

• get_demand_supply

  Get network-wide demand vs supply timeline data for capacity planning and market analysis.

• calculate_roi

  Calculate ROI projection for onboarding equipment. Returns month-by-month revenue, cost, and break-even analysis.

• get_operator_dashboard

  Not available: no route answers GET /api/operator on this gateway. The operator's real kernels, devices and in-flight jobs are at GET /api/agent/me.

• get_operator_machines

  Answers 501 not_available: operator machines with utilization and uptime are not recorded on this gateway. The operator's real kernels, devices and in-flight jobs are at GET /api/agent/me.

• get_operator_earnings

  Answers 501 not_available: operator earnings history is not recorded on this gateway. Per-job payment state is at GET /api/jobs/:jobId/execution.

• get_operator_certs

  Answers 501 not_available: operator certifications are not recorded on this gateway (there is no certification store; certifications typed at registration are the operator's own claim and are not checked).

• get_sensor_channels

  List all registered sensor channels across kernels. Returns channel descriptors with units and ranges.

• get_kernel_sensors

  Get sensor channels for a specific kernel. Returns live channel descriptors.

• get_settlement_status

  Get settlement pipeline status including pending operations count, total value queued, and smart account address.

• get_settlement_epochs

  Get settlement epoch history showing past batch settlements with timing and operation counts.

• get_depin_stats

  DePIN treasury, soulbound capability certificates, and current reward epoch stats.

• mint_certificate

  Mint a soulbound capability certificate (cNFT via Metaplex Core) for a kernel. Proves a verified capability on-chain as an immutable credential. Step 5 of onboarding.

• onboard_machine

  Register a new machine on the PCC network. Provide machine details to create a registration record. Include `operator` ({walletAddress, displayName, email}): without it the registration is recorded as operator 0x0000000000000000000000000000000000000000 / "Unknown", and prove cannot match it to you.

• analyze_machine_docs

  AI analysis of machine documentation. Upload docs to get suggested capabilities, extracted specs, materials, and tolerances.

• redeem_invite

  One-click agent onboarding with an invite code. Provisions wallet, identity, LLM access, and PCC tools in a single call.

• check_invite

  Validate an invite code before redeeming it. Returns whether the code is valid and what it includes.

• list_batches

  List active and completed settlement batches.

• list_evidence

  List encrypted evidence bundles stored in the gateway.

• submit_demand

  Signal that you want a capability that doesn't exist on the network yet. Creates a demand signal and may auto-create a bounty if enough demand accumulates.

• list_bounties

  List open bounties for capabilities the network needs. Operators can claim these to earn rewards by onboarding new capabilities.

• claim_bounty

  Claim a bounty to onboard a new capability. The operator commits to registering the capability and completing verification.

• verify_bounty

  Verify bounty completion by scoring the delivered capability against requirements.

• get_top_demand

  Get top demand signals aggregated by capability type. Shows which capabilities are most wanted on the network.

• get_bounty_leaderboard

  Get the bounty hunter leaderboard showing top operators by bounties claimed and verified.

• create_investment_pool

  Create an investment pool for a capability bounty. Stakers earn future protocol fees when the capability goes live.

• stake_in_pool

  Stake USDC or credits into a capability investment pool.

• get_pool_earnings

  Check earnings from capability investment pools for a staker address.

• get_pool

  Get details of a specific investment pool including stakes, status, and revenue share terms.

• list_pools

  List all investment pools. Optionally filter by status or capability type.

• close_pool

  Close an investment pool to new stakes. Pool enters sunset phase.

• claim_pool

  Operator claims an investment pool reward after capability verification.

• convert_bounty_to_pool

  Convert an existing bounty into an investment pool. Allows community staking toward the bounty's capability.

• get_subnet_status

  Get Bittensor verification subnet health, agent bridge status, and network connectivity.

• get_subnet_miners

  List verification subnet miners on the Bittensor network. Returns miner addresses, scores, and leaderboard positions.

• list_conversations

  List agent-to-agent conversations showing topic, participants, message count, and status.

• submit_feedback

  Submit a bug report, suggestion, or general feedback about the PCC network.

• report_anomaly

  Report a detected anomaly — protocol failure, evidence mismatch, stuck job, or suspicious behavior. All agents on the network are notified.

• get_unresolved_anomalies

  List all unresolved anomalies on the network. Filter by severity, category, or target agent.

• get_agent_anomalies

  Get anomalies involving a specific agent, plus their trust impact score.

• resolve_anomaly

  Mark an anomaly as resolved with a resolution note.

• get_anomaly_stats

  Get aggregate anomaly statistics — total, unresolved, by severity, by category.

• report_protocol_failure

  Report a protocol failure — when a step in the evidence/escrow/verification pipeline breaks. System may auto-recover.

• pcc_dht_query

  Query the DHT for capabilities matching your requirements. Returns announcements from operators whose equipment matches the type, materials, and price range you specify.

• pcc_dht_announce

  Announce capabilities to the DHT network. Signs the announcement with your node's Ed25519 key and broadcasts to connected peers.

• pcc_dht_peers

  List known DHT peers and their connection status. Shows which nodes are currently connected to the gossip network.

• pcc_create_scope

  Create an execution scope for a job. Scopes define exactly which tool calls are allowed on a kernel during a job, with command budgets, retry limits, and time-to-live. Required before issuing SCOPED WRITE operations (protocol upload, run create, run action).

• pcc_revoke_scope

  Revoke an execution scope immediately (emergency stop). All pending tool calls under this scope are rejected. The kernel enters a stopped state. A new scope must be created to resume.

• pcc_scope_audit

  Get the audit trail for an execution scope — every tool call made under this scope, with validation results, timestamps, and outcomes.

• pcc_relay_tool_call

  Relay a tool call to a device executor. The brain (LLM) posts tool calls here; the executor (on the device) polls for them and executes locally. Used for the brain/executor split architecture.

• pcc_get_tool_result

  Get the result of a previously relayed tool call. Poll this endpoint until the executor has processed the call and posted results.

• pcc_camera_latest

  Get the latest camera frame from a kernel as a JSON snapshot (base64 JPEG + metadata). For raw JPEG image, use GET /api/ot2/camera/latest directly.

• pcc_chat_send

  Send a chat message to a kernel's operator or agent. Used for human-in-the-loop communication during job execution, troubleshooting, and escalation.

• pcc_chat_history

  Get chat history with a kernel. Returns messages between agents, operators, and users for a specific kernel.

• approve_registration

  Approve a submitted machine registration. Moves it from 'submitted' to 'approved' status, enabling the operator to activate and start accepting jobs.

• reject_registration

  Reject a machine registration with a reason. The operator can see the rejection reason and resubmit.

• activate_registration

  Activate an approved registration, making the operator's equipment live on the network and ready to accept jobs.

• prove_registration

  Fast-track: submit evidence that your device works and get auto-approved + activated immediately. No manual review needed. Submit a photo of test output, device health snapshot, or a full evidence bundle with completion events. If evidence meets requirements, registration jumps straight to 'active'.

• list_registrations

  List all machine registrations on the network. See pending, approved, active, and rejected registrations. Public endpoint — no auth required.

• get_registration

  Get details of a specific machine registration by ID, including capabilities, pricing, operator info, and current status.

• near_status

  Get NEAR Protocol chain-abstraction integration status. Returns supported chains (near, eth, base, arbitrum, optimism, polygon), supported assets (USDC, USDT, NEAR, ETH, WBTC), and capability flags. Use this to confirm cross-chain settlement is available before requesting quotes.

• near_quote

  Get a cross-chain payment quote from the NEAR 1Click solver network (chaindefuser.com). Provides optimal routing and fee estimates for funding PCC escrow contracts using any source asset on any supported chain. Call near_status first to confirm available chains/assets.

• near_intent

  Submit a cross-chain payment intent to the NEAR 1Click solver network. Creates a signed intent that routes the payment atomically across chains. Call near_quote first to obtain a quoteId. Intents typically settle within 30-60 seconds — poll near_intent_status to track progress.

• near_intent_status

  Check the settlement status of a submitted NEAR 1Click cross-chain payment intent. Statuses progress: pending → submitted → settled | failed. Returns txHash and explorerUrl when settled.

• protocol_state

  Read the PCCProtocol root contract state: current fee rate, total protocol fees collected, total escrow count, and registry addresses. Requires PCC_PROTOCOL_ADDRESS to be configured on the gateway.

• protocol_fee

  Calculate the protocol fee for a given USDC amount (6-decimal units). Returns the fee, the net amount after fee, and formatted versions of both. Use this before building escrow contracts to understand the true cost.

• protocol_token_fees

  Get total protocol fees collected for a specific ERC-20 token address across all escrows. Returns raw wei amount and human-readable formatted value.

• protocol_escrow_fees

  Get protocol fees collected from a specific escrow contract. Also returns whether the escrow was deployed via the protocol factory. Useful for auditing fee flows.

• protocol_create_escrow

  Create a new MilestoneEscrow contract via the PCCProtocol factory on-chain. Protocol-deployed escrows have fee collection and registry tracking built in. Requires PCC_GATEWAY_PRIVATE_KEY write access.

• pcc_dht_metrics

  Get a snapshot of DHT telemetry counters and recent events. Returns message counts, peer connection stats, query/announce rates, and a list of the last 50 metric events. Use for monitoring network health.

• marketplace_categories

  List all supplies and materials marketplace categories with the count of active listings in each. Categories cover the full spectrum of physical production inputs: raw metals, plastics, lab reagents, consumables, electronics, tooling, and more.

• marketplace_list_listings

  Search and filter supplies/materials marketplace listings. Operators buy raw materials here to fulfill capability contracts. Filter by category, in-stock status, location, or free-text query.

• marketplace_get_listing

  Get full details of a specific supplies/materials marketplace listing by ID. Returns pricing, availability, lead time, location, and tags.

• marketplace_create_listing

  Create a new supplies/materials listing in the marketplace. Suppliers post available raw materials, lab reagents, tooling, or consumables for other operators to purchase.

• marketplace_update_listing

  Update an existing supplies/materials listing (price, stock status, description, etc.). Pass only the fields you want to change.

• marketplace_delete_listing

  Remove a supplies/materials listing from the marketplace. The listing is immediately hidden from search results.

• marketplace_place_order

  Place a purchase order for supplies or materials. Calculates total price automatically (quantity × pricePerUnit). Returns an order with 'pending' status. Optionally links to an on-chain escrow for trustless settlement.

• marketplace_list_orders

  List marketplace supply orders. Filter by buyerId, sellerId, or status. Returns order history with pricing and status.

• marketplace_get_order

  Get details of a specific supply order including the associated listing details, quantity, total price, status, and optional escrow address.

• system_telemetry

  Raw system state dump — actual DB rows for kernels, devices, jobs, evidence, registrations, capabilities, agent conversations, audit log. No fake numbers, no summaries.

• operator_poll_jobs

  Operator polls for pending jobs assigned to their kernel. Returns queued jobs ready for execution. The pcc-node 0.1.1 daemon does not call it: it takes no jobs.

• operator_push_evidence

  Operator pushes evidence bundle from a completed job execution. Contains device ID, execution timestamp, result payload, and event timeline. Success is a receipt with stored: true naming this jobId. HTTP 200 with stored: false means nothing was stored: never follow it with status completed.

• operator_heartbeat

  Operator sends heartbeat with capability re-announcement. Keeps the kernel alive on the network and updates available capabilities.

• operator_update_job_status

  Operator reports a job's status (in_progress, completed, failed). The node path finishes a job in two calls: submit its evidence (POST /api/operator/evidence; pcc-node does this), and only if that receipt says stored: true for this jobId, set status completed here. HTTP 200 alone is not enough: the relay answers 200 with stored: false when it could not store the evidence (an unknown job, a storage failure); then set failed with the reason evidence_not_stored. On the current gateway, completed marks the job done and its timeline then says settled, but the escrow is not released yet (board G1). Do not call pcc_job_complete after this: it answers 409.

• pcc_submit_paid_job

  Fast-track paid job: one call from DHT discovery to funded escrow + active scope. Auto-negotiates, quotes, creates escrow with milestones, creates execution scope. Returns jobId, scopeId, escrowId, quote with pricing adjustments, contract terms. For testnet, escrow is mock-funded automatically.

• pcc_job_complete

  Complete a job: gathers tool call audit trail from execution scopes, builds evidence bundle with SHA-256 hash, stores evidence, revokes scopes, and settles escrow (mock or real). This is how a job run through execution scopes is finished. A node that submitted its evidence and set status completed (operator_update_job_status) must not call it: it then answers 409 ("Job already completed or completion in progress").

• pcc_job_settlement

  Get a job's settlement status from its own escrow records: status (settled only when a settlement read confirms the release; reported_released when the milestone record says released but nothing confirms it; simulated for a mock escrow; awaiting_settlement, no_settlement_record, unknown or unavailable otherwise), settled, payout, paidAmount (confirmed releases only), reportedReleasedAmount, quotedAmount, currency (recorded or null), escrow, milestones, the negotiation session, notices and asOf.

• pcc_get_tool_manifest

  Get the tool manifest for a kernel's device type. Lists all available tools with their safety classification (read, safe_control, scoped_write, privileged) and input schemas. Use to understand what tools are available before making tool calls.

• pcc_relay_generic_tool_call

  Relay a tool call to any kernel's device executor via the generic relay (not OT-2 specific). Works with any device type. Safe tools (read/safe_control) don't need a scope. Scoped write tools require an active execution scope. Returns a call ID — poll pcc_get_tool_result for the response.

• pcc_submit_request

  Submit a high-level capability request in natural language. The system automatically decomposes it into a capability DAG with dependencies, timelines, and budget allocation across fabrication, design, assembly, electronics, software, logistics, and verification nodes. Returns the request with full decomposed DAG. Example: 'Build a cute animatronic plush desk robot with servo-driven animations'.

• pcc_list_requests

  List all capability requests with optional filtering. Shows status, decomposed DAG summary, estimated costs, and timelines.

• pcc_get_request

  Get a capability request by ID with the full decomposed DAG — all capability nodes, their dependencies, estimated costs/hours, assigned operators, and linked bounty IDs.

• pcc_decompose_request

  Re-trigger decomposition of an existing capability request. Overwrites the existing capability DAG with a fresh decomposition. Useful after updating the description or budget.

• pcc_publish_request

  Publish all pending capability nodes in a request as bounties. Each node becomes a bidding opportunity for operators. Returns the list of created bounty IDs linked to each capability node.

• pcc_get_request_dag

  Get the capability DAG (directed acyclic graph) for a request as adjacency data — nodes with all fields plus explicit edges showing dependency relationships. Useful for visualization or workflow planning.

• pcc_get_request_critical_path

  Get the critical path (longest dependency chain) for a capability request. The critical path determines the minimum calendar time to complete the request. Returns node IDs in order, the full node details, and total hours on the critical path.

• pcc_assign_node_operator

  Assign an operator to a specific capability node within a request. The node status changes to 'assigned'. Operators claim nodes to indicate they will execute that capability.

• pcc_update_node_status

  Update the status of a capability node within a request. Valid transitions: pending → bidding → assigned → in_progress → completed (or failed). When all nodes complete, the request automatically moves to completed.

• pcc_update_request

  Update a capability request's title, description, budget, deadline, urgency, or contact info. Does not re-decompose — call pcc_decompose_request afterwards if you want a fresh DAG.

• pcc_cancel_request

  Cancel a capability request. Cancelled requests cannot be updated, decomposed, or published. This is a soft delete — the request remains visible with status 'cancelled'.

• pcc_oracle_status

  Not served by the PCC gateway: GET /api/oracle/health returns 404 there. PCC's verification oracle runs as a separate service, and this route answers only where a deployment fronts it. Agents never call the oracle to settle a job: settlement is the gateway's step after pcc_job_complete. Where it is served, it returns the oracle's EIP-712 signing address and chain ID.