プロトタイプ · プレビュー版:公式レジストリのすべてのサーバーを掲載し、30分ごとに同期しています。レビューとアカウント機能は今後のステップで始まります。
PopNx MCPAIを使う人のためのMCPサーバー · やさしい言葉で解説

PrivateDAO Agent Exchange

作者:X-PACTバージョン 1.7.2i★ –iクラウドで動く
レジストリ名io.github.X-PACT/pdao-agent-exchange

インストール

概要

作者による説明(英語の原文)

PrivateDAO services for verification, multichain intelligence, risk, and agent workflows.

PopNx MCPの3つの柱

この3つを1つのスコアにまとめることはしません。意見、測定、人気はそれぞれ別のものだからです。

できること

このサーバーのやさしい解説はまだ書いていません。以下はレジストリから読み取った事実です。

  • 接続方法: クラウドで動く
  • トランスポート: Streamable HTTP
  • カテゴリ: その他

インストール

使っているAIアプリを選んで、設定をコピーしてください。

インストールの前に

必要なもの

どのアプリを使っていますか?

上でアプリを選んでください。選んだアプリを覚えておくので、次からはボタンに「…にインストール」と表示されます。

ウェブ、デスクトップ、モバイルのClaudeで使えます:

  1. Settings → Connectors を開く
  2. Add custom connector を押す
  3. 下のアドレスを貼り付けて Add を押す
  4. サインインを求められたら、作者のサービスにサインインする
SettingsConnectors1+ Add2https://…3
https://agents.privatedao.org/mcp

ターミナルでこれを実行します

claude mcp add --transport http pdao-agent-exchange https://agents.privatedao.org/mcp

Cursorで開く

または、設定を自分でコピーする

プロジェクトの .cursor/mcp.json、または ~/.cursor/mcp.json に貼り付けます

{
  "mcpServers": {
    "pdao-agent-exchange": {
      "url": "https://agents.privatedao.org/mcp"
    }
  }
}

ブラウザがアプリを開いてよいか確認し、そのあとアプリが設定を表示して確認を求めます。キーの値は空欄のままなので、自分で入力してください。

VS Codeで開く

または、設定を自分でコピーする

プロジェクトの .vscode/mcp.json に貼り付けます

{
  "servers": {
    "pdao-agent-exchange": {
      "type": "http",
      "url": "https://agents.privatedao.org/mcp"
    }
  }
}

ブラウザがアプリを開いてよいか確認し、そのあとアプリが設定を表示して確認を求めます。キーの値は空欄のままなので、自分で入力してください。

ChatGPTがつなげるのは、インターネット上のサーバーだけです:

  1. ウェブ版のChatGPTを開き → Settings → Connectors (Apps)
  2. Create または Add を押す(プランによっては、先に Advanced で Developer mode をオンにする必要があります)
  3. 下のアドレスを貼り付け、名前を付けて保存する
  4. サインインを求められたら、作者のサービスにサインインする
SettingsConnectors1+ Create2https://…3
https://agents.privatedao.org/mcp

メニューの名前は、プランや時期によって少し違うことがあります。

選んだアプリは、この端末のCookieに保存されます。アカウントは不要です。

この設定は、作者のレジストリ登録情報から作成しています。READMEと違う場合は、READMEに従ってください。

できること

