ChromaDB Remote MCP Server

Remote ChromaDB vector database MCP server with streamable HTTP transport. The chromadb remote mcp server wraps that behind the Model Context Protocol, so an assistant can use it through 7 defined tools rather than through you.

What it actually does

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.

All clients access the same self-hosted ChromaDB through this remote MCP server. Vector embeddings and semantic search results persist across all platforms.

• 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

Its toolset

Everything the assistant can do here goes through one of these:

• chroma_search — Hybrid dense + sparse search (RRF). The algorithm itself works on a single node; chromadb open-source simply hasn't implemented the search() endpoint
• 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)
• Path — Purpose
• Overview — All clients access the same self-hosted ChromaDB through this remote MCP server. Vector embeddings and semantic search results persist across all
• Authentication — The Authentication tool exposed by this server

Configuration

You will need 5 environment variables: MCP_AUTH_TOKEN, CHROMA_DATA_PATH, CHROMA_HOST, CHROMA_AUTH_TOKEN, YOUR_TOKEN. The server will not start without them, which is usually why the tools fail to appear on a first run. Keep credentials in your client's env block or a secrets manager rather than in a file you might commit.

Adding it to your client

Being a remote server, there is no local install. You register the endpoint with your client, authorise it once, and the tools appear.

When to reach for it

Plenty of cloud and infrastructure servers cover similar ground. The differences that matter in practice are scope of access and how much setup stands between you and a working tool call. ChromaDB Remote's toolset — chroma_search, chroma_fork_collection, chroma_get_fork_count and 4 more — is a fair guide to whether it matches your workflow. It is maintained by meloncafe; worth a glance at recent repository activity before you build anything load-bearing on it.

SyncDev reviews every entry in this directory against the project's own documentation before publishing, and revisits them as servers change.

Caveats

• Your data travels to the provider's service, so the usual questions apply about what you send and what they retain.
• Missing credentials fail quietly in some clients — if no tools show up, check the environment block first.
• MCP clients confirm each tool call by default. Leave that on until you have watched what the chromadb remote mcp server does with a few real requests.