
ChromaDB Remote MCP Server
io.github.meloncafe由 GitHub 账号 meloncafe 发布v1.0.2更新于 Oct 24, 2026
Remote ChromaDB vector database MCP server with streamable HTTP transport
发布方自己的服务:Registry Mcp
概览
自托管的远程 ChromaDB 向量数据库 MCP 服务器,通过 streamable HTTP 让助手管理集合与文档并进行语义检索。
- 可以做什么
- 列出、创建、幂等获取、修改、删除和查看集合,包括计数与内容预览
- 添加、upsert、读取、更新和删除文档,可附带向量与多模态 URI
- 对文档执行语义查询,并可按 ID 或 URI 预过滤
- 读取服务器信息,如心跳、版本、最大批大小和用户身份
- 可选开启的混合检索、分叉、索引状态、租户与数据库管理以及破坏性重置工具
- 适用场景
- 适合希望多个 Claude 客户端共享同一个私有自托管向量库用于检索与记忆的场景,也适合让助手直接管理 ChromaDB 集合和文档,而不必另写脚本。
- 运行要求
- 需要一个已部署的服务器实例(Docker Compose 栈含 ChromaDB 与 Caddy 代理,或用 Node.js 与 yarn 从源码构建)并通过 HTTP 访问;需提供该部署的 CHROMADB_MCP_URL;对外暴露时必须设置 MCP_AUTH_TOKEN,以 Authorization Bearer 头发送;可选配置 OIDC 发行方、ALLOWED_ORIGINS 和 ChromaDB 凭据。
安装
在 SourceWeft 中
- 打开 控制台中的 ChromaDB Remote MCP Server,将其添加到工作区。
- 为需要使用其工具的对话启用该服务。
Web executable,通过 Streamable HTTP。 远程服务在工作区中配置后即可从网页运行时运行。
交给智能体安装
把这段提示词粘贴到 Claude Code、Codex、Cursor 等智能体,或 SourceWeft 对话中。智能体会读取该服务器的安装指南,先向你展示发布者、端点和登录方式,经你同意后再把它添加到你的客户端。密钥不会写进任何命令。
阅读 https://sourceweft.com/mcp/io.github.meloncafe%2Fchromadb-remote-mcp/install.md,并按其中说明把这个 MCP 服务器接入我的客户端。修改任何配置之前,先告诉我它的发布者、端点和登录方式,等我确认。不要把 API 密钥写进命令或我会提交的文件;问我密钥应从哪里获取。其他 MCP 客户端
把它添加到你客户端的 mcpServers 配置中。
{
"mcpServers": {
"chromadb-remote": {
"type": "http",
"url": "https://meloncafe.github.io/chromadb-remote-mcp/mcp"
}
}
}README
ChromaDB Remote MCP Server
[MCP] [TypeScript] [License] [MseeP.ai] [codecov] [DeepSource]
A Streamable HTTP MCP (Model Context Protocol) server that provides remote access to ChromaDB for AI assistants like Claude. Enables semantic search and vector database operations from mobile devices and remote locations.
Note: This project uses MCP Streamable HTTP (2025-03-26 spec). SSE transport is deprecated.
Cross-Platform AI Memory Server
Compatible with ALL major AI platforms:
- Claude (Desktop, Mobile, Code)
- Gemini (CLI, Code Assist)
- Cursor, Cline, Windsurf, VS Code Copilot
- and use Remote MCP with any other MCP-compatible client
Features
Remote MCP server that enables all Claude clients (Desktop, Code, Mobile) to access the same self-hosted ChromaDB instance.
- Shared Memory Across Devices - All Claude clients use the same ChromaDB instance
- Self-Hosted & Private - Your data stays on your infrastructure
- Remote Access - Connect from anywhere via Tailscale or public internet
- Complete ChromaDB Support - All CRUD operations via MCP tools
- REST API Proxy - Direct ChromaDB access for Python/JavaScript
- Unified Authentication - Single token protects both MCP and REST API endpoints
- Easy Deployment - One-command installation with Docker
Architecture
Overview
How Clients Connect:
- Claude Desktop + Mobile: Set up once using custom connector in Claude Desktop, and it automatically syncs to the mobile app. Both share the same connection automatically.
- Claude Code: Requires separate setup using
claude mcp addCLI command.
All clients access the same self-hosted ChromaDB through this remote MCP server. Vector embeddings and semantic search results persist across all platforms.
API Endpoints
How It Works
- Claude Desktop/Mobile: Add MCP server via custom connector (syncs automatically between devices)
- Claude Code: Add MCP server using
claude mcp addCLI command - Remote MCP Server authenticates requests and translates MCP protocol to ChromaDB operations
- ChromaDB stores and retrieves vector embeddings for semantic search
- Python can also access ChromaDB directly via the proxied REST API
Benefits:
- Same vector database across all clients
- Desktop and mobile share connection automatically
- Self-hosted and private
- Persistent memory across app restarts
- Single source of truth for embeddings
Quick Start
One-Command Installation
This will:
- Download
docker-compose.ymland.env.example - Auto-detect Docker Compose command (
docker-composeordocker compose) - Auto-generate a secure authentication token (optional)
- Configure ChromaDB data storage location (Docker volume, local directory, or custom path)
- Pull Docker images
- Display your authentication token and connection URL
Manual Installation
Option 1: Docker (Recommended - Pre-built Image)
Option 2: Build from Source
Option 3: Local Development
Generate Secure Token
For production use, generate a secure token for MCP_AUTH_TOKEN in .env:
Copy the generated token and paste it into your .env file:
Server Endpoints
- MCP:
http://localhost:8080/mcp(via Caddy proxy) - Health:
http://localhost:8080/health - ChromaDB API:
http://localhost:8080/api/v2/* - Swagger UI:
http://localhost:8080/docs
Configuration
Environment Variables (.env file)
All configuration is done through the .env file. Copy .env.example to .env and customize:
Authentication
IMPORTANT: For public internet access (Tailscale Funnel, Cloudflare Tunnel, etc.), you must set MCP_AUTH_TOKEN in your .env file.
Generate a secure token:
Edit your .env file:
Then restart the services:
Supported authentication methods (v2.0.0):
-
Authorization: Bearer TOKEN— only supported way to sendMCP_AUTH_TOKEN.- Recommended for service-to-service callers (API clients, scripts, MCP relays).
- Compliant with MCP specification.
- Example:
curl -H "Authorization: Bearer YOUR_TOKEN" https://your-server.com/mcp
-
OAuth 2.1 / OpenID Connect — recommended for human users.
- Set
OIDC_ISSUERS(comma-separated issuer URLs) orOIDC_PRESET=google,github,microsoft. - Set
OIDC_AUDIENCEto the resource identifier (typically your MCP server's public URL). - The server publishes RFC 9728 Protected Resource Metadata at
/.well-known/oauth-protected-resource. - 401 responses include
WWW-Authenticate: Bearer error="...", resource_metadata="..."per RFC 6750.
- Set
Removed in v2.0.0:
X-Chroma-Tokenheader and?apiKey=/?token=/?api_key=query-parameter auth are no longer accepted. Clients that previously used those paths must migrate toAuthorization: Bearer. TheALLOW_QUERY_AUTHenv var is ignored.
Origin Header Validation (DNS Rebinding Protection)
The server validates the Origin header for browser requests to prevent DNS rebinding attacks. This security feature is enabled by default and protects your local MCP server from malicious websites.
Default allowed origins (always permitted):
- Localhost variants:
localhost,127.0.0.1,[::1] - Claude.ai domains:
https://claude.ai,https://api.anthropic.com
Configure additional allowed origins:
If you need to allow additional web applications or custom domains, add them to ALLOWED_ORIGINS in your .env file:
When to configure ALLOWED_ORIGINS:
- ✅ Using Claude Desktop Custom Connector → No configuration needed (allowed by default)
- ✅ Accessing from custom web applications → Add your application's domain
- ✅ Using Swagger UI remotely → Add your server's domain
- ❌ Using Claude Code CLI → Not needed (no Origin header)
- ❌ Using Python/JavaScript clients → Not needed (no Origin header)
- ❌ Local development only → Not needed (localhost is allowed by default)
Example configurations:
Note: Claude.ai domains (https://claude.ai, https://api.anthropic.com) and localhost are always allowed, even if ALLOWED_ORIGINS is empty. Server-to-server requests (without Origin header) are always permitted.
Data Storage Configuration
ChromaDB data can be stored in three ways:
-
Docker volume (default):
CHROMA_DATA_PATH=chroma-data- Managed by Docker
- Survives container restarts
- Use
docker volume lsanddocker volume inspect chroma-datato locate
-
Local directory:
CHROMA_DATA_PATH=./data- Easy to backup and access
- Stored in installation directory
-
Custom path:
CHROMA_DATA_PATH=/path/to/data- Must be an absolute path
- Useful for mounting external storage
After changing CHROMA_DATA_PATH, restart the services:
Connecting Claude
Claude Desktop + Mobile
Method 1: Custom Connector (Recommended - Pro/Team/Enterprise)
- Open Claude Desktop → Settings → Integrations → Custom Connector
- Click "Add Custom Server"
- Enter:
- Name:
ChromaDB - URL:
https://your-server.com/mcp(setAuthorization: Bearer YOUR_TOKENin the connector's header config)
- Name:
Note: Custom connector automatically syncs to the mobile app. Authentication is mandatory for remote access.
Method 2: mcp-remote Wrapper (Free/Pro Users)
If you don't have access to Custom Connectors, use the mcp-remote package as a workaround:
Configuration file location:
- macOS:
~/Library/Application Support/Claude/claude_desktop_config.json - Windows:
%APPDATA%\Claude\claude_desktop_config.json
Add to configuration file:
Restart Claude Desktop after editing the file.
Important: Remote MCP servers cannot be configured directly in
claude_desktop_config.jsonusingstreamableHttptransport. You must either use Custom Connectors or themcp-remotewrapper package.
Claude Code
CLI Command:
Available Tools (v2.2.0)
The MCP server provides these tools for Claude. v2.2.0 expands coverage to 30 tools across collection / document / search / fork / client-info / admin / destructive groups.
Collection Management
chroma_list_collections- List all collections (withlimit/offset)chroma_create_collection- Create a new collection (configuration/schemaoptional)chroma_get_or_create_collection- Idempotent create-or-get (v2.2.0)chroma_modify_collection- Rename / change metadata or configuration (v2.2.0)chroma_delete_collection- Delete a collectionchroma_get_collection_info- Get collection metadatachroma_get_collection_count- Get document count (read_leveloptional)chroma_count_collections- Total collection count (v2.2.0)chroma_peek_collection- Preview collection contents
Document Operations
chroma_add_documents- Add documents (withurisfor multi-modal)chroma_upsert_documents- Idempotent insert-or-update (v2.2.0)chroma_query_documents- Semantic search (withquery_uris/idspre-filter)chroma_get_documents- Retrieve documents (read_leveloptional)chroma_update_documents- Update existing documents (withembeddings/uris)chroma_delete_documents- Delete byidsand/orwhere/where_documentfilter
Server Info (v2.2.0)
chroma_heartbeat- Server heartbeat (nanosecond timestamp)chroma_get_server_version- Server version stringchroma_get_max_batch_size- Max batch size (for client-side splitting)chroma_get_user_identity- Current tenant + databases
Distributed/Cloud-only — opt-in (CHROMA_DISTRIBUTED_TOOLS_ENABLED=true)
These 4 tools require ChromaDB's distributed executor (the executor is the chromadb-server-internal frontend layer, not an algorithmic distribution requirement). The single-node open-source server (chromadb/chroma:latest docker) ships with the local executor, which has these methods hard-coded as unimplemented in rust/frontend/src/executor/local.rs and rust/types/src/api_types.rs. To use them you need either Chroma Cloud (CloudClient) or a self-hosted distributed Chroma deployment (Kubernetes multi-component: frontend + query executor + WAL + compactor + object storage).
Hidden by default so single-node deployments don't waste LLM context on tools that always return "not implemented for local executor" / "unsupported for local chroma".
chroma_search- Hybrid dense + sparse search (RRF). The algorithm itself works on a single node; chromadb open-source simply hasn't implemented thesearch()endpoint in the local executor.chroma_fork_collection- Zero-copy fork (segment-level operation on object storage — architecturally requires the distributed compactor/storage stack).chroma_get_fork_count- Fork metadata lookup (depends on the distributed metadata store).chroma_get_indexing_status- WAL offset + compactor index progress (requires the distributed WAL/compactor services).
Admin — opt-in (CHROMA_ADMIN_TOOLS_ENABLED=true)
chroma_admin_create_database/chroma_admin_get_database/chroma_admin_list_databaseschroma_admin_create_tenant/chroma_admin_get_tenant
Destructive — opt-in (CHROMA_ALLOW_DESTRUCTIVE_OPS=true)
Calls emit a [DESTRUCTIVE] audit line.
chroma_reset_database- Reset entire database (irreversible)chroma_admin_delete_database- Delete a database (requires both flags)
Using ChromaDB from Python
The MCP server proxies all ChromaDB REST API endpoints, allowing direct access from Python clients.
Python Example
Alternative authentication:
API Documentation
Visit https://your-server.com/docs for Swagger UI documentation of all ChromaDB REST API endpoints.
Deployment
Deploying with deploy.sh
deploy.sh wraps the Docker Compose lifecycle of this repository's docker-compose.yml in one script. It is host independent: everything host specific lives in .env (see .env.example) and optional extra compose files, never in the script.
./deploy.sh help prints the usage.
Settings — read from the host's .env (a process environment variable of the same name takes precedence):
DRY_RUN=1, DEPLOY_DIR=<dir> (target directory, for tests) and CHROMA_IMAGE=<ref> (image for the backup tar when no chromadb container exists) are read from the process environment.
One stack per host — docker-compose.yml fixes container_name (chromadb, chroma-mcp-server, caddy-proxy), so changing only COMPOSE_PROJECT_NAME does not let a second stack run on the same host: the container names collide.
Compose file selection — COMPOSE_FILE is a list merged in order (later files override earlier ones), exactly like docker compose. Relative entries resolve against the deploy directory, absolute entries are used unchanged. deploy.sh passes --project-directory on every call, so .env and relative paths always refer to the deploy directory.
DRY_RUN=1 — prints every docker command prefixed [DRY-RUN], calls no docker and changes no file; it works even without docker installed. install prints its plan without copying .env or creating backups/; version / update skip the digest judgment, the .env write and the mcp-server recreation. A missing .env is downgraded to a warning: the plan is printed from the committed .env.example / compose defaults and no file is created. Without DRY_RUN, a missing .env is still an error.
Output language — help and log messages are English or Korean. The language is DEPLOY_LANG (environment, then .env); if unset, the first non-empty of LC_ALL, LC_MESSAGES, LANG: a value starting with ko selects Korean, anything else English.
CHROMA_SERVER_VERSION handling — the Chroma server reports a hardcoded 1.0.0, so update / version compare the RepoDigest of the chromadb container's image with the digest pinned in the compose file and then with the Docker Hub digest of the pinned tag, and record the result in .env. When the value changed, mcp-server alone is recreated with up -d. If the version cannot be determined (including a match on the Docker Hub latest tag alone), an existing .env value is preserved with a warning; unknown is written only when no value exists yet.
Backup — ./deploy.sh backup reads the data through a throwaway container with a read-only mount, so root-owned bind directories and named volumes both work. The data location is detected automatically: the existing chromadb container's /data mount first, otherwise CHROMA_DATA_PATH from .env (an absolute, ./ or ../ path is a bind mount; a bare name — the default chroma-data — is the compose named volume <project>_<name>). The archive is written as .tar.gz.partial and renamed on success (removed on failure). chromadb is stopped for a consistent snapshot and started again only if it was running before the backup. If the backup receives SIGINT or SIGTERM (for example Ctrl+C), it removes the .tar.gz.partial file, starts chromadb again when it was running before the backup, and exits with code 130 (SIGINT) or 143 (SIGTERM).
Self-update — ./deploy.sh self-update [tag] downloads the repository-managed files from a GitHub release tag (default: the latest release; DEPLOY_TAG or --tag also work) into a staging directory, validates them (non-empty, bash -n for the script, services: for compose files, and SHA256SUMS when the release publishes one), backs up the current files to backups/self-update_<timestamp>_<version>/, replaces each file atomically (temp file + mv), and restores the backup on any failure or interrupt. It shows the current and target version (the installed tag is recorded in .deploy-release). .env, local compose overrides that are not part of the release, and the data directory are never touched. It refuses to run inside a git checkout (use git pull) and supports DRY_RUN=1. DEPLOY_REPO (default meloncafe/chromadb-remote-mcp) and SELF_UPDATE_FILES override the source repository and the file list. update (images) and self-update (scripts/compose) are deliberately separate: swapping the compose file in the middle of update would change what the pull/recreate runs against, so update only prints a hint and self-update ends by telling you to run update.
Behind a Traefik reverse proxy — docker-compose.traefik.example.yml is an optional example override with placeholder variables. Copy it, keep the copy on the server, and select it through the compose file list in .env:
TRAEFIK_HOST and TRAEFIK_CERT_RESOLVER are required. Optional: TRAEFIK_NETWORK (external network Traefik is attached to, which must already exist; default traefik), TRAEFIK_ENTRYPOINT (default websecure), TRAEFIK_MIDDLEWARES (comma-separated; see the note below) and TRAEFIK_ROUTER_NAME (default chromadb-mcp). Traefik router and service names are global, so pick a TRAEFIK_ROUTER_NAME that no other container on that Traefik already uses. The example removes the base file's host port mapping with !reset, which requires Docker Compose 2.24 or newer.
The middlewares label in docker-compose.traefik.example.yml is commented out by default, so no middleware is attached. Once you uncomment the label, TRAEFIK_MIDDLEWARES becomes required: not only an unset variable but also an empty value (TRAEFIK_MIDDLEWARES=) aborts with required variable TRAEFIK_MIDDLEWARES is missing a value. To run without middlewares, keep the label commented out.
Option 1: Tailscale VPN (Recommended)
Secure access within your Tailscale network:
Your server is now accessible at https://your-machine.tailXXXXX.ts.net to all devices in your Tailnet.
Advantages:
- Automatic HTTPS certificates
- No public internet exposure
- Encrypted VPN tunnel
- Authentication optional (VPN provides security layer)
Option 2: Tailscale Funnel (Public Internet)
To use Claude Desktop UI Custom Connector or share publicly:
Warning: This exposes your server to the public internet. Authentication is mandatory! Set
MCP_AUTH_TOKENin your environment.
Disable Funnel:
Option 3: Cloudflare Tunnel
Option 4: Nginx Reverse Proxy
Security
Code Quality & Security Analysis
This project follows strict security practices and has resolved all security issues identified by static analysis:
- ✅ Zero Active Issues: All OWASP and CWE security findings have been resolved
- 🔒 Static Analysis: Continuous monitoring with DeepSource
- 🛡️ Security Standards: Compliant with OWASP Top 10 and Node.js security best practices
- 📊 Automated Scanning: Dependabot, CodeQL, and container vulnerability scanning
For detailed security information, see Security Policy.
Security Recommendations
-
Enable Authentication for Public Access
- Set
MCP_AUTH_TOKENwhen using Tailscale Funnel or public internet - Generate strong tokens:
openssl rand -base64 32 | tr '+/' '-_' | tr -d '=' - Rotate tokens regularly
- Set
-
Use HTTPS
- Tailscale provides automatic HTTPS certificates
- Use reverse proxy (Nginx/Caddy) with Let's Encrypt for other deployments
-
Prefer VPN Over Public Internet
- Tailscale Serve (VPN-only) is more secure than Funnel (public)
- Authentication is optional within VPN but mandatory for public access
-
Monitor Access
-
Network Isolation
- Keep ChromaDB on private network
- Only expose MCP server to public internet
Testing
Local Testing
Remote Testing (with authentication)
Troubleshooting
ChromaDB Connection Failed
MCP Server Not Responding
Claude Desktop Connection Issues
- Restart Claude Desktop
- Verify URL includes
/mcppath - Confirm transport type is
streamableHttp(notsse) - Check authentication token if enabled
- For Custom Connector: Ensure Tailscale Funnel is active
TLS Handshake Timeout on Local Network
If you're connecting from the same local network as the server and using Tailscale Funnel HTTPS:
Problem: TLS handshake fails with timeout when accessing https://your-server.ts.net from the same network.
Root cause: Tailscale Funnel has issues with TLS termination when clients on the same LAN try to connect via the public Funnel domain.
Solution: Use direct local network connection instead of Tailscale HTTPS:
Verification:
Note: External clients should continue using Tailscale Funnel HTTPS. This issue only affects clients on the same LAN as the server.
Authentication Errors (401)
Development
Building from Source
Testing
The project includes integration tests with Docker-based E2E validation:
Integration Test Coverage:
- ✅ Health check endpoint
- ✅ Authentication (
Authorization: BearerMCP_AUTH_TOKEN; OAuth 2.1 / OIDC multi-provider) - ✅ MCP protocol (tools/list, tools/call)
- ✅ ChromaDB REST API proxy
- ✅ Collection CRUD operations
- ✅ Rate limiting
- ✅ Unauthorized access handling
Unit Tests:
Unit Test Coverage:
- ✅ Authentication utilities (timing-safe comparison, buffer operations)
- ✅ Input validation (collection names, document IDs, metadata)
- ✅ Data processing (response formatting, JSON serialization)
- ✅ Error message formatting
See __tests__/README.md for detailed testing strategy.
Code Quality & Coverage
This project uses Codecov for code coverage tracking and test analytics.
Docker Development
Local Build and Test
Multi-Platform Build
Push to Docker Hub
Environment Variables for Docker Scripts:
Development Scripts
All development scripts are located in scripts/:
Quick Development Workflow:
Project Structure
v2.2.3 Release Notes — CVE-2026-45829 Security Hardening
⚠️ Breaking changes — operators upgrading from v2.2.2 or earlier must read this section.
ChromaDB image version pinned (R4)
All docker-compose*.yml files now pin chromadb/chroma to version 1.5.9@sha256:....
Versions 1.0.0–1.5.8 are vulnerable to CVE-2026-45829 (ChromaToast, CVSS 10.0) —
a pre-auth RCE via malicious embedding-function configuration. Do not downgrade the pin.
A CI workflow (.github/workflows/chromadb-version-check.yml) fails the build if any
docker-compose file references a version in the vulnerable range.
Dev fail-open removed (R1, breaking)
Previously, starting the server without MCP_AUTH_TOKEN or OIDC_ISSUERS/OIDC_PRESET
would succeed silently in non-production environments. This behaviour is removed.
The server now refuses to start unless at least one auth method is configured or
ALLOW_INSECURE_NO_AUTH=true is explicitly set.
Migration:
- Production: set
MCP_AUTH_TOKENor configure OIDC. - Local dev: add
ALLOW_INSECURE_NO_AUTH=trueto your.env.
ChromaDB REST catch-all proxy is now OFF by default (R3, breaking)
The pass-through REST proxy (previously always mounted) is now disabled unless
CHROMA_REST_PROXY_ENABLED=true is set. When disabled, all /api/* requests return 404.
When enabled, the proxy enforces:
- DNS-rebind protection (
validateOriginHeader) —Origin: evil.example→ 403 - Authentication (always required;
ALLOW_INSECURE_NO_AUTHdoes not bypass the proxy) - Path filter: collection create/modify/delete and embedding-function endpoints are blocked (403)
- Body sanitize:
configuration.embedding_functionin POST/PUT/PATCH body → 400
Migration: If you relied on direct /api/v2/* REST passthrough, set
CHROMA_REST_PROXY_ENABLED=true and ensure authentication is configured.
Contributing
Contributions are welcome! Please feel free to submit issues and pull requests.
- Fork the repository
- Create a feature branch (
git checkout -b feature/amazing-feature) - Commit your changes (
git commit -m 'Add amazing feature') - Push to the branch (
git push origin feature/amazing-feature) - Open a Pull Request
License
Resources
- MCP Specification
- MCP TypeScript SDK
- ChromaDB Documentation
- Tailscale Serve
- Tailscale Funnel
- Cloudflare Tunnel
Support
If you encounter any issues or have questions, please open an issue.
v2.0.0 Configuration
v2.0 introduces collection metadata schema v2, OAuth 2.1 OIDC, configurable embedding providers, and an optional reranker. See MIGRATION.md for the upgrade guide.
Environment variables
Recommended embedding + reranker combinations
Verified locally on Korean RAG workloads (2026-05). Pick by priority:
Notes from the verification run:
- Voyage
rerank-2did NOT reorder the short KR question↔answer pair used in this test — keep Cohere as the rerank default for KR until your own corpus shows otherwise. - The reranker layer is fail-soft: leave
RERANKER_API_BASEunset to disable reranking without code changes. - Set
CONFIDENCE_THRESHOLD(or per-callmin_score) to drop low-similarity hits; the server emitsconfidence_gate: "no_confident_match"when every result is filtered.
Docker Compose snippet (Gemini + Google OAuth)
OAuth flow
- Configure your IdP (Google / GitHub / Microsoft) to issue tokens for an audience that matches
OIDC_AUDIENCE. - Set
OIDC_PRESET=google(orOIDC_ISSUERS=...for custom IdPs) andOIDC_AUDIENCE=.... - Clients send
Authorization: Bearer <token>to/mcp. - 401 responses include
WWW-Authenticate: Bearer error="...", resource_metadata="<base>/.well-known/oauth-protected-resource"per RFC 9728. MCP_AUTH_TOKENremains valid alongside OAuth — recommended for non-interactive workloads.
Reading legacy v1 collections
Set LEGACY_COLLECTION_COMPAT=true to allow read-only access. Writes (chroma_add_documents / update / delete) on v1 collections still return Error: Cannot write to legacy v1 collection. See MIGRATION.md.
来源:README.md,提交 7d6b821
工具
0版本历史
1- v1.0.2最新Sep 16, 2026
评分
已满足适用检查项的 85%
该评分衡量此收录条目的完整程度,依据注册中心条目、端点与公开来源计算得出。它不是对服务器本身的评价,也不表示服务器安全或当前可用:可连通性是带日期的检查结果,评分也不包含安装量或用户评价。
- 近 30 天内可连通必需25 分
- 已声明认证方式必需10 分
- 已列出工具必需15 分
请让服务器在无凭据时响应 tools/list,或发布可在沙箱中无凭据启动的软件包。
- 描述必需15 分
- 图标10 分
- 文档15 分
- 许可证10 分
其他 Remote-Mcp 集成

Registry Mcp
com.remote-mcp官方发布者
远程 MCP 服务器,让助手搜索官方 MCP 注册表并查看各个 MCP 服务器的详细信息。

Starmux — All-in-One Self-Hosted Remote MCP Server & Gateway
由 GitHub 账号 cookyecat 发布
自托管守护进程,通过 Streamable HTTP 向 AI 客户端提供文件、终端、进程与 Git 工具,并可聚合其他本地 MCP 服务器。

Remote MCP Server
由 GitHub 账号 CaSO44444 发布
一个托管在裸 IP 地址上的远程 MCP 服务器,未提供工具、说明或认证信息。

Sdp Remote Mcp
com.opentext
OpenText 官方内嵌式服务器,让 AI 客户端读写软件交付平台中的待办事项、工作项与交付数据。

Revit Converter MCP
由 GitHub 账号 labsfuture 发布
远程 MCP 服务器,可将 Revit(.rvt)模型转换为 XKT、IFC 或 DWG,并让助手用自然语言查询 BIM 数据。