ツールの名前と説明は、サーバーが2026年11月7日に返したそのままの内容です。書いたのは作者で、私たちではありません。プレーンテキストとして表示しています。

  • get_workflow_guide

    Return the overview, execution, or payment workflow guide. Use this instead of separate guide tools when you need lifecycle context; it is free, read-only, and returns the selected next steps without executing or paying.

  • list_catalog

    List services, products, external capabilities, or network metadata with optional filters. This is free and read-only; use discover_agents for a task-specific match and create_paid_job only after selecting a service.

  • discover_agents

    Match a natural-language requirement or structured capabilities to first-party services and registered agents. Returns ranked matches without side effects or cost; use list_catalog for exact schemas and prices, and create_paid_job to execute selected paid work.

  • get_provider_integrations

    Return provider roles and integration metadata for planning. This is free and read-only; use list_catalog for purchasable capabilities and discover_agents for matching.

  • service_recommendation

    Translate a business or product objective into the most relevant PrivateDAO capabilities and a practical next step.

  • privatepay_status

    Read the current PrivatePAY x402 readiness, MagicBlock private-rail configuration, facilitator state, PDAO entry requirement, and public-chain privacy boundary. Call this first; it is free and read-only, creates no challenge, and never moves funds.

  • privatepay_challenge

    Create a fresh PrivatePAY x402 v2 challenge for a resource and quoted USDC amount. Call this before privatepay_verify; it returns exact payment requirements and the PDAO private-settlement rule, but never signs, broadcasts, or charges a wallet.

  • privatepay_checkout

    Create a MagicBlock PrivatePAY checkout or request the payment-required challenge for an existing checkout. Use this to begin a private checkout instead of create_paid_job with direct USDC; it returns commercial terms only and never signs, broadcasts, or moves funds.

  • privatepay_prepare

    Prepare an unsigned MagicBlock deposit, private transfer, or withdrawal for a local wallet to inspect and sign. Call this after privatepay_checkout and before wallet authorization; PrivateDAO never receives a private key and this tool never broadcasts.

  • privatepay_verify

    Verify an x402 v2 PrivatePAY payload through the configured facilitator against the exact original requirements. Call this after privatepay_challenge or privatepay_checkout and before privatepay_settle; it is read-only, fail-closed, and returns redacted evidence without spending

  • privatepay_settle

    Settle an already verified x402 v2 PrivatePAY payload through the configured facilitator and return redacted settlement evidence. Call this only after privatepay_verify with unchanged requirements; this is the payment-moving action and may create facilitator-side or on-chain sett

  • privatepay_job_payment

    Apply a finalized PrivatePAY x402 payment to an existing paid job and execute it once. Use this instead of submit_payment for a job created with payment_mode=privatepay; it consumes supplied payment proof, may settle funds, and returns workflow evidence.

  • verify_receipt

    Verify an asset/record or retrieve and validate a PrivateDAO receipt. Returns structured evidence and hashes; it is free and read-only, never pays or executes work, and replaces the separate basic, receipt, and get-receipt paths.

  • create_paid_job

    Create a selected paid PrivateDAO capability request and return an immediate result or exact quote-first payment intent. Use discover_agents or list_catalog first; payment_mode=privatepay starts the PrivatePAY flow, while direct uses ordinary USDC. This call never spends funds.

  • submit_payment

    Confirm an authorized payment reference for a selected request and return the payment/execution result. Use this after create_paid_job and only with the exact returned quote; it may write payment state and never accepts a guessed amount.

  • job_status

    Read the current state, exact payment intent, result, or receipt reference for a request. Poll this after create_paid_job, privatepay_job_payment, or submit_payment; it is free and read-only, never retries payment, and never executes work again.

  • cancel_job

    Cancel an unpaid pending request before execution and return its updated status. It records cancellation only, never spends or refunds funds, and must not be used after payment or execution has started.

基本チェックi

誰でも見られる情報をチェックしており、コードは読んでいません。当てはまらない項目は数に入れていません。 · 2026年11月7日にチェック

  • ✓ 合格

    作者とリポジトリが一致

    レジストリ名は、リポジトリを所有するGitHubアカウント X-PACT で確認済みです

  • … 未チェック

    今もメンテナンスされている

    このリポジトリはまだGitHubから読み取っていません

  • … 未チェック

    ライセンスがある

    このリポジトリはまだGitHubから読み取っていません

  • ✓ 合格

    エンドポイントが応答する

    436ミリ秒で応答(HTTP 200)

  • – 対象外

    OAuthでサインイン

    サインイン不要

  • ✓ 合格

    ツールの説明に隠れた指示がない

    17件のツールの説明を読み、AIへの隠れた指示は見つかりませんでした

その他のほかのサーバーとの比較i

  • このカテゴリのほかの32725件のうち0%よりスターが多い
  • このカテゴリのほかの32725件のうち73%より最近レジストリに公開
  • 基本チェックの結果が、このカテゴリのほかの32725件のうち100%と同じかそれ以上

レジストリでこのカテゴリにある有効なすべてのサーバーと比較しています。スターは、公開者がリポジトリの所有者である場合だけ数えます。

よくある質問

PrivateDAO Agent Exchangeは安全ですか?

当てはまる基本チェック3項目のうち3項目に合格しました。コードは読んでいません。キーやトークンを追加する前に、サーバーがどんなアクセスを求めているかを確認し、必要な権限だけを持つキーを使ってください。

どんなキーやコードが必要ですか?

レジストリには必須のキーは載っていません。ただし、最初に使うときにサインインを求めるサーバーもあります。

パソコンで動きますか、それともクラウドですか?

作者のクラウドで動きます。インストール不要でインターネット経由でつながりますが、送った内容は作者のサーバーを通ります。

今もメンテナンスされていますか?

GitHubリポジトリの最終更新は–、最新バージョン(1.7.2)がレジストリに届いたのは13 日前です。

どのアプリで使えますか?

Claude Desktop、Claude Code、Cursor、VS CodeなどのMCP対応アプリで使えます。URLでつながるので、リモートMCPサーバーに対応したアプリ(開発者モードのChatGPTなど)でも使えます。

代わりに使えるものは?

同じカテゴリには:Spec Driven Development, Remote Desktop Commander, Signoff

