Loading ToolBench
Model Context Protocol server for RosalindDB - a cost-optimized, object-storage-first vector search database.
RosalindDB MCP demonstrates solid tool design with complete input schemas, clear descriptions, and proper parameter typing via Zod. All 11 tools have descriptions (avg ~180 chars, within baseline 194), and all parameters are typed and described. Naming follows verb_noun convention (list_, create_, get_, delete_, ingest_, query_). However, output schemas are not documented in the source, responses are inferred from API behavior rather than explicitly declared. Error handling is present but minimal; no recovery guidance or actionable error messages visible. Tool composition is clean (single responsibility), but some tools lack context about prerequisites or when to call them relative to others.
Create a new empty vector dataset. You choose the name and the vector dimension; vectors are added afterwards with ingest_vectors.
Delete a dataset and all its vectors. This is a soft-delete; the dataset becomes immediately unavailable.
Delete a single vector record by id. Depending on the server's recall tier: if recall is on, the delete is synchronous (204 No Content, read-your-deletes); if recall is off, the delete is asynchronous (202 Accepted with a job_id, eventually consistent). Errors with not_found if the id is absent or already deleted.
Get a single dataset's details: dimension, status (empty/validating/indexing/indexed/error), row count, and timestamps. Useful for polling indexing progress after ingest.
Fetch account usage: stored vectors, queries run this month, and quota limits. Useful for monitoring consumption and planning upgrades.
Output schemas not documented. Tool descriptions explain what is returned (e.g., 'returns nearest neighbours sorted by L2 distance'), but formal response schemas are absent. LLMs cannot reliably extract fields or plan downstream tool chains without knowing the exact structure.
Error handling lacks recovery guidance. No visible error classification (retryable vs. user-fixable vs. fatal) or actionable error messages. E.g., if ingest_vectors rejects records, the response should list which records failed and why, not just a count.
Destructive operations (delete_dataset, delete_vector) lack confirmation or dry-run support. Agents can irreversibly delete data without a safety gate. No mention of undo/compensation tools.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | 2026-07-28+ | v2 |
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.
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.
List all API keys for the account: their names, creation dates, and last-used timestamps. Useful for auditing and key rotation.
List all vector datasets in the RosalindDB instance, with each dataset's dimension, status, and row count.
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.
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).
Tool descriptions lack dependency hints. E.g., ingest_vectors mentions 'poll get_dataset until status is indexed' but does not explicitly state 'call get_dataset after ingest to check progress.' Agents may not know the intended workflow.
list_api_keys and get_usage descriptions are generic (75 chars). They lack context about when to call them or what the agent should do with the results. E.g., 'Useful for monitoring consumption' is vague, does the agent compare against a quota, alert on threshold, or just log?