mcpField
B
Basis Protocol

Basis Protocol

ローカル
github.com/shlok-lgtm金融データ028 週間前に更新
リポジトリ

Basis Protocol について

Basis Protocol MCPは、ステーブルコイン、ウォレット、取引のリスク評価向けMCPサービス群です。旧モノリシック版は非推奨で、4つの分野別サーバーが推奨されています。現時点で旧ツールはすべてoracleサーバーに含まれます。

主な機能

  1. 01SII、PSI、RPIなどのスコア取得
  2. 02CQI構成とストレス評価
  3. 03規制レポートと伝染分析
  4. 04証拠・ライブシグナル用のスキャフォールド

活用シーン

  1. 01クライアントでステーブルコイン関連スコアを読む
  2. 02ウォレットや取引のリスク情報を取得する
  3. 03CQIなどの指標を用いてリスクを分析する

MCP 対応

MCP クライアント向けにリスクスコア取得ツールを公開します。分割後の他の3サーバーは、機能の提供が進むまで名前空間を確保するスキャフォールドです。

設定

ローカルサーバーの設定はどのクライアントでも共通です。コピーしてクライアントの MCP 設定ファイルに貼り付けてください。

mcp.json · 共通設定
{
  "mcpServers": {
    "shlok-lgtm-basis": {
      "command": "npx",
      "args": [
        "-y",
        "@basis-protocol/mcp-server"
      ]
    }
  }
}
起動コマンドnpx -y @basis-protocol/mcp-server

ローカルサーバーにはマシン上の実行環境（Node.js 18 以上など）が必要です。設定ファイルの場所はクライアントごとに異なります。

パッケージ
npm@basis-protocol/mcp-server1.0.3

ツール

8

掲載時のツール一覧 · 3 週間前に更新

パラメーター型必須説明
sort_byenumいいえ結果の並び順score_desc | score_asc | name
min_gradeenumいいえ任意の最低グレードフィルター（例：'B+' は B+ 以上を返します）A+ | A | A- | B+ | B | B- | C+ | C | C- | D | F

詳細

Basis Protocol MCP — 分割サーバー

2026-04-19： モノリシックな @basis-protocol/mcp-server （レジストリ名 io.github.basis-protocol/basis-mcp）は非推奨になりましたが、 引き続き公開され、機能します。新しい統合では、以下の4つのスコープ付きサーバーを インストールしてください。従来の8つのツールはすべて @basis/oracle-mcp に含まれています。他の3つは名前空間を確保し、 機能の提供開始まではスキャフォールドとして公開されます。

パッケージスコープソース
@basis/oracle-mcpスコアの読み取り — SII、PSI、RPI、累積インデックスpackages/oracle-mcp
@basis/cqi-mcp構成 — CQI ペア、ストレス、Basel SCO60 / MiCA / GENIUS レポート、RQS、伝染packages/cqi-mcp
@basis/witness-mcpエビデンス — アテステーション、TLSNotary 証明、CDA スナップショットpackages/witness-mcp
@basis/divergence-mcpライブシグナル — パルス、乖離、オラクルのストレス、コヒーレンスの低下、探索packages/divergence-mcp

共通 HTTP クライアント、型、ヘルパー、サーバーランナーは @basis/mcp-shared にあります。従来のモノリスは artifacts/basis-mcp にあります。分割の全記録については、 mcp_split_plan.md、 mcp_registry_entries.md、および blockers.md を参照してください。

MCP レジストリ

MCP レジストリは、MCP サーバーのアプリストアのように、MCP クライアントに MCP サーバーの一覧を提供します。

📤 MCP サーバーを公開する | ⚡️ ライブ API ドキュメント | 👀 エコシステムのビジョン | 📖 ドキュメント全文

開発状況

2025-10-24 更新：レジストリ API は API 凍結（v0.1） に入りました 🎉。今後1か月以上、API は破壊的変更のない安定した状態に保たれるため、インテグレーターは安心してサポートを実装できます。この凍結は v0.1 に適用され、v0 の開発は継続します。この期間を利用して、実際の統合で API を検証し、一般提供に向けた v1 の策定に役立つフィードバックを集めます。貢献とご辛抱に感謝します。皆さんの参加が、ここまでたどり着くうえで大きな力となりました！

2025-09-08 更新：レジストリのプレビュー版が公開されました 🎉（告知ブログ記事）。システムはより安定しましたが、これはまだプレビューリリースのため、破壊的変更やデータのリセットが発生する可能性があります。一般提供（GA）リリースは後日予定されています。GitHub ディスカッションまたは #registry-dev Discord（参加方法はこちら）で、ぜひフィードバックをお寄せください。

現在の主なメンテナー：

貢献

コラボレーションには複数のチャネルを利用しています。modelcontextprotocol.io/community/communication をご覧ください。

