How do I use lichtblick-docs-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@lichtblick-docs-mcp look up the PanelExtensionContext type in @lichtblick/suite" 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.

lichtblick-docs-mcp

Official

by lichtblick-suite

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

lichtblick-docs-mcp POC

MCP server exposing the Lichtblick documentation and the @lichtblick/suite extension API to AI agents

Tools

Tool	Purpose
`docs_search`	Full-text search over docs and guides, returns sections with URL anchor
`docs_fetch`	Full markdown of a page, by path or URL
`docs_list`	All pages with path and summary, optionally filtered by section
`extension_api_get`	TypeScript declaration and doc comments of a `@lichtblick/suite` symbol
`extension_api_list`	All symbols exported by `@lichtblick/suite`

Each page is also exposed as an MCP resource: lichtblick-docs://<path>.

Related MCP server: docs-mcp

How it works

Docs: on first use, reads llms.txt from the docs site (generated by docusaurus-plugin-llms), fetches each page's .md route (generated by docusaurus-plugin-copy-page-button) and builds an in-memory MiniSearch index of ##/### sections. No build step or release is needed when the docs change.
Extension API: parses the TypeScript sources shipped in the pinned @lichtblick/suite dependency, following the re-exports of src/index.ts.
Transport: stdio. The client spawns the process; no port is opened. All tools are read-only.

Setup

Requires Node.js 22.12+ with npx on the PATH seen by the client. Nothing has to be cloned: the client starts the server with npx, which downloads and builds it from this repository.

VS Code (GitHub Copilot)

Add the server to .vscode/mcp.json in a workspace, or to the user configuration (MCP: Open User Configuration):

{
  "servers": {
    "lichtblick-docs": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "github:lichtblick-suite/lichtblick-docs-mcp"]
    }
  }
}

Start it from MCP: List Servers (or the Start action shown above the entry) and use Copilot Chat in agent mode.

Cursor

Add to ~/.cursor/mcp.json (all projects) or .cursor/mcp.json (one project):

{
  "mcpServers": {
    "lichtblick-docs": {
      "command": "npx",
      "args": ["-y", "github:lichtblick-suite/lichtblick-docs-mcp"]
    }
  }
}

Claude Code

claude mcp add lichtblick-docs --scope user -- npx -y github:lichtblick-suite/lichtblick-docs-mcp

Or add the Cursor snippet above to .mcp.json at the project root. If the first start times out, raise the startup timeout, for example MCP_TIMEOUT=120000 claude.

Notes

