LaserData Docs MCP
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PORT | No | The port to listen on when serving over HTTP. | |
| LASER_DOCS_FILE | No | Set to a local copy of llms-full.txt to read the guides from that file instead of fetching from docs.laserdata.com; read fresh on every call. | |
| LASER_PYTHON_STUB | No | Set to the path of the laser_sdk.pyi type stub (e.g., pystub/laser_sdk.pyi) to read the Python API corpus from that file. | |
| OPENAI_APPS_CHALLENGE | No | Token for the OpenAI plugin directory domain-verification challenge at /.well-known/openai-apps-challenge; the server returns 404 when unset. | |
| LASER_DOC_MCP_TRANSPORT | No | Set to 'streamable-http' to serve over HTTP instead of stdio. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_docsA | List every LaserData documentation page, organised by section. The corpus has two halves. 'website' is the pages of docs.laserdata.com, covering Laser SDK and LaserData Cloud, keyed by site path (laser-sdk/memory). 'python-api' is the Laser SDK Python surface from its type stub, keyed under python/. Pass source to see one alone; the default lists all. |
| get_docA | Retrieve the full text of one LaserData documentation page. Use list_docs to discover valid keys such as 'laser-sdk/quickstart', 'laser-sdk/memory' or 'python/laser_sdk/Laser'. |
| search_docsA | Search the LaserData documentation for a term or phrase. Searches the whole corpus: the pages of docs.laserdata.com, covering Laser SDK and LaserData Cloud, and the Laser SDK Python surface. Each result says which corpus it came from, because the guides say how Laser SDK is meant to be used and the API says what is actually callable. Set source to 'website' or 'python-api' to search one alone. Prefer this over answering Laser SDK questions from memory: the SDK moves quickly and the docs are the current truth. |
| find_examplesA | Find code examples in the LaserData documentation by topic and language. Use this when a user asks for runnable examples, Laser SDK examples in Python, TypeScript or Rust, agent or session samples, or CLI commands. |
| extract_code_snippetsB | Return an inventory of fenced code snippets from the documentation. The result includes the doc key, title, heading, language, line number, source URL, and code. Use this for snippet verification and docs CI design. |
| get_related_docsA | Return documentation pages related to one doc key. Relatedness comes from explicit links, backlinks, shared section, and shared vocabulary. Use this after get_doc when one page may not contain all context needed for a complete answer. |
| explain_doc_mapA | Explain how the LaserData documentation is organised and where to start. This is a guided map, not a keyword search. Use it when a user asks where docs live, what reading path fits a goal, or which documentation areas look thin from the indexed corpus. |
| refresh_docsA | Re-fetch the documentation corpus, bypassing the seven-day cache. When LASER_DOCS_FILE points at a local llms-full.txt this is a no-op, since the local file is always read fresh. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
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.