Servidor MCP de PCC — Physical Capability Cloud

• Nombre en el registronetwork.capability/physical-capability-cloudverificado en el registro MCP

El nombre en el registro está bajo capability.network. El registro solo permite usar ese espacio de nombres a quien demuestra control del dominio por DNS o HTTP.

• Estadorespondecomprobado el 2026-10-26
• Herramientas256
• El servidor se llamaPhysical Capability Cloud
• Versión del servidor2.19.3+sha256.a93b6fab5a8a325daafb456917
• Versión del protocolo2025-06-18

El 2026-10-26 el servidor respondió a initialize y tools/list sin iniciar sesión. Primera respuesta en 79 ms.

• Aún no se ha juzgado si sus herramientas hacen el trabajo del producto.
• Comprobado 2 de los 7 días necesarios para juzgar su fiabilidad.

Lo dicen reglas a partir de las mediciones de arriba. La primera llamada probable la elige un modelo de la lista de herramientas; lee su descripción antes de fiarte.

• Nota INITE MCPtras una semanala nota necesita 7 comprobaciones diarias: 2 hasta ahora
• Uso3 estrellas en GitHub
• Respondiómidiendo2 de las 7 comprobaciones diarias necesarias para mostrar el porcentaje
• Mediana de la primera respuesta203 ms
• Espacio en el contexto del agente≈ 39.663 tokenslas definiciones de todas sus herramientas (256), que el agente lleva en cada turno
• Definiciones de herramientasA · 99 de 100
• Resultados tipados7 de 256 herramientasdeclaran outputSchema: el resultado llega tipado y se lee de una vez

• Parámetros sin descripción: en 10 de 256

Un programa comprueba el servidor una vez al día: initialize y tools/list, sin modelo. Los tokens son la longitud de las definiciones, a unos cuatro caracteres por token. La nota promedia seis comprobaciones del nombre, la descripción, el esquema y las anotaciones de cada herramienta; dice lo bien descritas que están, no si funcionan. La nota pondera solo lo medido: si responde (25%), si hace el trabajo del producto (25%), definiciones (20%), contexto (10%), uso (10%) y lo fácil que es conectarse (10%). Lo que no se midió queda fuera, y una instrucción oculta limita la nota a 40. El estado de los servidores MCP de los proveedores: método y números →

• 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…

• 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…

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

Las primeras 60 de 256, en el orden del servidor.