代わりの候補

同じカテゴリで、ほかの作者が作ったサーバー。スターの多い順。

カードの見方:★ GitHubスターi3つの柱:レビュー · チェック · 利用状況i更新=最新バージョンをレジストリに公開した日i

Remote Desktop Commander

作者:desktop-commander

Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.

クラウドで動く★ 211一昨日更新
インストール

Signoff

作者:ayuanxx-max

Five gates that make an agent's 'done' provable: run them, read the verdict, audit the record.

パソコンで動く今日更新
インストール

作者のREADME

READMEを開く

作者のリポジトリから書かれたとおりにコピーしたものです。PopNx MCPは内容を確認・推奨していません。HTML、画像、スクリプトは取り除いています。リンクはこのサイトの外へ移動します。

PrivateDAO

Private decisions. Verifiable outcomes.

PrivateDAO is a privacy-first operating layer for organizations that need to run sensitive work without making every detail public. It helps teams define rules, run workflows, approve actions, execute through the appropriate infrastructure, and share evidence of the outcome.

PrivateDAO is built for organizations entering Web3 as well as organizations that never intend to become crypto companies. A business can keep its existing operating model and add verifiable Web3 capability only where it is useful: private payroll, controlled treasury actions, governance, procurement, and verification. Privacy is the product principle; blockchain, wallets, and cryptography are execution infrastructure behind that principle.

Product direction

The project is organized around six core organizational workflows:

  1. Confidential Payroll - pay people without publishing salary records.
  2. Treasury Coordination - approve and reconcile sensitive spending.
  3. Private Governance - make and prove decisions without exposing every discussion.
  4. Confidential Auctions - run sealed procurement and competitive bids.
  5. Blind Verification - prove that a condition was met without revealing the underlying information.
  6. Record Verification - prove that a document, event, or result is valid without publishing private fields.

These workflows share the PrivateDAO Kernel, policy controls, execution adapters, receipts, and reconciliation boundaries. The public product surface is intentionally simple; technical network details remain available for builders, reviewers, and operators.

Next milestone: PDAO Wallet

The next product milestone is PDAO Wallet, an account and policy layer for organizations rather than a single consumer wallet. The planned wallet suite will support:

  • corporate accounts for the six core workflows and institution management;
  • an autonomous AI wallet for bounded, policy-controlled agent operations;
  • a B2B wallet for organizations, counterparties, and service settlement;
  • role-based permissions, approval thresholds, spending policies, signing boundaries, receipts, reconciliation, and audit-ready evidence.

PDAO Wallet will be developed as a capability layer above the PrivateDAO Kernel. It will remain independent from any single chain or provider, while each network adapter is required to provide real implementation and evidence before it is described as supported.

Quantum-security roadmap

PrivateDAO plans a quantum-resilience layer above the Kernel and PDAO Wallet. This work will evaluate current post-quantum and hybrid cryptographic libraries, key-agility patterns, signing policies, migration paths, and hardware-backed execution as the standards and production libraries mature. The implementation will use maintained, independently reviewed libraries and explicit compatibility gates. This roadmap is not a claim that PrivateDAO is currently quantum-safe, certified, or externally audited for post-quantum security.

Ecosystem programs and technology partners

PrivateDAO is participating in the following programs based on accepted program communications and the partnership records maintained by the project owner:

OrganizationProgram or relationshipPrivateDAO use in this project
MongoDBMongoDB Partner Program and MongoDB for StartupsEvidence-history storage, search, and startup infrastructure validation
IBMIBM Partner PlusEnterprise AI and watsonx integration evaluation
AMDAMD AI Developer ProgramAI workload, accelerator, and performance validation
IntelIntel Partner PlusOpenVINO inference and performance validation
GitHubGitHub Developer ProgramDeveloper tooling, repository provenance, and integration testing
DigitalOceanDigitalOcean developer infrastructure accessCloud compute, storage, and deployment experimentation

These program relationships do not by themselves mean endorsement of every PrivateDAO product, certification, customer reference, grant award, or joint commercial offering. Product capabilities remain subject to the evidence and status recorded in the repository. The supporting acceptance emails and public announcements are retained by the project owner; this repository records the program names and their intended technical role without reproducing private correspondence.

The PDAO Wallet roadmap will use these relationships for storage, AI inference, hardware/performance testing, developer tooling, and operational validation as the relevant integrations are enabled. See the ecosystem program record for the technical scope and disclosure boundary.

Evidence language

This repository distinguishes three states:

  • Verified - backed by current source, runtime, or independently checkable execution evidence.
  • Planned - an approved product or engineering milestone that is not yet a completed production capability.
  • Historical - retained material that explains prior work but is not a current product claim.

