Rushdb Memory Layer For Ai Agents And Apps
@rush-db
About Rushdb Memory Layer For Ai Agents And Apps
No overview available yet
Config
Add this server to your MCP-compatible client using the configuration below.
{
"mcpServers": {
"rushdb": {
"command": "npx",
"args": [
"-y",
"@rushdb/mcp-server"
],
"env": {
"RUSHDB_API_KEY": "<your-api-key>"
}
}
}
}Tools
39STEP 0 — call this ONCE at the start of every conversation before constructing any query. Returns the complete graph schema as compact Markdown: all labels with record counts, all properties per label with their type and value ranges (min/max for numbers/datetimes, sample values for strings/booleans; array properties render as type[]), and all cross-label relationships with direction and edge property summaries. The Properties table includes a "Semantic Search" column: properties with an embedding index show `sourceType similarityFunction dimensionsd [status]` (e.g. `managed cosine 1536d [ready]`); others show `—`. A non-`—` value means the property is queryable with aiSemanticSearch. This single call replaces the need for separate findLabels + findProperties + findRelationships discovery calls. Use the result to determine exact label names (case-sensitive), field names, field types, and relationship patterns before building any findRecords query. Optionally pass `labels` array to narrow the output to specific labels. Pass `force: true` to bypass the 1-hour schema cache and force a fresh recalculation.
Returns the same graph schema as getSchemaMarkdown but as structured JSON. Each item has: label (string), count (number), properties (array with id, name, type, optional isArray, recordsCount (number of records that carry this property), min/max for numbers/datetimes, values[] for strings/booleans, and an optional vectorIndexes array), and relationships (array with label, type, direction: in|out, count, and optional edge properties). vectorIndexes is non-empty when one or more embedding indexes exist for that property; each entry has: id, sourceType (managed|external), similarityFunction (cosine|euclidean), dimensions (number), status (pending|indexing|ready|error), modelKey. A non-empty vectorIndexes means the property is queryable with aiSemanticSearch. Use this when you need property `id` values to pass to propertyValues for deeper drill-down. For initial schema orientation, getSchemaMarkdown uses fewer tokens. Pass `force: true` to bypass the 1-hour schema cache and force a fresh recalculation.
List or filter available record types (labels) and their counts. IMPORTANT: getSchemaMarkdown already returns ALL label names in STEP 0 — do NOT call findLabels as a substitute for it. Only call findLabels when you need label counts after applying record-scoped predicates, or getSchemaMarkdown was not called yet. Call with no arguments to list all labels. `where` is applied to Records, not label metadata; use getSchemaMarkdown to search label names. Returns objects with name (case-sensitive — use exact casing in all subsequent calls) and count (number of matching records). Pick the best matching label by: exact match > starts-with > substring > semantic similarity, preferring higher count on ties. State your label assumption briefly ("using DEAL for 'deals'") and proceed without asking.
Create a new record. Use the exact label casing returned by findLabels. Set mergeStrategy + mergeBy in options to enable upsert semantics (merge existing vs. replace).
Partially update a record — only fields present in data are changed; all other existing fields are preserved. Use setRecord instead if you want to replace all fields. Requires recordId: retrieve it first with findRecords or getRecord if not already known.
Delete a single record by ID. Irreversible. Always confirm with the user before calling. Use findRecords to preview the record first.
Primary read/query/list/search tool for records. Use findRecords to find records, search records, list records, retrieve matching records, filter records, or answer questions from data. Use this instead of exportRecords unless the user explicitly asks for CSV/export/download. Search records with a structured SearchQuery. BEFORE building any query with dates, metrics, groupBy, relationship traversal, or vector search — call getSearchQuerySpec to load the complete syntax reference. INTENT: metrics/analytics request (count/total/sum/avg/breakdown/top N by metric) → MUST include select + groupBy. NEVER fetch raw records to count/sum manually. RESPONSE: { data:[...records], total:N } — for simple "how many" read total directly; no count select needed. HARD RULES: (1) NEVER set limit when select is present — restricts the record scan and produces mathematically wrong results. Omit limit for all metrics queries. (2) labels contains root records only; put related labels inside where traversal blocks with $alias when referenced. (3) groupBy never accepts alias-only values like "$record"; use "$record.name" or a select key. (4) Ambiguous/incomplete named references should use $contains on a display property confirmed via schema discovery, not exact equality. (5) Related-count rankings keep the requested parent/entity as root; count the related alias and order desc for most/more or asc for least/less/fewer.
Fetch a single record by its ID. Use when you already have the ID from a previous findRecords or findOneRecord call.
Fetch multiple records by their IDs in one call. Use after collecting IDs from a findRecords query.
Create a directed or bidirectional relationship between records. sourceId and targetId/targetIds must already exist — use findRecords to resolve records by name/attribute first.
Remove a relationship between records. Use findRelationships to inspect existing relationships and confirm the correct type/direction before detaching.
Discover and traverse relationships between records. Use this tool in two scenarios: (1) Multi-hop path discovery — fetch a sample record ID, then call findRelationships with source.where or target.where containing that ID to reveal adjacent labels; repeat to trace the full path before building a nested findRecords where clause. (2) Edge filtering — where applies to relationship type/properties; use source/target for endpoint record predicates. Does NOT support select or groupBy — use findRecords for metrics/analytics across related labels.
List inferred relationship patterns for the current project. Returns suggestions and their lifecycle status, current schema relationship summaries, and the latest analysis status. Use this before approving, ignoring, or deleting a relationship pattern.
Queue schema analysis to generate relationship pattern suggestions for the current project. This may invoke the configured LLM. Poll listRelationshipPatterns to inspect completion status and suggestions.
Approve and apply a suggested relationship pattern. Call listRelationshipPatterns first so the user can review the inferred source, target, direction, type, mode, and confidence.
Ignore a suggested relationship pattern without applying it. Call listRelationshipPatterns first so the user can review the inferred pattern.
Delete a saved relationship pattern. Irreversible. Confirm with the user before calling. When deleteExisting is true, relationships previously materialized by this pattern are also removed.
Insert multiple records of the same label in one call. Set mergeStrategy ("append" to keep existing unspecified fields, "rewrite" to replace) and mergeBy (fields to match on) in options to enable upsert semantics. Use the exact label casing returned by findLabels.
Delete all records matching a query. IRREVERSIBLE and potentially high-impact. REQUIRED: always call findRecords with the same labels+where first to show the user a preview, then ask for explicit confirmation before calling this tool.
Export matching records as a CSV file only when the user explicitly asks to export/download CSV. For normal reading, answering, listing, searching, or inspecting records, use findRecords instead. Accepts the same labels/where/orderBy filters as findRecords. Call findProperties first to know available field names if constructing a where filter.
Help the user add the RushDB MCP server to their MCP client
Return the RushDB system prompt. Use this if your MCP client does not support the Prompts API.
Returns the complete RushDB SearchQuery specification as a focused reference document. Covers: all WHERE operators (string/number/boolean/datetime component objects/vector/$exists/$type), relationship traversal syntax ($alias/$relation with variable-length hops/$cycle ring detection/$id), logical grouping ($and/$or/$not/$nor/$xor), all select functions ($sum/$avg/$min/$max/$count/$collect/$timeBucket), both groupBy modes (dimensional + self-group), late-ordering rules, root-label vs related-label traversal rules, COLLECT nesting, limit rules by query mode, multi-hop path discovery, enum normalization, validation checklist, and annotated query examples. CALL THIS before building any findRecords query that involves dates, metrics, groupBy, relationship traversal, or vector search. Do not guess operator syntax — use this spec as the source of truth.
Replace ALL fields of a record with the provided data object — any existing fields not in data are deleted. Use updateRecord instead for partial/merge updates that preserve unspecified fields.
Return the first record matching the query — useful for entity resolution probes. Call with where: { <nameField>: { $contains: "..." } } and a small limit to resolve a named entity to its ID before using it in a relationship filter. Prefer this over findRecords when you need exactly one representative match rather than a full list.
Return the single record that uniquely matches the query — throws if zero or more than one record matches. Use for unique-key lookups (email, code, slug) where exactly one result is expected. Use findOneRecord instead when you only want the first match and duplicates are acceptable.
Delete a single record by ID. Irreversible. Always confirm with the user before calling. Use getRecord to preview the record if needed.
Get statistics or distinct values for a specific property, identified by the `id` field returned from findProperties. What this tool returns depends on the property type: • number / datetime → returns { min, max } — use this to answer range, min/max, or spread questions for numeric or date fields. No findRecords aggregation needed. • string / boolean → returns a list of all distinct values — use this to canonicalize filter values before querying. Workflow for range/min/max questions: (1) findLabels, (2) findProperties to find the field and get its id and type, (3) call this tool with that id if type is number or datetime.
Discover the field names, types, and IDs available on a record label. Always call this before using field names in any query — never guess or invent field names. Filter by label using labels: ["LABEL_NAME"]. `where` is applied to Records, not property metadata. Each returned property object has: id (string), name (string), type (string | number | boolean | datetime), recordsCount (number of records that carry this property). Use the `name` field as the field name in where/orderBy/groupBy clauses. Use the `id` field as the `propertyId` argument to propertyValues. After calling this tool, decide the next step based on the field type: number or datetime → call propertyValues(propertyId) to get { min, max } for range questions, OR use findRecords with select: { min: ..., max: ... }; string or boolean → call propertyValues(propertyId) to get distinct values before filtering.
Fetch the metadata (name, type, label, recordsCount) of a single property by its ID. Use when you already have a propertyId and need to re-confirm its type or cardinality before calling propertyValues.
Permanently delete a property and all its values from every record that has it. Irreversible. Confirm with the user before calling.
List all embedding index policies configured for the current project. Each index entry contains: id, label, propertyName, modelKey, dimensions, enabled, status (pending|indexing|ready|error), createdAt, updatedAt. Call this before creating a new index to check if one already exists for the same label+propertyName.
Create a new embedding index policy for a string property. For managed indexes (default), RushDB asynchronously embeds every existing value and keeps new values embedded on write. For external indexes (sourceType: "external"), the client supplies vectors via upsertEmbeddingVectors. Once the index status becomes "ready" (check with getEmbeddingIndexStats), use vectorSearch to query.
Write pre-computed embedding vectors to an external vector index for a set of records. Only valid for indexes with sourceType "external". Each vector must contain exactly as many dimensions as the index was created with. After upserting, call getEmbeddingIndexStats to check if all records are indexed (status becomes "ready").
Delete an embedding index policy by its ID and strip all stored embedding vectors for that index. Irreversible. Confirm with the user before calling. Use findEmbeddingIndexes to get the indexId.
Return Neo4j-level statistics for an embedding index: totalRecords and indexedRecords. Use this to monitor backfill progress after creating an index — when indexedRecords === totalRecords the index is fully ready.
Perform direct vector similarity search over records whose `propertyName` has been indexed with createEmbeddingIndex. For managed indexes: provide a free-text `query` — RushDB embeds it and returns the most similar records ranked by similarity (__score). For external indexes: provide a `queryVector` (pre-computed number[]) instead of query text. Direct vector-index mode (fast, default): used when no `where` filter is supplied. Prefilter mode (exact, slower): activated when a `where` filter is supplied — candidates are first narrowed then ranked. Requires an embedding index in "ready" status for the given label+propertyName.
Deprecated alias for vectorSearch. Performs direct vector similarity search over records whose `propertyName` has been indexed with createEmbeddingIndex. Prefer vectorSearch for new integrations. For natural-language schema-aware querying, use smartSearch.
Convert a natural-language question into a RushDB SearchQuery using the project schema, execute it, and return matching records plus the generated query. Use this for user-facing questions such as "Who are piloting Falcon?" or "Find planets 3-5 hops away from Tatooine". For direct vector similarity over an embedding index, use vectorSearch instead.
Basic information
More Databases MCP servers
Redis MCP Server
redisThe official Redis MCP Server is a natural language interface designed for agentic applications to manage and search data in Redis efficiently

PostgreSQL
modelcontextprotocolModel Context Protocol Servers
Postgres Mcp
crystaldbaPostgres MCP Pro provides configurable read/write access and performance analysis for you and your AI agents.
Elasticsearch MCP Server
elasticMySQL MCP Server
designcomputerA Model Context Protocol (MCP) server that enables secure interaction with MySQL databases
Comments