Skip to main content
Glama
@rosalinddb/mcp

@rosalinddb/mcp

by rosalinddb

@rosalinddb/mcp

Model Context Protocol server for RosalindDB.

License: Apache 2.0 npm Node 18+


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_datasets

GET /v1/datasets

List all datasets with dimension, status, row count.

create_dataset

POST /v1/datasets

Create a new empty dataset with a name and vector dimension.

get_dataset

GET /v1/datasets/{name}

Get one dataset's details and indexing status.

delete_dataset

DELETE /v1/datasets/{name}

Delete a dataset and its vectors.

ingest_vectors

POST /v1/datasets/{name}/vectors (NDJSON)

Upsert vector records (id, values, optional metadata). Read-your-writes when the recall tier is on.

query_vectors

POST /v1/query

Vector similarity search with an optional flat metadata filter. Reports the serving tier in mode.

get_vector

GET /v1/datasets/{name}/vectors/{id}

Fetch one vector's id + metadata (optionally its embedding).

list_vectors

GET /v1/datasets/{name}/vectors

List/enumerate stored vectors (memories) with an optional filter.

delete_vector

DELETE /v1/datasets/{name}/vectors/{id}

Delete one vector by id (read-your-deletes when the recall tier is on).

get_usage

GET /auth/usage

Current usage and quotas (vectors stored, queries today).

list_api_keys

GET /auth/keys

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_vectors is read-your-writes. With recall on, an upsert is synchronous (no job_id in the result) and the vector is immediately returned by the next query_vectors. With recall off, ingest is eventually consistent (returns a job_id) — poll get_dataset until status is indexed.

  • delete_vector is 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_vectors reports the serving tier in mode: recall (the recall tier), hot/cold (the consolidated object-storage tier — hot = shard already cached in memory, cold = first fetch), or ephemeral (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 what docker compose up gives you out of the box. Set ROSALINDDB_API_URL to your stack and leave ROSALINDDB_API_KEY unset. The list_api_keys, get_usage, and signup endpoints are disabled in this mode; calls to them surface a clear auth_disabled hint.

  • Multi-tenant self-host (RB_REQUIRE_AUTH=true): set ROSALINDDB_API_KEY=rb_live_.... Create a key with POST /auth/keys (or use POST /auth/signup for the first user on a fresh stack).

Configuration

The server reads two environment variables:

Variable

Required

Default

Description

ROSALINDDB_API_KEY

No

—

A RosalindDB API key (rb_live_...). Required when the backend runs with RB_REQUIRE_AUTH=true; omit for an OSS-default backend.

ROSALINDDB_API_URL

No

http://localhost:8080

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_URL to its base URL. If auth is on, also set ROSALINDDB_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 stdio

To 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.mjs

It 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 tools
create_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

    A3.7/5.0

    Scored across 11 tools

    Disambiguation5/5

    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.

    Naming Consistency5/5

    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.

    Tool Count5/5

    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.

    Completeness4/5

    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

    ActivityInactive
    ResponsivenessNo recent community issues

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      B
      quality
      D
      maintenance
      A 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.
      25
      61 npm
      1
      ISC
    • A
      license
      Not graded
      quality
      D
      maintenance
      Model 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.
      1
      MIT
    • F
      license
      Not graded
      quality
      D
      maintenance
      A Python-based Model Context Protocol server that integrates local AI models for managing data with features like CRUD operations, similarity search, and text analysis.
      -