Servidor MCP de PCC — Physical Capability Cloud

• Nome no registronetwork.capability/physical-capability-cloudverificado no registro MCP

O nome no registro fica sob capability.network. O registro só libera esse espaço de nomes para quem prova controle do domínio por DNS ou HTTP.

• Estadorespondeverificado em 2026-10-26
• Ferramentas256
• O servidor se chamaPhysical Capability Cloud
• Versão do servidor2.19.3+sha256.a93b6fab5a8a325daafb456917
• Versão do protocolo2025-06-18

Em 2026-10-26 o servidor respondeu a initialize e tools/list sem login. Primeira resposta em 79 ms.

• Ainda não avaliamos se as ferramentas fazem o trabalho do produto.
• Verificado em 2 dos 7 dias necessários para julgar a confiabilidade.

Dito por regras a partir das medições acima. A primeira chamada provável é a escolha de um modelo na lista de ferramentas; leia a descrição antes de confiar nela.

• Nota INITE MCPdepois de uma semanaa nota precisa de 7 verificações diárias: 2 até agora
• Uso3 estrelas no GitHub
• Respondeumedindo2 das 7 verificações diárias necessárias para mostrar a porcentagem
• Mediana da primeira resposta203 ms
• Espaço no contexto do agente≈ 39.663 tokensas definições de todas as ferramentas (256), que o agente carrega a cada turno
• Definições das ferramentasA · 99 de 100
• Resultados tipados7 de 256 ferramentasdeclaram outputSchema: o resultado chega tipado e é lido de uma vez

• Parâmetros sem descrição: em 10 de 256

Um programa verifica o servidor uma vez por dia: initialize e tools/list, sem modelo. Os tokens são o tamanho das definições, a cerca de quatro caracteres por token. A nota é a média de seis verificações do nome, da descrição, do esquema e das anotações de cada ferramenta; diz se as ferramentas estão bem descritas, não se funcionam. A nota pesa só o que foi medido: se responde (25%), se faz o trabalho do produto (25%), definições (20%), contexto (10%), uso (10%) e a facilidade de conectar (10%). Uma parte não medida fica de fora, e uma instrução oculta limita a nota a 40. O estado dos servidores MCP dos fornecedores: método e 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.

As primeiras 60 de 256, na ordem do servidor.