Uses OpenAI's embedding API to turn search queries into vectors for semantic similarity search against a local LanceDB database, enabling vector search (with the embedding model configurable via EMBEDDING_MODEL).
Click on "Deploy 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., "@Lancelot search my docs for the refund policy"
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.
Lancelot is an MCP server that answers search and retrieval queries against a local LanceDB database. It uses OpenAI embeddings for vector search when an API key is set, and plain text matching when it is not.
It reads the database folder and never writes to it. It speaks MCP over stdio only.
Tool | What it does |
| Searches a table and returns ranked hits with short snippets. |
| Retrieves chunks for a question and returns them as one block of context, cut to a character budget. |
| Reports the connection, the tables with row counts, and whether embeddings are available. |
| Reports the Lancelot version, the MCP protocol version of the SDK it is built on, and what is enabled. |
lancedb_searchParameter | Type | Required | Meaning |
| string | yes | The search text. |
| number | no | Maximum hits, 1 to 200. Default: |
|
| no |
|
| string | no | Table to search. Default: |
| string | no | Column holding the text. Default: |
| string | no | Column holding the vectors. Default: |
The reply is JSON. Its searchType field is the search that produced the hits, vector or
text. When that is not the search you asked for, a note field says why: no API key, the vector
search failed, or (in auto) it found nothing. For vector hits score is the distance, so lower is
closer. For text hits score is the share of query words found in the hit, so higher is better.
Text search is a case-insensitive substring match on the words of the query. It does not use a full-text index and does not stem words.
lancedb_queryParameter | Type | Required | Meaning |
| string | yes | The question to retrieve context for. |
| number | no | Maximum characters of context. Default: |
| boolean | no | Retrieve a general project overview instead of answering |
| string | no | Table to query. Default: |
| number | no | Maximum chunks to retrieve, 1 to 200. Default: |
The reply is a Markdown block: a header (mode, search type, query), then one section per chunk with its title, source and text. Chunks that would pass the budget are left out and the block says how many.
lancedb_statusParameter | Type | Required | Meaning |
| boolean | no | Include the column names of each table. Default: false. |
lancedb_versionNo parameters.
Lancelot reads the text from the text column (text by default). It reads title for the title,
and chunkSource or docSource for the source, when a row has them; this is the layout AnythingLLM
writes. Other columns come back as metadata. Vector search needs vectors made with the same model
as EMBEDDING_MODEL.
Related MCP server: kb-agent-platform
Claude Code, using the stdio form from the Claude Code MCP documentation:
claude mcp add --env LANCEDB_PATH=/path/to/db --env OPENAI_API_KEY=... --transport stdio lancelot -- npx -y @ayersrepair/lancelot--transport stdio sits between the last --env and the server name on purpose: the CLI reads a
name that follows --env directly as another variable. Everything after -- runs the server.
Leave out --env OPENAI_API_KEY=... for text search only.
Other MCP clients take the same command in their mcpServers configuration:
{
"mcpServers": {
"lancelot": {
"command": "npx",
"args": ["-y", "@ayersrepair/lancelot"],
"env": {
"LANCEDB_PATH": "/path/to/db",
"OPENAI_API_KEY": "sk-..."
}
}
}
}Open one of these in a browser or on the command line to add the server to the editor. Set
LANCEDB_PATH to your database folder afterwards.
VS Code: vscode:mcp/install?%7B%22name%22%3A%22lancelot%22%2C%22command%22%3A%22npx%22%2C%22args%22%3A%5B%22-y%22%2C%22%40ayersrepair%2Flancelot%400.2.0%22%5D%2C%22env%22%3A%7B%22LANCEDB_PATH%22%3A%22%2Fpath%2Fto%2Fdb%22%7D%7D
Cursor: cursor://anysphere.cursor-deeplink/mcp/install?name=lancelot&config=eyJjb21tYW5kIjoibnB4IiwiYXJncyI6WyIteSIsIkBheWVyc3JlcGFpci9sYW5jZWxvdEAwLjIuMCJdLCJlbnYiOnsiTEFOQ0VEQl9QQVRIIjoiL3BhdGgvdG8vZGIifX0=
The link formats are from the VS Code MCP guide and the Cursor install links documentation.
Listed in the official MCP Registry as io.github.ayers-software-repair/lancelot once published.
lancelot-init asks for the database folder and an OpenAI API key, and stores them for later runs.
The key goes to the operating system keychain through keytar, or to an encrypted file when keytar
is not available. Run it with npx -p @ayersrepair/lancelot lancelot-init. Environment variables
override what it stored.
Settings come from, in order: the environment, the file written by lancelot-init, the defaults.
A variable that is empty or only whitespace counts as not set. MCP clients that substitute a blank
optional value pass an empty string, and Lancelot then behaves as if the variable were absent: no
OpenAI client is created, search is text only, and nothing is logged as an error.
Variable | Default | Meaning |
| none | The LanceDB database folder. Required for the tools to work. It must exist; Lancelot does not create it. |
|
| Table used when a call names none. |
|
| Column holding the text. |
|
| Column holding the vectors. |
|
| Hits returned when a call sets no |
|
| Characters of context |
| none | Enables vector search. When unset, the credential store is checked next. |
|
| The OpenAI model used to embed queries. |
|
| Reported by |
|
| One of |
The MCP stdio transport says the server writes only valid MCP messages to stdout, and that it may write logs to stderr. Lancelot follows that:
Every log level goes to stderr. The logger has one transport, a winston Console transport with
all seven levels listed in stderrLevels.
The server entry point points console.log, console.info and console.debug at stderr, so
a library that prints does not corrupt the stream.
The server reads stdin until the client closes it, then exits.
lancelot-init is the one command that writes to stdout. It talks to a person at a terminal and
is never started as a server.
The four tools open a table and query it. No code in src creates a table, adds, updates or
deletes rows, or builds an index, and the server does not create the database folder if the path is
wrong. tests/readonly.test.ts scans the source for those calls.
Lancelot keeps its own settings and credentials in the per-user configuration directory, never in the database folder.
When OPENAI_API_KEY is set, query text is sent to OpenAI to compute embeddings. With no key
nothing leaves the machine.
npm ci
npm run check # typecheck, lint, test, buildNode 20 or later. See CONTRIBUTING.md.
Apache-2.0. See LICENSE and NOTICE.
Published by Ayers Electronics.
RAG query with context retrieval from LanceDB
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of chunks to retrieve (default: the configured limit, 20; at most 200) | |
| table | No | Table to query (default: the configured table) | |
| question | Yes | The user's question | |
| warmStart | No | Retrieve a general project overview instead of answering the question | |
| contextBudget | No | Maximum characters of context to return (default: the configured budget, 8000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and discloses almost nothing: it does not state that the operation is read-only, whether the question is embedded and searched, what the returned context looks like, or how warmStart changes behavior. Only the words 'context retrieval' hint at the return shape.
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 front-loaded sentence with no wasted words, satisfying conciseness. Its brevity, however, borders on under-specification rather than purposeful economy.
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 five-parameter RAG tool with no annotations and no output schema, the description is far too thin. It does not explain the relationship between the question and returned chunks, what warmStart produces, or how contextBudget interacts with limit, leaving the agent to reconstruct behavior from parameter names alone.
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 description coverage is 100%, so all five parameters (question, table, limit, contextBudget, warmStart) are already documented in the schema. The description adds no parameter-level meaning beyond what the schema provides, making the baseline 3 appropriate.
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 names a resource (LanceDB) and a rough action (RAG query with context retrieval), so the general purpose is inferable. However, 'RAG query' is vague about what the tool actually does—retrieve chunks, generate an answer, or both—and it gives no differentiation from the sibling lancedb_search, which an agent would reasonably confuse it with.
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?
There is no guidance on when to use this tool versus lancedb_search, lancedb_status, or lancedb_version. No prerequisites, no conditions or exclusions are stated, leaving the agent to infer the choice from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search LanceDB for relevant documents using vector or text search
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results (default: the configured limit, 20; at most 200) | |
| query | Yes | Search query string | |
| table | No | Table to search (default: the configured table) | |
| searchType | No | vector uses OpenAI embeddings, text matches words in the text column, auto uses vector when a key is set and text otherwise | auto |
| textColumn | No | Column holding the text | |
| vectorColumn | No | Column holding the vectors |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full behavioral burden, yet it says nothing about read-only safety, permissions, embedding/key requirements, or result shape. It only restates the search modes that the schema already documents in 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?
A single front-loaded sentence with no filler. It is efficient, though the 'vector or text search' clause largely duplicates the searchType parameter documentation.
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 fully documented schema covers the parameters, and no output schema exists so return values need not be explained. Still, with zero annotations and three sibling tools, the description should at minimum state that this is a read-only retrieval operation and how it differs from lancedb_query.
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 description coverage is 100%, with enum values, defaults, and the auto-mode logic all documented in the schema itself. The description adds nothing beyond that baseline, so a 3 is appropriate.
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?
States a specific verb and resource ('Search LanceDB for relevant documents') plus the two search modes, so the core operation is unambiguous. It does not distinguish itself from the sibling lancedb_query, leaving the agent to guess which retrieval tool to pick.
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 versus lancedb_query, or when vector vs text mode is preferable beyond the schema's own explanation. The agent is given a capability but no selection rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get LanceDB status and statistics
| Name | Required | Description | Default |
|---|---|---|---|
| verbose | No | Include the column names of each table |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, yet it says nothing about what "status" or "statistics" actually contain, whether the call is read-only/harmless, or whether it can fail when no database exists. For a zero-annotation tool, this leaves behavioral traits undisclosed.
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?
A single short sentence with no waste and the resource stated up front. It is efficient, though brevity here edges toward under-specification rather than precision.
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?
With no annotations and no output schema, the description is the only source of information about the return payload, and it never indicates what statistics or status fields come back. That is a meaningful gap for an informational 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?
Schema coverage is 100% and the lone parameter 'verbose' already explains that it includes column names per table. The description adds no additional meaning beyond the schema, so the baseline 3 applies.
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 gives a clear verb and resource: get status and statistics for LanceDB. It does not, however, distinguish this tool from sibling lancedb_version, which an agent could plausibly confuse with a status/info call.
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?
There is no guidance on when to call this tool versus lancedb_version, lancedb_search, or lancedb_query, and no stated prerequisites such as requiring an initialized database.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show Lancelot version information
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries the full disclosure burden, yet it says nothing about whether this is a local/side-effect-free read, what the response contains, or whether the version refers to the client, server, or data format. Only the bare purpose is stated.
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?
A single front-loaded sentence with zero waste. It is arguably under-specified rather than bloated, but nothing could be trimmed.
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?
There is no output schema and no annotations, so the description is the only source of information about the result, and it does not say what version information is returned or in what form. For a trivial zero-param tool this is a noticeable gap rather than a fatal one.
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 takes zero parameters, so there is nothing for the description to disambiguate; the 4 baseline applies. Schema coverage is 100% and trivially empty.
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?
States a specific verb ("Show") and resource ("Lancelot version information"), which an agent can distinguish from the search/query/status siblings. The only blemish is the inconsistent naming ("Lancelot" vs the lancedb_ prefix), which slightly muddies what the version actually describes.
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 when-to-use or when-not-to-use guidance, and no mention of the overlap with lancedb_status in the sibling list, which could plausibly also surface version/build info. The agent is left to infer the call context entirely.
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.
v0.2.0lancedb_querylancedb_searchlancedb_statuslancedb_versionScored across 4 tools
lancedb_search and lancedb_query have overlapping retrieval purposes; an agent could easily pick the wrong one without careful reading. The descriptions distinguish them somewhat (raw search vs RAG context retrieval), but the boundary is not crisp. Status and version are clearly distinct.
All four tools use a consistent lancedb_<verb/noun> prefix pattern. Names are readable and predictable throughout.
Four tools is on the thin side but reasonable for a focused retrieval/status server. No obvious bloat, though the surface feels minimal.
The surface only covers search/query/status/version; there is no way to create or ingest documents, list tables, update, or delete data. For a LanceDB server, these are significant lifecycle gaps that would force agents to fail on write/admin tasks.
Search your AI chat history (ChatGPT, Claude, Codex) from any MCP client. Remote, private, read-only
Query, join, profile, clean and convert CSV/JSON/Parquet with server-side DuckDB over MCP.
Serve a folder of Markdown notes as an MCP server: hybrid search, reading, and sourced answers.
