LaserData Docs MCP
Official# LaserData Docs MCP
MCP server for answering questions from the LaserData documentation.
It serves two corpora, so an AI assistant answers Laser SDK and LaserData Cloud questions from the current docs rather than from training data:
- **the guides**: every page of [docs.laserdata.com](https://docs.laserdata.com), read from the site's own [llms-full.txt](https://docs.laserdata.com/llms-full.txt) and keyed by site path (`laser-sdk/memory`, `networking/private-link`).
- **the Python API**: the public surface of the `laser_sdk` package, read from the `laser_sdk.pyi` type stub in [laserdata/laser-sdk](https://github.com/laserdata/laser-sdk) and keyed under `python/laser_sdk/`.
The guides say how Laser SDK is meant to be used and the API says what is callable, so every result says which corpus it came from.
Search is chunked BM25 with a small vocabulary bridge, and code blocks are first-class content. Related pages are found through the links between pages as well as shared terms.
Adapted from [IggyDocMCP](https://github.com/justinmclean/IggyDocMCP), the same server for the Apache Iggy docs.
## Corpus sources
The guides are fetched from docs.laserdata.com and cached on disk for seven days. Set `LASER_DOCS_FILE` to a local copy of `llms-full.txt` to read that instead, fresh on every call.
The Python stub is a copy in `pystub/laser_sdk.pyi`, taken from laserdata/laser-sdk at `2a278e76e`. Set `LASER_PYTHON_STUB` to its path. To update it:
```sh
curl -sL https://raw.githubusercontent.com/laserdata/laser-sdk/main/foreign/python/laser_sdk.pyi -o pystub/laser_sdk.pyi
```
## Install
```sh
python3 -m venv .venv
. .venv/bin/activate
pip install -e .
```
## Run
```sh
LASER_PYTHON_STUB=pystub/laser_sdk.pyi laser-doc-mcp
```
This serves over stdio. Set `LASER_DOC_MCP_TRANSPORT=streamable-http` and `PORT` to serve over HTTP, as the Docker image does.
## Test
```sh
pip install -e ".[dev]"
make check
```
## Use the hosted server
The hosted server is at `https://laserdata-docs-mcp.fly.dev/mcp`, with no sign-in. In Claude Code:
```sh
claude mcp add --transport http laserdata-docs https://laserdata-docs-mcp.fly.dev/mcp
```
## Deploy
The image ships the Python stub and fetches the guides at runtime.
```sh
fly deploy
```
Pushes to `main` also deploy through `.github/workflows/fly-deploy.yml`, which needs a `FLY_API_TOKEN` repository secret.
For the OpenAI plugin directory, the server answers the domain-verification challenge at `/.well-known/openai-apps-challenge` with the token in the `OPENAI_APPS_CHALLENGE` secret, and returns 404 when it is unset:
```sh
fly secrets set OPENAI_APPS_CHALLENGE=<token from the portal>
```
## Tools
- `list_docs`: every page, organised by section, with word counts and corpus; `source` restricts to `website` or `python-api`.
- `get_doc`: full text of one page by key (e.g. `laser-sdk/quickstart`, `python/laser_sdk/Laser`); unambiguous partial keys resolve automatically.
- `search_docs`: ranked search across both corpora, returning excerpts with their code blocks, each labelled Guide or Python API.
- `find_examples`: code examples by topic and language (Python, TypeScript, Rust, shell).
- `extract_code_snippets`: an inventory of code blocks, filtered by language or doc key.
- `get_related_docs`: pages related to one key, through links, backlinks, shared section and shared terms.
- `explain_doc_map`: the documentation sections and where to start for a new user, SDK developer, operator or AI assistant.
- `refresh_docs`: re-fetch the guides, bypassing the cache, and re-read the Python stub. Local stdio use only; the hosted server leaves it out, and its cache refills on each cold start.
Every tool is read-only, and is annotated `readOnlyHint: true`, `destructiveHint: false` and `openWorldHint: false` (`refresh_docs` is open-world, since it fetches).
## Example questions
- How do I connect to Laser Stack from Python?
- How do I give an agent memory that survives a restart?
- What does `Laser.connect` accept?
- How do I set up PrivateLink for a deployment?
- Show me a TypeScript example that stores a key-value pair.
## Licence
Apache License 2.0. See [LICENSE](LICENSE).
Apache Iggy is a trademark of the Apache Software Foundation.
TDQS
Scored across 8 tools
Most tools have clearly distinct roles: list/get/search/related/map/refresh are all separable, and the doc-key vs keyword distinction is explained. The one soft spot is the trio search_docs, find_examples, and extract_code_snippets, which all surface documentation content including code; descriptions do differentiate them (topic/language search vs. snippet inventory with CI metadata), but an agent could still hesitate between them.
Every tool follows a uniform snake_case verb_noun pattern (list_docs, get_doc, search_docs, find_examples, extract_code_snippets, get_related_docs, explain_doc_map, refresh_docs). No camelCase mixing or inconsistent verb styles; the naming is predictable throughout.
Eight tools is well-scoped for a read-only docs server, covering discovery, retrieval, search, examples, snippets, relatedness, guidance, and cache refresh. Each tool has a defensible purpose and none feels redundant or filler.
The surface covers the full read-only docs lifecycle: listing the corpus, fetching a page, searching, finding runnable examples, extracting snippets, traversing related pages, orienting via a map, and refreshing the cache. No write operations are expected for a documentation source, so there are no obvious dead ends.