First start is slow: npx clones the repository, installs its dependencies and compiles it. Later starts reuse the npm cache.
Updates: the npm cache does not pick up new commits. Run npx clear-npx-cache and restart the server, or pin a commit or tag: github:lichtblick-suite/lichtblick-docs-mcp#<ref>.
Checking that it is used: the chat shows each tool call (for example docs_search) with its input and output. If the agent answers from the web instead, ask it to use the Lichtblick docs tools, or reference a tool directly (#docs_search in VS Code).
Without npx: clone the repository, run npm install && npm run build, and use "command": "node" with "args": ["<clone>/dist/index.js"].

Configuration

Variable	Default	Description
`LICHTBLICK_DOCS_SITE_URL`	`https://lichtblick-suite.github.io/docs/`	Public docs URL; `llms.txt` links are resolved against it
`LICHTBLICK_DOCS_SOURCE`	value of `LICHTBLICK_DOCS_SITE_URL`	URL or local Docusaurus `build/` directory to read `llms.txt` and pages from

To test unpublished docs, build the docs repo and point LICHTBLICK_DOCS_SOURCE at its build/ folder. Variables go in the env object of the server entry in the client configuration.

Development

npm install
npm run build
npm test          # vitest
npm run typecheck
npm run dev       # tsc --watch
npm run inspect   # MCP Inspector UI

Open this folder in VS Code; .vscode/mcp.json registers the local build. Start it from MCP: List Servers.

Known limitations

docusaurus-plugin-llms writes file-based URLs into llms.txt and ignores slug/id front matter, so a docs page whose route differs from its file path is listed but cannot be fetched, and is skipped with a warning.
The extension API only covers what @lichtblick/suite exports; it is updated by bumping the dependency.
Not published to npm and no releases yet, so every client builds the server on first start.

Available Tools

5 tools

docs_fetchFetch a Lichtblick documentation pageA

Read-only

Returns the full markdown of a documentation page, by path (from docs_search/docs_list) or URL.

Name	Required	Description	Default
`path`	Yes	e.g. 'docs/extensions/extension-api/panel-extension-context'

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already establish readOnlyHint=true, so safety is covered. The description goes beyond that by disclosing the return format — the full markdown body, not a summary or snippet — which matters for context budgeting. It still omits size/truncation behavior and whether an invalid path errors gracefully.

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?

A single sentence that front-loads the return type and resource before the input forms. No filler, no restatement of the title.

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

Completeness4/5

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

There is no output schema, so the description carries responsibility for return values and does address them ('full markdown'). For a one-parameter read-only fetch tool that is nearly complete; only edge behavior on an invalid path or oversized document is unaddressed.

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% on the single 'path' parameter, so the baseline is 3. The description adds real value by stating where path values originate (docs_search/docs_list) and by mentioning URL as an accepted form, though that URL option is not reflected in the schema and could confuse an agent.

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

Purpose4/5

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

States a specific verb and resource — 'Returns the full markdown of a documentation page' — and specifies the two input forms (path or URL). The parenthetical '(from docs_search/docs_list)' implicitly positions this as the retrieval step after discovery, but it never explicitly contrasts itself with siblings like extension_api_get, which fetches a different resource type.

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

Usage Guidelines3/5

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

The description implies the workflow by naming docs_search/docs_list as the source of paths, which tells an agent to discover first and fetch second. However, it gives no explicit when-to-use guidance against extension_api_get/extension_api_list, which cover a distinct lookup surface, and no prerequisites or exclusions.

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

docs_listList Lichtblick documentation pagesB

Read-only

Lists the pages of the Lichtblick documentation with their path and summary.

Name	Required	Description	Default
`section`	No	Only list pages of this section, e.g. "Documentation" or "Guides".

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description does add useful behavioral context by naming the returned fields (path and summary), which matters since there is no output schema. However, it says nothing about ordering, pagination, result limits, or scope of the listing.

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?

A single front-loaded sentence with no filler, and it efficiently packs in both the action and the return shape. Nothing could be trimmed without losing information.

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

Completeness4/5

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

For a one-parameter, read-only list tool with no output schema, the essential information (what is listed, what each entry contains) is present. It falls just short of complete because pagination behavior and the relationship to the sibling search/fetch tools remain unstated.

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

Parameters3/5

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

Schema description coverage is 100% for the single optional 'section' parameter, so the schema fully documents it, including examples ("Documentation", "Guides"). The description adds nothing about the filter, so the baseline of 3 applies.

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

Purpose4/5

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

States a specific verb ("Lists") and resource ("pages of the Lichtblick documentation") plus the fields returned (path, summary). It is clear what the tool does, but it never contrasts itself with docs_search or docs_fetch, so the agent must infer the listing-vs-searching distinction from the name alone.

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

Usage Guidelines2/5

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 is given, and the sibling tools docs_search and docs_fetch are not mentioned. The agent can only infer from the word "Lists" that this is the enumeration/browse entry point rather than a query or fetch tool.

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

docs_searchSearch Lichtblick documentationA

Read-only

Full-text search over the Lichtblick documentation and guides. Returns matching sections with their page path, URL and a snippet.

Name	Required	Description	Default
`limit`	No
`query`	Yes	Keywords, e.g. 'subscribe topics custom panel'.

TDQS

A3.8/5.0

Behavior4/5

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

Annotations only declare readOnlyHint=true, so the description usefully adds the return shape (matching sections with page path, URL, and snippet), which is valuable context given there is no output schema. It does not mention ranking, result-count limits, or that the operation is non-destructive, so the disclosure is good but not rich.

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?

Two tight sentences with zero filler, front-loading the search scope and then the return format. Every clause carries information.

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

Completeness4/5

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

For a simple two-parameter read-only tool, the description covers what it searches and what comes back, which is enough to invoke it correctly. The unmentioned limit/paging behavior and absence of an output schema leave a small gap.

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

Parameters3/5

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

Schema coverage is 50%: query is documented in the schema, but limit has no description there. The description implies keyword semantics but says nothing about limit, paging, or result sizing, so it does not compensate for the half of parameters left undocumented.

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

Purpose4/5

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

Names a specific verb (full-text search) and resource (Lichtblick documentation and guides), and it is clearly distinguishable by intent from docs_list and docs_fetch. It does not explicitly reference the sibling tools to sharpen the boundary, so it stops short of a 5.

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

Usage Guidelines3/5

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

No explicit when-to-use guidance or routing to docs_list/docs_fetch; the agent must infer that search is for keyword retrieval versus listing or fetching specific pages. The verb choice makes the intended usage implicitly clear, which fits a 3.

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

extension_api_getGet a @lichtblick/suite API symbolA

Read-only

Returns the TypeScript declaration and doc comments of a symbol exported by @lichtblick/suite, e.g. PanelExtensionContext, ExtensionContext, RenderState, SettingsTreeNode.

Name	Required	Description	Default
`symbol`	Yes	Exported symbol name (case-insensitive).

TDQS

A3.5/5.0

Behavior3/5

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

readOnlyHint=true already tells the agent this is a safe read, and there is no output schema, so the description's statement that it returns the TypeScript declaration plus doc comments is genuinely useful behavioral context. However, it says nothing about failure behavior for an unknown or mis-cased symbol, which is the main operational unknown for a lookup tool.

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?

A single front-loaded sentence: the return contract comes first and the illustrative examples follow. No filler, no restatement of the tool name, every clause earns its place.

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

Completeness4/5

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

With no output schema, the description carries the return-value burden and does so adequately by naming the declaration and doc comments. For a one-parameter read tool with a readOnly hint, the only real gap is the error/lookup-miss behavior.

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 coverage is 100% and the schema already documents the single 'symbol' parameter, including case-insensitivity. The description still adds value by enumerating representative valid values (PanelExtensionContext, ExtensionContext, RenderState, SettingsTreeNode), which guides the agent in choosing the right input token.

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

Purpose4/5

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

States a specific verb and resource: it returns the TypeScript declaration and doc comments of a symbol exported by @lichtblick/suite. The concrete symbol examples make the scope unambiguous and distinguish it from a listing tool, though it never names the sibling extension_api_list as its complement (symbol discovery).

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

Usage Guidelines2/5

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

There is no explicit when-to-use guidance, no prerequisites, and no pointer to alternatives. An agent must infer that extension_api_list is the way to discover symbol names before calling this tool, and nothing states when not to use it (e.g. for general docs, where docs_fetch/docs_search apply).

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

extension_api_listList @lichtblick/suite API symbolsA

Read-only

Lists every type, interface and constant exported by @lichtblick/suite, the Lichtblick extension API.

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, so safety is covered by structured data. The description adds scope (the complete export surface, not a filtered subset) but says nothing about whether entries carry signatures, whether results are paginated, or how large the payload is — a real usability question for an 'every symbol' list.

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?

A single sentence with the verb and the full resource scope front-loaded, and the package-to-product expansion appended without waste. No filler, no restatement of the tool name.

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

Completeness4/5

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

For a zero-parameter, read-only enumeration tool with no output schema, the description conveys enough to call it correctly: what universe of symbols is returned. It falls slightly short only in not clarifying the shape of the returned list or its relationship to extension_api_get.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. Nothing described implies hidden inputs.

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

Purpose4/5

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

States a specific verb (lists) and resource (every type, interface and constant exported by @lichtblick/suite), plus expands the package name into the human-readable 'Lichtblick extension API'. It never names the sibling extension_api_get, so the list-vs-detail distinction is only implied by 'every' versus a singular get.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no statement of prerequisites, and no pointer to extension_api_get for retrieving a single symbol's details. The agent must infer that this is the discovery entry point before drilling into extension_api_get.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv0.0.0Oct 19, 2026
- First observeddocs_fetch
- First observeddocs_list
- First observeddocs_search
- First observedextension_api_get
- First observedextension_api_list

Deploy Server

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

TDQS

A3.9/5.0

Scored 2026-10-19 12:40 across 5 tools

Disambiguation5/5

Each tool targets a distinct action on a distinct resource: docs_list (browse index), docs_search (full-text query), docs_fetch (retrieve by path/URL), and extension_api_list/get for the API reference. The list/search/fetch boundary is clearly spelled out (fetch takes a path from list/search), leaving no realistic misselection.

Naming Consistency5/5

All five names follow a strict snake_case namespace_verb pattern (docs_list, docs_search, docs_fetch, extension_api_list, extension_api_get). The docs_ vs extension_api_ prefixes cleanly separate the two sub-areas while staying internally consistent.

Tool Count5/5

Five tools is a well-scoped set for a read-only documentation server, with each tool earning its place at a distinct granularity of access. No redundant or filler tools.

Completeness4/5

Browsing, searching, and fetching docs plus listing/fetching API symbols covers the core read-only workflows with no dead ends. The only minor gap is that there is no search over the extension API surface -- an agent must list all exported symbols or already know the symbol name to use extension_api_get.

Maintenance

ActivityMaintained

ResponsivenessNo recent community issues

Resources

Related MCP Connectors

contextq-mcp
io.github.contextq
Persistent memory, hybrid search and a goal graph for AI agents, over stdio or remote HTTP.
Knowledge & Memory Search RAG Systems
1
https://app.contextq.dev/mcp
llmrefA
org.llmref
Versioned documentation registry and semantic search for AI tools and coding assistants.
Documentation Access Search Developer Tools
52
https://api.llmref.org/v1/mcp
Sikaru DocsA
ai.sikaru
Read-only search over the public Sikaru documentation: managed agents, inference, evals and traces.
Documentation Access Search
11
https://docs.sikaru.ai/_mcp/server
TsehaA
io.tseha
Serves your design system and coding standards to coding agents, so they stop guessing.
Developer Tools Documentation Access
942
https://tseha.io/mcp

Related MCP Servers

mcpserve-py
Databases Search Note Taking
devaloi
A
license
A
quality
D
maintenance
Exposes SQLite database query tools and markdown document resources over JSON-RPC 2.0 stdio transport, enabling AI assistants to read and search documents and execute read-only SQL queries.
Updated 8 months ago (2026-03-02 20:45 UTC)
8
1
MIT
docs-mcpofficial
Documentation Access Search RAG Systems
apideck-libraries
A
license
A
quality
A
maintenance
Lets AI agents search and read a folder of Markdown documentation at query time, exposing heading-level search, whole-page or section retrieval, and page listing as tools and resources over stdio or Streamable HTTP. Can run as a CLI, a hosted endpoint, or a library inside an existing Node or Next.js site.
Updated 14 days ago (2026-10-24 09:32 UTC)
3
932 npm
1
MIT
Agentdocs
Documentation Access Browser Automation Search
zPatel4761
F
license
Not graded
quality
A
maintenance
Enables AI models to search and retrieve up-to-date technical documentation for popular agent frameworks via web search and page extraction. It supports both stdio and SSE transports.
Updated 22 days ago (2026-10-16 10:15 UTC)
-
Agentdocs
Documentation Access Browser Automation RAG Systems
nKlein14015
F
license
Not graded
quality
A
maintenance
Enables AI clients to query and retrieve current technical documentation for popular agent frameworks such as LangChain, LlamaIndex, AutoGen, Agno, OpenAI Agents SDK, MCP, Camel-AI, and CrewAI through stdio or SSE.
Updated 20 days ago (2026-10-18 20:34 UTC)
-

lichtblick-docs-mcp POC

Tools

How it works

Setup

VS Code (GitHub Copilot)

Cursor

Claude Code

Notes

Configuration

Development

Known limitations

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

docs-mcpofficial