Basis Protocol

io.github.shlok-lgtm由 GitHub 帳號 shlok-lgtm 發布v1.0.3更新於 Oct 24, 2026

Stablecoin risk scores, wallet risk profiles, and transaction risk assessment.

已驗證STDIO僅桌面金融安全與監控

概覽

AI 產生的概覽

Basis Protocol 提供的本機 stdio MCP 伺服器,讓助理取得穩定幣風險評分、錢包風險輪廓與交易風險評估。

可以做什麼
依註冊表描述及 oracle 範圍所列的 SII、PSI、RPI 與累計指數,取得穩定幣與相關指數的風險評分。查詢錢包風險輪廓並評估交易風險。README 說明單體套件已棄用,全部 8 個舊工具有現已歸入獨立的 oracle 套件,另外三個分域套件目前僅以雛形形式發布。
適用情境
適合助理在處理或回報加密資產前,需要查核穩定幣、錢包或交易風險時使用。新整合應考慮較新的分域套件,而非這個已棄用的單體套件。
執行需求
以本機程序透過 stdio 執行,從 npm 套件安裝。未宣告任何身分驗證、環境變數或請求標頭。僅限桌面端,不提供網頁可執行版本。
安裝前請注意
README 將此單體套件標示為已棄用但仍發布且可用,並建議新整合改用四個分域伺服器。風險評分屬第三方評估,不應視為財務建議。未宣告憑證,但使用前應確認此伺服器傳送哪些資料至 Basis Protocol 服務。

安裝

在 SourceWeft 中

  1. 開啟 儀表板中的 Basis Protocol,將其新增到工作區。
  2. 為需要使用其工具的對話啟用該服務。

Desktop only,透過 STDIO。 STDIO 服務會啟動本機處理程序,因此需要 SourceWeft 桌面主機。

其他 MCP 客戶端

參照 儲存庫 中的啟動說明。

README

Basis Protocol MCP — split servers

2026-04-19: The monolithic @basis-protocol/mcp-server (registry name io.github.basis-protocol/basis-mcp) is deprecated but still published and functional. New integrations should install the four scoped servers below. All 8 legacy tools now ship in @basis/oracle-mcp; the other three reserve their namespaces and publish as scaffolds while their feature sets ship.

PackageScopeSource
@basis/oracle-mcpScore reads — SII, PSI, RPI, accruing indicespackages/oracle-mcp
@basis/cqi-mcpComposition — CQI pairs, stress, Basel SCO60 / MiCA / GENIUS reports, RQS, contagionpackages/cqi-mcp
@basis/witness-mcpEvidence — attestations, TLSNotary proofs, CDA snapshotspackages/witness-mcp
@basis/divergence-mcpLive signals — pulse, divergence, oracle stress, coherence drops, discoverypackages/divergence-mcp

Shared HTTP client, types, helpers, and server runner live in @basis/mcp-shared. Legacy monolith lives at artifacts/basis-mcp. See mcp_split_plan.md, mcp_registry_entries.md, and blockers.md for the full split record.


MCP Registry

The MCP registry provides MCP clients with a list of MCP servers, like an app store for MCP servers.

📤 Publish my MCP server | ⚡️ Live API docs | 👀 Ecosystem vision | 📖 Full documentation

Development Status

2025-10-24 update: The Registry API has entered an API freeze (v0.1) 🎉. For the next month or more, the API will remain stable with no breaking changes, allowing integrators to confidently implement support. This freeze applies to v0.1 while development continues on v0. We'll use this period to validate the API in real-world integrations and gather feedback to shape v1 for general availability. Thank you to everyone for your contributions and patience—your involvement has been key to getting us here!

2025-09-08 update: The registry has launched in preview 🎉 (announcement blog post). While the system is now more stable, this is still a preview release and breaking changes or data resets may occur. A general availability (GA) release will follow later. We'd love your feedback in GitHub discussions or in the #registry-dev Discord (joining details here).

Current key maintainers:

Contributing

