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 "Install 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.
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.
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
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.
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).
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).
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.
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"
}
}
}
}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.
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.
Apache 2.0. See LICENSE.
To report a vulnerability, see SECURITY.md.
Create a new empty vector dataset. You choose the name and the vector dimension; vectors are added afterwards with ingest_vectors.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'empty' and that vectors are added later, but lacks disclosure of required permissions, limits, side effects, or constraints. Minimal behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no redundant information. Efficiently communicates the core action and subsequent step.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple but the description omits critical details like parameter requirements, validation rules, and return values. The mismatch between description and schema undermines completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties and allows additional properties, but the description implies two parameters (name, dimension) not defined in the schema. This contradiction reduces clarity; the description adds misleading information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new empty vector dataset' and specifies that the user chooses name and dimension, which distinguishes it from sibling tools like delete_dataset, get_dataset, and ingest_vectors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage order (create before ingest_vectors) but does not provide explicit when-to-use, when-not-to-use, or alternatives. It only indirectly suggests that vectors are added later.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a dataset and all its vectors. This is a soft-delete; the dataset becomes immediately unavailable.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the operation is a soft-delete and makes the dataset immediately unavailable, which provides some behavioral context. However, it lacks details on reversibility, authorization needs, or side effects on other resources.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and front-loaded with the core action. Every word adds value, and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fails to explain how the target dataset is identified, given the empty input schema. For a delete operation, the agent needs to know what dataset is affected. The description also omits details about restore options or confirmation steps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters in the input schema, so the baseline is 4. The description does not add parameter information, but none is needed. The schema coverage is effectively 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'delete' and the resource 'dataset and all its vectors', making the purpose unambiguous. It also distinguishes itself from sibling tools like create_dataset, get_dataset, and query_vectors by specifying a destructive action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, scenarios where soft-delete is appropriate, or when to use other tools like list_datasets or get_usage instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: synchronous tombstone vs async rebuild, read-your-deletes guarantee, clean no-op for unknown ids, and retryable 503 error on recall failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, each adding essential information: action, tier behavior, error handling. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema or annotations, the description comprehensively covers purpose, behavioral nuances, edge case (unknown id), and error condition. It is sufficient for correct tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (0 params), so no parameter documentation is needed. The description adds value by explaining the tool's behavior, meeting the baseline for 0 params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a single vector (memory) by id,' specifying the verb, resource, and scope. It differentiates from sibling tools like delete_dataset or get_vector by targeting vectors specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through tier behavior but does not explicitly state when to use this tool versus alternatives. No 'when not to use' or comparison to other tools is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single dataset's details: dimension, status (empty/validating/indexing/indexed/error), row count, and timestamps. Useful for polling indexing progress after ingest.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes full burden. It discloses that the tool returns status, row count, timestamps, and indicates polling behavior. No contradictions, but it could mention if it's read-only or requires authentication, though not critical for a get operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, followed by a use case. Every sentence adds value without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 0-param tool with no output schema, the description explains return fields and purpose. Slightly unclear how the dataset is identified (maybe from context), but overall complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters in schema, and schema coverage is 100%. The description doesn't need to add param info, but it explains the returned fields well, providing context beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'get' and resource 'single dataset's details' with explicit fields (dimension, status, row count, timestamps). It clearly differentiates from sibling tools like create_dataset, delete_dataset, list_datasets, and query_vectors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States a clear use case: 'polling indexing progress after ingest.' This implies when to use (check status) and hints at not using for other purposes like creation or listing, though explicit exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the instance's current usage and quotas: vectors stored vs quota, queries today vs daily quota, and the quota reset time.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. It confirms a read-only operation but does not disclose authentication requirements, rate limits, or potential errors. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that front-loads purpose and lists specific outputs. Every word contributes meaning. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description covers key return fields: vectors stored, queries today, quotas, reset time. Lacks mention of data format (e.g., JSON structure) or error cases, but sufficient for a simple get tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100%. The description adds value by detailing what the tool returns, which compensates for the lack of an output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Get', resource 'instance's current usage and quotas', and specifies the data included (vectors stored vs quota, queries today, reset time). No ambiguity; distinguishes from sibling tools which are CRUD on datasets or API keys.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives guidance. Since it has no parameters and is the only info-oriented tool among siblings, usage is implied but not articulated. Lacks a note like 'Use to monitor quota before ingesting.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description discloses cold-vector omission and not_found errors, adding useful behavioral context. However, parameter-schema mismatch contradicts described functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, somewhat concise, but first sentence is awkwardly phrased with a colon. Could be more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, no parameters in schema; description covers behavior but is incomplete due to missing parameter definitions, making the tool effectively undefined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has zero parameters, but description assumes id and include_values. With 100% schema coverage (trivially) and no params, description fails to provide meaning and contradicts schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it fetches a single vector by id and returns id/metadata/optional embedding, distinguishing it from siblings. However, the input schema lacks parameters for id and include_values, creating a critical mismatch that undermines clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use for fetching a single vector and explains behavior for cold vectors, but no explicit when-not or alternatives to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It fully discloses synchronous vs asynchronous indexing, response structure (accepted/rejected counts, per-record errors), and polling mechanism via get_dataset.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise with front-loaded main action, though slightly lengthy with detailed async behavior; each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensively covers all necessary aspects for an ingestion tool with async behavior, including response details and integration with get_dataset for polling, despite lacking an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has no defined properties (empty object with additionalProperties), but description adds essential parameter details like id, values array, and optional metadata, compensating for the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool ingests (upserts) vector records into a dataset with last-write-wins per id, distinguishing it from siblings like create_dataset or delete_vector.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use the async import flow for large payloads over 10 MiB and explains read-your-writes behavior based on recall tier, offering clear context without naming specific alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that raw keys are never returned and lists the metadata fields. However, it does not mention authentication requirements, rate limits, or explicitly state that it is a safe read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences, with the first sentence front-loading the main purpose. Every word adds value, and there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description adequately covers the tool's behavior by listing output fields. It is complete for a simple list operation, though it could mention whether pagination or sorting is supported.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, with 100% schema coverage. The description adds value by enumerating the metadata fields returned (name, creation time, last use, revoked), which goes beyond the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists instance API keys, emphasizing metadata only and that raw key values are never returned. It specifies the exact fields shown (name, creation time, last use, revoked). This distinguishes it from sibling tools, which are all dataset-oriented.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. While the sibling tools are all dataset-related and this is the only API key tool, there is no guidance on prerequisites or use cases other than the implicit purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all vector datasets in the RosalindDB instance, with each dataset's dimension, status, and row count.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It states the returned fields but omits details like pagination, rate limits, or whether the operation is read-only. This is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no wasted words. It is front-loaded and efficiently conveys the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, no output schema), the description is nearly complete. It could mention authentication requirements or pagination limits, but overall it suffices.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the description does not need to add parameter info. The baseline for 0 parameters is 4, and the description meets this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all vector datasets and specifies the returned fields (dimension, status, row count). It effectively distinguishes from siblings like get_dataset (single) and create_dataset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies listing all datasets but does not explicitly state when to use this tool versus alternatives (e.g., get_dataset for a specific dataset, query_vectors for searching). No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the return format ({ vectors, next_cursor }) and mentions optional filtering and pagination. Without annotations, it provides basic transparency but lacks details on error conditions, rate limits, or prerequisites (e.g., dataset context).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that packs the core functionality, optional features, and return format. It is concise and front-loaded, though the mismatch with the schema reduces its effectiveness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the empty schema and no annotations, the description covers the basic operation and return type. However, it omits details like required dataset identification, error handling, and the impact of additionalProperties being true in the schema, leaving gaps for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions a metadata filter, page limit, and cursor, but the input schema has zero parameters. This adds misleading meaning beyond the schema, and with 100% schema coverage (of no params), the baseline expectation is not met. The description does not clarify how to pass these filters without defined parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists vector records with id and metadata, and mentions optional filtering and pagination. This distinguishes it from siblings like get_vector (single retrieval) and query_vectors (similarity search). However, the described parameters are not present in the empty input schema, causing some confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes it is useful for enumerating or auditing stored memories, providing a use case. It does not explicitly exclude other scenarios or compare with sibling tools, leaving the agent to infer when to use which.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the result modes (recall, hot, cold, ephemeral) and their implications, as well as the distance metric and filter semantics. However, it omits details on pagination, rate limits, error handling, and performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, starting with the main purpose, then explaining distance, result modes, and filter. It is somewhat lengthy but each section adds value. Could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a vector search tool with no output schema, the description covers return values and result interpretations. However, it lacks details on how to specify the query vector and dataset, which are critical for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no properties, and the description adds information about an optional flat metadata filter with exact-match AND semantics. While this provides context, it does not specify the parameter name or format, and the schema coverage is 100% by default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs a vector similarity search against a dataset and returns nearest neighbours sorted by L2 distance. This distinguishes it from sibling tools like list_vectors or get_vector, but does not explicitly specify how the dataset is identified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use it, or contrast with other search or list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.2.0delete_vectorget_vectorlist_vectorsv0.1.0create_datasetdelete_datasetget_datasetget_usageingest_vectorslist_api_keyslist_datasetsquery_vectorsEach 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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
Hosted MCP server for AI-driven data ops. Create apps, manage schemas, and CRUD structured data.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/rosalinddb/rosalinddb-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
