Lancelot is a read-only MCP server for searching and retrieving document passages from a local LanceDB database.
Search tables with text, vector, or automatic search and get ranked hits with snippets, configurable by limit, table, and text/vector column.
Retrieve relevant chunks for a question as a single context block, with character budget, optional warm-start overview, table, and limit controls.
Check database status, including connection, tables, row counts, embedding availability, and optional column names.
Report Lancelot version, MCP protocol version, and enabled features.
Use it via stdio, Streamable HTTP, or AWS Lambda; tools are read-only, while indexing is a separate command.
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.
Search your documents from any MCP-compatible assistant. Lancelot connects an agent to a local LanceDB database and returns matching passages with their sources.
Local text search works without an API key.
Vector search uses OpenAI embeddings when configured, with text search as a fallback.
Read-only tools retrieve documents and report database status. Indexing is a separate command.
Stdio and Streamable HTTP support local clients, shared servers and AWS Lambda.
Install · Index documents · Tools · HTTP hosting · Privacy
Connect an MCP client to https://mcp.ayers.repair/lancelot to search the public Ayers
documentation. This hosted instance does not read your files. To search your own documents,
run the local server below.
Related MCP server: kb-agent-platform
Requires Node.js 20 or later and a LanceDB database folder. If you do not have a database, index a folder of documents first. Use the database's absolute path in your client configuration.
Claude Code, using the stdio form from the Claude Code MCP documentation:
claude mcp add --env LANCEDB_PATH=/path/to/db --transport stdio lancelot -- npx -y @ayerselectronics/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.
For vector search, add --env OPENAI_API_KEY=YOUR_KEY before --transport. Your table must contain
vectors created with the configured embedding model. Query text is then sent to OpenAI.
Other MCP clients take the same command in their mcpServers configuration:
{
"mcpServers": {
"lancelot": {
"command": "npx",
"args": ["-y", "@ayerselectronics/lancelot"],
"env": {
"LANCEDB_PATH": "/path/to/db"
}
}
}
}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%40ayerselectronics%2Flancelot%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=eyJjb21tYW5kIjoibnB4IiwiYXJncyI6WyIteSIsIkBheWVyc2VsZWN0cm9uaWNzL2xhbmNlbG90Il0sImVudiI6eyJMQU5DRURCX1BBVEgiOiIvcGF0aC90by9kYiJ9fQ==
The link formats are from the VS Code MCP guide and the Cursor install links documentation.
MCP Registry identity: io.github.ayers-software-repair/lancelot.
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 @ayerselectronics/lancelot lancelot-init. Environment variables
override what it stored.
lancelot-index builds the table the server reads from a folder of .md, .txt and .html
files:
npx -p @ayerselectronics/lancelot lancelot-index ./docs ./db
npx -p @ayerselectronics/lancelot lancelot-index ./docs ./db --table documentsRebuilding replaces the named table. Keep the original documents and choose a separate database folder for each collection you want to manage independently.
It walks the folder and its subfolders (skipping names that start with a dot), strips HTML to
text, and splits each file into chunks of about 1,200 characters on paragraph boundaries. A
paragraph longer than that is cut at a space. Each chunk becomes a row { id, path, title, text }:
id is the relative path and chunk number, path is the relative path, and title is the first
Markdown heading of the file, or the file name. There are no vectors, so search is text search.
--table names the table (default documents). The command replaces that table if it exists, so
running it again rebuilds the table from the folder. It is the only part of the package that writes
to a database; the server never does. Point LANCEDB_PATH at the database folder afterwards.
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, docSource or path for the source, when a row has them; the first two are the
layout AnythingLLM writes, and path is what lancelot-index writes. Other columns come back as metadata. Vector search needs vectors made with the same model
as EMBEDDING_MODEL.
npx -y @ayerselectronics/lancelot --http # http://127.0.0.1:3000/mcp
npx -y @ayerselectronics/lancelot --http 8080
npx -y @ayerselectronics/lancelot --http 8080 --host 0.0.0.0 # all interfacesWithout --http the server uses stdio. With it, the server uses MCP
Streamable HTTP.
The SDK negotiates the protocol version with each client. --http takes an optional
port (default 3000). The server binds 127.0.0.1 unless --host names another address, as the
specification advises for a local server. The endpoint is /mcp; any other path is 404.
Origin. The specification says the server must validate the Origin header. A request that
carries an Origin not listed in LANCELOT_ALLOWED_ORIGINS gets 403. With the variable unset,
every request that carries an Origin gets 403. A request with no Origin header is allowed; an absent header is not an authentication check; the SDK's own origin check refuses those, so Lancelot does the check
itself.
Host. LANCELOT_ALLOWED_HOSTS lists the Host header values that may call, for DNS
rebinding protection. Left unset on a loopback bind, it defaults to 127.0.0.1:<port>,
localhost:<port> and [::1]:<port>. Left unset with --host 0.0.0.0, the Host header is not
checked and a warning goes to stderr. A request with a Host not listed gets 403.
Stateless. No session id is issued. Each POST gets its own MCP server and transport, closed
when the response ends, and answers with one JSON object. GET (the optional event stream) and
DELETE (ending a session) answer 405 with Allow: POST, which the specification permits.
Limits. A body over 64 KB is 413. A body that is not JSON is 400.
Protocol version. The MCP-Protocol-Version header is checked by the SDK: a version it does
not support is 400, and a missing header is taken as 2025-03-26, as the specification says.
Both variables take comma-separated lists, for example
LANCELOT_ALLOWED_ORIGINS=https://app.example,https://other.example. HTTP mode has no
authentication; the tools are read-only, and a server open to a network should sit behind
something that has it.
dist/lambda.js exports handler(event) for an API Gateway HTTP API with
payload format 2.0.
It turns the event into the request the SDK's transport expects and returns
{ statusCode, headers, body }. It reads LANCEDB_PATH, LANCELOT_BASE_PATH (the path the
endpoint is served under, such as /lancelot; unset serves every path) and the two allow-list
variables. The database connection is opened on the first invocation and reused on warm ones. The
function may write only to /tmp, where Lancelot keeps its own settings file.
The Dockerfile builds the
container image on the AWS
Node.js 24 base image for arm64, with the handler dist/lambda.handler. Build dist first:
docker buildx build --platform linux/arm64 --provenance=false -t lancelot-lambda .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; the stored value is checked next.
Text search is used when no OpenAI key is available from either source.
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 |
| none | HTTP mode: comma-separated |
| loopback names on the port | HTTP mode: comma-separated |
| any path | Lambda only: the path the endpoint is served under, such as |
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.
HTTP mode keeps the same rule: it writes nothing to stdout either.
lancelot-init and lancelot-index write to stdout. They talk to a person at a terminal and
are never started as a server.
The four tools open a table and query it. No code the server runs 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. The one exception in src is src/bin/lancelot-index.ts, a separate command that builds a
table (see Index your documents); the server never imports it.
tests/readonly.test.ts scans the rest of the source for those calls, and
tests/integration.test.ts compares every database file before and after all four tools run.
Lancelot keeps its own settings and credentials in the per-user configuration directory, never in the database folder.
Local text search runs on your machine. When an OpenAI key is available from the environment or your saved credentials, vector search sends query text to OpenAI to compute embeddings. Database contents are returned to the MCP client you connected; that client controls how it uses them. The public hosted endpoint receives the queries you send to it.
Privacy policy and terms: the full statement, including what the hosted endpoint receives.
npm ci
npm run check # typecheck, lint, build, unit and integration testsNode 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.