We use multiple channels for collaboration - see modelcontextprotocol.io/community/communication.

Often (but not always) ideas flow through this pipeline:

  • Discord - Real-time community discussions
  • Discussions - Propose and discuss product/technical requirements
  • Issues - Track well-scoped technical work
  • Pull Requests - Contribute work towards issues

Quick start:

Pre-requisites
Running the server
bash
# Start full development environmentmake dev-compose

This starts the registry at localhost:8080 with PostgreSQL. The database uses ephemeral storage and is reset each time you restart the containers, ensuring a clean state for development and testing.

Note: The registry uses ko to build container images. The make dev-compose command automatically builds the registry image with ko and loads it into your local Docker daemon before starting the services.

By default, the registry seeds from the production API with a filtered subset of servers (to keep startup fast). This ensures your local environment mirrors production behavior and all seed data passes validation. For offline development you can seed from a file without validation with MCP_REGISTRY_SEED_FROM=data/seed.json MCP_REGISTRY_ENABLE_REGISTRY_VALIDATION=false make dev-compose.

The setup can be configured with environment variables in docker-compose.yml - see .env.example for a reference.

Alternative: Running a pre-built Docker image

Pre-built Docker images are automatically published to GitHub Container Registry:

bash
# Run latest stable releasedocker 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 versiondocker run -p 8080:8080 ghcr.io/modelcontextprotocol/registry:v1.0.0
# Run development build from main branchdocker run -p 8080:8080 ghcr.io/modelcontextprotocol/registry:main-20250906-abc123d

Available tags:

  • Releases: latest, v1.0.0, v1.1.0, etc.
  • Continuous: main (latest main branch build)
  • Development: main-<date>-<sha> (specific commit builds)
Publishing a server

To publish a server, we've built a simple CLI. You can use it with:

bash
# Build the latest CLImake publisher
# Use it!./bin/mcp-publisher --help

See the publisher guide for more details.

Other commands
bash
# Run lint, unit tests and integration testsmake check

There are also a few more helpful commands for development. Run make help to learn more, or look in Makefile.

Architecture

Project Structure

├── 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

Authentication

Publishing supports multiple authentication methods:

  • GitHub OAuth - For publishing by logging into GitHub
  • GitHub OIDC - For publishing from GitHub Actions
  • DNS verification - For proving ownership of a domain and its subdomains
  • HTTP verification - For proving ownership of a domain

The registry validates namespace ownership when publishing. E.g. to publish...:

  • io.github.domdomegg/my-cool-mcp you must login to GitHub as domdomegg, or be in a GitHub Action on domdomegg's repos
  • me.adamjones/my-cool-mcp you must prove ownership of adamjones.me via DNS or HTTP challenge

Community Projects

Check out community projects to explore notable registry-related work created by the community.

More documentation

See the documentation for more details if your question has not been answered here!

來源:README.md,提交 47f1a58

工具

0
SourceWeft 尚未在沙箱中啟動過該軟體包,因此其工具未知。

版本歷史

1
  1. v1.0.3最新Sep 16, 2026

評分

已滿足適用檢查項的 40%

該評分衡量此收錄條目的完整程度,依據註冊中心條目、端點與公開來源計算得出。它不是對伺服器本身的評價,也不表示伺服器安全或目前可用:可連通性是帶日期的檢查結果,評分也不包含安裝量或使用者評價。

  • 近 30 天內可連通25 分

    請保持端點能夠回應 MCP 握手;SourceWeft 每 30 天探測一次。

  • 已宣告認證方式10 分

    請在註冊中心條目中宣告憑證請求標頭,或保持端點能夠回應探測,以便判定其認證方式。

  • 已列出工具15 分

    請讓伺服器在無憑證時回應 tools/list,或發布可在沙箱中無憑證啟動的軟體包。

  • 描述必需15 分
  • 圖示10 分
  • 文件15 分
  • 授權條款10 分

    請在儲存庫或註冊中心條目中宣告授權條款。