@rosalinddb/mcp
The @rosalinddb/mcp server lets AI clients (e.g., Claude Desktop, Cursor) interact with a RosalindDB vector database instance to manage datasets, store and search vectors, and monitor usage — without writing REST calls directly.
Dataset Management
List datasets: View all vector datasets with their dimension, status, and row count.
Create a dataset: Create a new empty vector dataset by specifying a name and vector dimension.
Get dataset details: Retrieve a single dataset's metadata including status (
empty/validating/indexing/indexed/error), row count, and timestamps — useful for polling indexing progress.Delete a dataset: Permanently remove a dataset and all its vectors.
Vector Operations
Ingest vectors: Upsert vector records (ID, embedding values, optional metadata) into a dataset.
Query vectors: Run a nearest-neighbor similarity search (L2 distance) with an optional metadata filter.
Get / list / delete individual vectors: Fetch, enumerate, or remove specific vectors by ID.
Administration & Monitoring
Get usage: Check vectors stored vs. quota, queries today vs. daily limit, and quota reset time.
List API keys: View API key metadata (name, creation time, last use, revocation status) — raw key values are never exposed.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@@rosalinddb/mcp find the top 5 vectors closest to [0.2,0.8,0.3] in the 'embeddings' dataset"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
@rosalinddb/mcp
Model Context Protocol server for RosalindDB.
A Model Context Protocol (MCP) server for RosalindDB — a cost-optimized, object-storage-first vector search database.
This server lets MCP-capable AI clients (Claude Desktop, Cursor, Claude Code,
and others) operate a RosalindDB instance directly: create datasets, ingest
vectors, run similarity queries, and check usage — without hand-writing REST
calls. It is a thin wrapper over RosalindDB's v1 REST API: it authenticates
with an rb_live_ API key when the backend has auth enabled, otherwise it
runs unauthenticated against an OSS-default backend. It contains no business
logic of its own.
The RosalindDB engine lives at
rosalinddb/rosalinddb.
Self-host it via docker compose and point this MCP at it.
Tools
Tool | RosalindDB endpoint | What it does |
|
| List all datasets with dimension, status, row count. |
|
| Create a new empty dataset with a name and vector dimension. |
|
| Get one dataset's details and indexing status. |
|
| Delete a dataset and its vectors. |
|
| Upsert vector records (id, values, optional metadata). Read-your-writes when the recall tier is on. |
|
| Vector similarity search with an optional flat metadata filter. Reports the serving tier in |
|
| Fetch one vector's id + metadata (optionally its embedding). |
|
| List/enumerate stored vectors (memories) with an optional filter. |
|
| Delete one vector by id (read-your-deletes when the recall tier is on). |
|
| Current usage and quotas (vectors stored, queries today). |
|
| List the instance's API keys (metadata only). |
For very large embedding dumps (over the 10 MiB ingest_vectors cap), use
RosalindDB's async import-job flow directly via the REST API.
Related MCP server: Tensorus MCP
Recall tier (read-your-writes)
RosalindDB can run an optional recall tier — a hot pgvector instance the
server enables with RB_RECALL + RB_RECALL_DSN. It's transparent to this MCP
(nothing to configure client-side), but it changes the behavior an agent sees:
ingest_vectorsis read-your-writes. With recall on, an upsert is synchronous (nojob_idin the result) and the vector is immediately returned by the nextquery_vectors. With recall off, ingest is eventually consistent (returns ajob_id) — pollget_datasetuntilstatusisindexed.delete_vectoris read-your-deletes. With recall on, a delete is a synchronous tombstone ({ synchronous: true }) and the vector is gone from queries at once; with recall off it queues a rebuild ({ async: true, job_id }).query_vectorsreports the serving tier inmode:recall(the recall tier),hot/cold(the consolidated object-storage tier —hot= shard already cached in memory,cold= first fetch), orephemeral(no shard yet, computed on demand). Recall and consolidated results are unioned, with recall authoritative for anything written since the last consolidation.
This makes RosalindDB usable as agent working memory: store a fact and recall it on the very next turn. See the engine's recall / consolidate docs.
Auth modes
The RosalindDB backend ships in two modes; the MCP server supports both:
OSS default (
RB_REQUIRE_AUTH=false): no auth, no API key needed. This is whatdocker compose upgives you out of the box. SetROSALINDDB_API_URLto your stack and leaveROSALINDDB_API_KEYunset. Thelist_api_keys,get_usage, and signup endpoints are disabled in this mode; calls to them surface a clearauth_disabledhint.Multi-tenant self-host (
RB_REQUIRE_AUTH=true): setROSALINDDB_API_KEY=rb_live_.... Create a key withPOST /auth/keys(or usePOST /auth/signupfor the first user on a fresh stack).
Configuration
The server reads two environment variables:
Variable | Required | Default | Description |
| No | — | A RosalindDB API key ( |
| No |
| Base URL of the RosalindDB API. |
When set, the key is sent as Authorization: Bearer rb_live_... on every
request. A key that doesn't start with rb_live_ triggers a startup warning
but is not rejected (in case you front the backend with a custom auth proxy).
Wiring it into an MCP client
Add this to your MCP client config (for Claude Desktop,
claude_desktop_config.json):
{
"mcpServers": {
"rosalinddb": {
"command": "npx",
"args": ["-y", "@rosalinddb/mcp"],
"env": {
"ROSALINDDB_API_URL": "http://localhost:8080"
}
}
}
}npx -y @rosalinddb/mcp downloads and runs the server on demand — no global
install needed. The server speaks the stdio transport, the standard for a
locally-launched MCP server.
Pointing at a non-local instance? Set
ROSALINDDB_API_URLto its base URL. If auth is on, also setROSALINDDB_API_KEY=rb_live_.... The backend lives at rosalinddb/rosalinddb.
Local development
npm install # install dependencies
npm run build # compile TypeScript to dist/
npm test # run the vitest unit + in-process MCP suite
npm run smoke # build, then drive a real tools/list over stdioTo run the server directly from a local checkout:
{
"mcpServers": {
"rosalinddb": {
"command": "node",
"args": ["/absolute/path/to/mcp-server/dist/index.js"],
"env": {
"ROSALINDDB_API_URL": "http://localhost:8080"
}
}
}
}Live smoke test
With a running RosalindDB stack and a real key, tests/live-smoke.mjs
exercises create → ingest → usage → query → delete end to end:
npm run build
ROSALINDDB_API_KEY=rb_live_... node tests/live-smoke.mjsIt is skipped automatically when no key is set.
Error handling
RosalindDB API errors are mapped to clear, actionable MCP tool errors — never
a raw stack trace. A 404 surfaces as "dataset does not exist — list datasets
or create it first"; a 429 quota error explains the limit and how to recover;
a 404 auth_disabled (calling list_api_keys against an OSS-default
backend) explains that the auth endpoints are gated behind
RB_REQUIRE_AUTH=true; and a 503 recall_write_failed / recall_delete_failed
/ recall_unavailable explains that the read-your-writes tier is momentarily
down and the call should be retried.
License
Apache 2.0. See LICENSE.
Security
To report a vulnerability, see SECURITY.md.
Available Tools
11 toolscreate_datasetB
Create a new empty vector dataset. You choose the name and the vector dimension; vectors are added afterwards with ingest_vectors.
Inputs: no named parameters.
delete_datasetA
Delete a dataset and all its vectors. This is a soft-delete; the dataset becomes immediately unavailable.
Inputs: no named parameters.
delete_vectorA
Delete a single vector (memory) by id. With the recall tier on this is a synchronous tombstone — the vector is immediately gone from queries (read-your-deletes); otherwise it queues an async rebuild and returns a job_id. Deleting an unknown id is a clean no-op; a recall-tier failure surfaces as a retryable 503 (recall_delete_failed).
Inputs: no named parameters.
get_datasetA
Get a single dataset's details: dimension, status (empty/validating/indexing/indexed/error), row count, and timestamps. Useful for polling indexing progress after ingest.
Inputs: no named parameters.
get_usageA
Get the instance's current usage and quotas: vectors stored vs quota, queries today vs daily quota, and the quota reset time.
Inputs: no named parameters.
get_vectorC
Fetch a single vector record by id: its id and metadata. Set include_values=true to also return the stored embedding for a recall-resident vector (a consolidated/cold-only vector omits it even when requested — its absence is expected, not an error). Errors with not_found if the id is absent or deleted.
Inputs: no named parameters.
ingest_vectorsA
Ingest (upsert) vector records into a dataset (last-write-wins per id). Each record needs an id, a values array matching the dataset dimension, and optional flat metadata. The response reports accepted/rejected counts and per-record errors. Read-your-writes depends on the server's recall tier: if the result has NO job_id the write was synchronous and is immediately queryable; if it returns a job_id, indexing is asynchronous (eventually consistent) — poll get_dataset until status is 'indexed'. For dumps over ~10 MiB use the async import flow.
Inputs: no named parameters.
list_api_keysA
List the instance's API keys (metadata only; raw key values are never returned). Shows each key's name, creation time, last use, and whether it has been revoked.
Inputs: no named parameters.
list_datasetsA
List all vector datasets in the RosalindDB instance, with each dataset's dimension, status, and row count.
Inputs: no named parameters.
list_vectorsB
List vector records (id + metadata) in a dataset, optionally filtered by a flat exact-match metadata filter, with a page limit and cursor. Returns { vectors, next_cursor }. Useful for enumerating or auditing the memories an agent has stored.
Inputs: no named parameters.
query_vectorsB
Run a vector similarity search against a dataset. Returns nearest neighbours sorted by L2 distance (lower score = closer; 0.0 is exact). The result 'mode' names the tier that answered: 'recall' = the read-your-writes recall tier; 'hot'/'cold' = the consolidated object-storage tier ('hot' = shard already cached in memory, 'cold' = first fetch from object storage); 'ephemeral' = no shard yet (computed on demand). With the recall tier on, a just-ingested vector is immediately searchable (read-your-writes). Supports an optional flat metadata filter (exact-match AND semantics; run exhaustively server-side).
Inputs: no named parameters.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 11 tools
Each tool targets a distinct resource and action: dataset management (create, delete, get, list), vector operations (ingest, get, delete, list, query), usage monitoring, and API key listing. There is no overlap or ambiguity between tools.
All tool names follow a consistent verb_noun pattern with snake_case (e.g., create_dataset, ingest_vectors, list_api_keys). No deviations or mixed conventions are present.
11 tools is well-scoped for a vector database MCP server, covering dataset lifecycle, vector CRUD and search, usage monitoring, and API key management. Each tool serves a clear purpose.
The tool set covers core operations: dataset CRUD (except update), vector ingest/read/delete/query, and API key listing. Minor gaps exist, such as missing dataset update or API key revocation, but agents can work around them.
Maintenance
Related MCP Connectors
An MCP server for search and retrieval over a local LanceDB database
Remote ChromaDB vector database MCP server with streamable HTTP transport
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
A Model Context Protocol server for Wix AI tools
Related MCP Servers
- AlicenseBqualityDmaintenanceA Model Context Protocol server that enables AI models to interact with SourceSync.ai's knowledge management platform for managing documents, ingesting content from various sources, and performing semantic searches.2561 npm1ISC
- AlicenseNot gradedqualityDmaintenanceModel Context Protocol server and client that enables AI agents and LLMs to interact with Tensorus tensor database for operations like creating datasets, ingesting tensors, and applying tensor operations.1MIT
- FlicenseNot gradedqualityDmaintenanceA Python-based Model Context Protocol server that integrates local AI models for managing data with features like CRUD operations, similarity search, and text analysis.-
- AlicenseNot gradedqualityDmaintenanceModel Context Protocol server that standardizes tool discovery, execution, and context management for AI applications.MIT