Network configuration, an address, a UI label, or a passing unit test alone is not evidence of a live product execution path. See the capability matrix and linked evidence for the status of each network and workflow.

Live Testnet program: EP9xE8MJZ6FfyEwLqns6HDdUZBknEa7WGYs1Jzsecuva

Historical Devnet proof registry program: 5AhUsbQ4mJ8Xh7QJEomuS85qGgmK9iNvFqzF669Y7Psx (docs/proof-registry.json); this is retained as provenance and is not the current Testnet deployment.

An organization does not need to become a Web3 or crypto company to use PrivateDAO. A company, institution, financial team, DAO, data provider, or Web3 operator can start with a familiar business workflow and add wallets, networks, settlement, or verifiable Web3 capability only where it creates value.

What PrivateDAO provides

Private operations
  • Confidential Payroll - prepare payroll, apply tax and deduction rules, collect approvals, settle through a supported private-payment path, and produce a verifiable result without exposing employee records.
  • Treasury Coordination - manage spending requests, budgets, approvals, execution, reconciliation, and evidence for sensitive financial operations.
  • Private Governance - coordinate proposals, committees, delegation, and decisions while keeping sensitive discussion and voting context private where the workflow requires it.
Private transactions and markets
  • Confidential Auctions - protect competing bids until the agreed close, then produce a fair and checkable result.
  • Private Settlement Workflows - move an approved operation through a supported settlement provider and retain a receipt with clear lifecycle status.
Verification
  • Blind Verification - prove that a condition or policy was satisfied without revealing the underlying data.
  • Record Verification - create a shareable, tamper-evident record for a document, event, approval, or business result without publishing private fields.
  • Private Identity Verification - support selective confirmation of identity, entity, jurisdiction, or authorization requirements while keeping the source material private.
Agent and community products
  • PrivateDAO Agent Exchange - an MCP-compatible service marketplace for verification, blockchain intelligence, market context, agent discovery, and verifiable receipts.
  • PDAO Worlds - an independent community game about privacy, trust, evidence, and coordination. It is a separate product and does not define the commercial workflow runtime.
Community

PDAO Worlds is the community layer for education, experimentation, and shared participation around PrivateDAO. It is separate from the organization workflow products and does not change the evidence or security requirements of the Kernel, PDAO Wallet, or settlement paths.

PDAO token surface

The current published token surface is documented in docs/pdao-token.md and the machine-readable attestation is docs/pdao-attestation.generated.json. The documented Testnet governance token is PDAO with mint DFYvBdivHCe4bSErgCiKm2RhwGEcZYbBPFQzLNr37Bie and a published initial supply of 1,000,000 PDAO. These references describe the current evidence surface; they do not claim Mainnet launch, market liquidity, or speculative returns.

How it works

Choose the workflow

-> define rules and participants -> run privately -> approve and execute -> reconcile the result -> share only the evidence that others need

The customer-facing workflow comes first. Wallets, providers, networks, RPC clients, cryptography, and settlement details remain behind the product boundary until execution requires them.

Agent Exchange

The production Agent Exchange is available at:

The endpoint is designed for standard MCP clients and exposes discovery, verification, intelligence, agent matching, job lifecycle, payment-aware receipts, and marketplace capabilities. Free discovery and read-only tools are separate from paid service execution. A client must use the published schemas and receipts; a frontend response is not payment proof.

Current payment and network claims are capability-specific. Where a service requires payment, the active payment rail and supported target network are returned by the service catalog. Do not infer that every advertised target network has the same execution or payment capability.

Kernel and runtime architecture

The current separation between the six enterprise products and the external Agent Exchange is documented in docs/architecture/enterprise-kernel-boundary-20261014.md.

The repository contains provider-neutral runtime contracts in packages/privatedao-runtime. The Kernel and Protocol layers provide common boundaries for:

  • product capabilities and permissions;
  • provider selection and lifecycle states;
  • wallet-signing boundaries;
  • preparation, submission, confirmation, and receipts;
  • reconciliation, idempotency, normalized errors, and telemetry;
  • MCP, REST, SDK, and agent-facing contracts.

Network-specific transaction construction belongs behind adapters. The runtime package does not store private keys, contain a wallet signer, or invent a successful receipt. A configured network is not considered supported merely because it appears in a UI or configuration file; it needs a real adapter and independent evidence.

Review and operating references

The repository keeps security, release, runtime, and operating evidence available for reviewers. These documents describe engineering evidence and boundaries; they are not claims of incorporation, certification, partnership, or mainnet readiness unless the referenced document says so explicitly.

  • Security review
  • Threat model
  • Security coverage map
  • Failure modes
  • Replay analysis
  • Live proof
  • Devnet release manifest
  • Verification gates
  • [Mainnet readiness](do

冒頭だけを表示しています。続きはリポジトリで読めます

PopNxに聞く