RushDB MCP Server

Official

Overview Schema Source Related Servers Discussions Admin

createEmbeddingIndex

Define an embedding index policy for a record label and string property to enable semantic vector search; supports managed or external vector sources.

Instructions

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.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	No	Index name, unique within the project (1–64 of letters, digits, ".", "_", ":", "-"). Defaults to <label>.<property>.<model>.<dimensions>.<similarity>.
`label`	Yes	Record label to scope the index to (e.g. "Book", "Task").
`dimensions`	No	Vector dimensionality. Required for external indexes. For managed indexes, defaults to the server-configured embedding model dimensions.
`sourceType`	No	Whether RushDB generates embeddings ("managed") or the client provides them ("external"). Defaults to "managed".
`propertyName`	Yes	Name of the string property whose values will be embedded.
`similarityFunction`	No	Similarity function for the vector index. Defaults to "cosine".

Output Schema

TableJSON Schema

Name	Required	Description	Default
`index`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv3.0.1Oct 21, 2026

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With annotations only declaring readOnly=false, destructive=false, openWorld=false, the description supplies the behavior that actually matters: managed indexes asynchronously embed every existing value and keep new values embedded on write, the index has a status lifecycle ending in "ready", and external indexes require the client to push vectors. This is exactly the beyond-annotation context an agent needs for a long-running, stateful operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, front-loaded with the purpose, then mode semantics, then the post-creation workflow. No filler and no repetition of schema text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a multi-mode, asynchronous creation tool with an output schema available, the description covers the creation semantics, the two operating modes, the readiness signal, and the downstream query tool. Nothing an agent needs to invoke and then correctly follow up is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3, but the description adds real meaning: it explains the sourceType dichotomy (managed vs external), that dimensions matter primarily for external indexes, and that vectors for external indexes arrive via upsertEmbeddingVectors. That workflow context goes beyond the field-level descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence states a specific verb and resource ('Create a new embedding index policy for a string property'), and the rest of the description anchors it against the sibling tools it pairs with (getEmbeddingIndexStats, vectorSearch, upsertEmbeddingVectors). An agent can distinguish this from createTextIndex/textSearch by the explicit vector-embedding framing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clearly explains when each mode applies ('For managed indexes (default)... For external indexes (sourceType: "external"), the client supplies vectors via upsertEmbeddingVectors') and gives the follow-on workflow (wait for status "ready", then use vectorSearch). It never states when not to use this tool or prerequisites like model configuration, so it stops short of full when/when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.