多くの場合（常にそうとは限りません）、アイデアは次の流れで進みます。

クイックスタート：
前提条件
  • Docker
  • Go 1.24.x
  • ko - Go 用コンテナーイメージビルダー（インストール手順）
  • golangci-lint v2.4.0
サーバーの実行
# Start full development environment
make dev-compose

PostgreSQL を使用して、レジストリが localhost:8080 で起動します。データベースは一時ストレージを使用し、コンテナーを再起動するたびにリセットされるため、開発とテストに適したクリーンな状態が保たれます。

注： レジストリでは、コンテナーイメージのビルドに ko を使用します。make dev-compose コマンドは、サービスの起動前に ko でレジストリイメージを自動的にビルドし、ローカルの Docker デーモンに読み込みます。

デフォルトでは、起動を高速化するために、レジストリは本番 API からサーバーを絞り込んだサブセットをシードします。これにより、ローカル環境が本番環境の動作を反映し、すべてのシードデータが検証に合格します。オフライン開発では、MCP_REGISTRY_SEED_FROM=data/seed.json MCP_REGISTRY_ENABLE_REGISTRY_VALIDATION=false make dev-compose を使用すると、検証せずにファイルからシードできます。

.env.example を参考に、docker-compose.yml の環境変数でセットアップを構成できます。

別の方法：ビルド済み Docker イメージの実行

ビルド済みの Docker イメージは、GitHub Container Registry に自動的に公開されます。

# Run latest stable release
docker run -p 8080:8080 ghcr.io/modelcontextprotocol/registry:latest

# Run latest from main branch (continuous deployment)
docker run -p 8080:8080 ghcr.io/modelcontextprotocol/registry:main

# Run specific release version
docker run -p 8080:8080 ghcr.io/modelcontextprotocol/registry:v1.0.0

# Run development build from main branch
docker run -p 8080:8080 ghcr.io/modelcontextprotocol/registry:main-20250906-abc123d

利用可能なタグ：

  • リリース：latest、v1.0.0、v1.1.0 など
  • 継続ビルド：main（最新の main ブランチのビルド）
  • 開発：main-<date>-<sha>（特定のコミットのビルド）
サーバーの公開

サーバーを公開するためのシンプルな CLI を用意しています。次のように使用できます。

# Build the latest CLI
make publisher

# Use it!
./bin/mcp-publisher --help

詳しくはパブリッシャーガイドをご覧ください。

その他のコマンド
# Run lint, unit tests and integration tests
make check

開発に役立つコマンドもいくつかあります。make help を実行して詳細を確認するか、Makefile をご覧ください。

アーキテクチャ

プロジェクト構成
├── cmd/                     # Application entry points
│   └── publisher/           # Server publishing tool
├── data/                    # Seed data
├── deploy/                  # Deployment configuration (Pulumi)
├── docs/                    # Documentation
├── internal/                # Private application code
│   ├── api/                 # HTTP handlers and routing
│   ├── auth/                # Authentication (GitHub OAuth, JWT, namespace blocking)
│   ├── config/              # Configuration management
│   ├── database/            # Data persistence (PostgreSQL)
│   ├── service/             # Business logic
│   ├── telemetry/           # Metrics and monitoring
│   └── validators/          # Input validation
├── pkg/                     # Public packages
│   ├── api/                 # API types and structures
│   │   └── v0/              # Version 0 API types
│   └── model/               # Data models for server.json
├── scripts/                 # Development and testing scripts
├── tests/                   # Integration tests
└── tools/                   # CLI tools and utilities
    └── validate-*.sh        # Schema validation tools
認証

公開には、複数の認証方法が用意されています。

  • GitHub OAuth - GitHub にログインして公開する場合
  • GitHub OIDC - GitHub Actions から公開する場合
  • DNS 検証 - ドメインおよびそのサブドメインの所有権を証明する場合
  • HTTP 検証 - ドメインの所有権を証明する場合

レジストリは、公開時に名前空間の所有権を検証します。例：

  • io.github.domdomegg/my-cool-mcp を公開するには、GitHub に domdomegg としてログインするか、domdomegg のリポジトリ上の GitHub Action である必要があります
  • me.adamjones/my-cool-mcp を公開するには、DNS または HTTP チャレンジを通じて adamjones.me の所有権を証明する必要があります

コミュニティプロジェクト

コミュニティによって作成された、レジストリ関連の注目すべき取り組みについては、コミュニティプロジェクトをご覧ください。

詳細なドキュメント

こちらで疑問が解決しない場合は、詳しくはドキュメントをご覧ください。

コメント

Markdown 対応

MCP は初めてですか？

プロトコルの概要から最初のサーバーの導入まで、よくある疑問にまとめて答えます。

AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。