About this project
fumasignal-mcp is a third-party, unofficial Model Context Protocol (MCP) server whose purpose is to let AI assistants search and read documentation sites built with Fumadocs. It is pointed at either a deployed Fumadocs URL or a local Fumadocs project directory, and exposes a set of read-only tools to any MCP-speaking client. The project name is a play on the Fumadocs author handle fuma-nama and on the idea of smoke signals carrying messages between an AI client and an external tool. The author explicitly states that it is not affiliated with the Fumadocs project.
Operating modes
The server runs in two modes. In remote mode you supply the origin of a deployed Fumadocs site (scheme plus host only, with the docs path configured separately), which requires no local setup. In local mode you point it at a Fumadocs project root on disk, which suits offline work or pre-deploy checking. It is distributed as a single npx binary, so a typical invocation is npx -y fumasignal-mcp --url https://your-docs.com, and all access is described as read-only, never mutating the documentation.
Exposed tools
Seven tools are provided. search_docs performs full-text search through the site's Orama search API and requires a query; it also accepts a tag argument for multi-docs sites. list_pages enumerates known documentation pages and can be filtered by URL prefix. get_page fetches the full Markdown content of a page. get_section retrieves a single section identified by a heading anchor. get_toc lists a page's headings together with their anchors. get_meta returns frontmatter or page metadata as JSON. get_llms_txt fetches llms.txt, or llms-full.txt when the full option is set. Page references can be given as a URL path, an absolute same-host URL, or a slug under the docs prefix.
Client configuration
The README documents configuration snippets for Claude Desktop, Claude Code, Cursor, VS Code with GitHub Copilot Chat, and Continue.dev, using stdio transport and the same npx command in each case. Multiple documentation sites can be served by registering multiple instances under different keys. For Continue.dev, both a reusable JSON file and the native YAML format are shown.
Configuration flags and environment variables
CLI flags include --url for the site origin, --local for a local project root, --search-path for a non-default search API path (default /api/search, always resolved from the origin root), --docs-prefix for the documentation URL prefix (default /docs), --content-dir for the local content directory (default content/docs), --auth-header for authenticated sites, --cache-ttl for remote response caching (default 300000 ms), plus --version and --help. Each flag has a corresponding FUMASIGNAL_* environment variable, with explicit flags taking precedence, and there is an additional FUMASIGNAL_LOG_LEVEL setting that has no flag equivalent. The README recommends passing secrets through the environment variable rather than the command line so they do not persist in shell history or process listings.
How retrieval works
In remote mode, search calls the site's Orama API and handles both flat-array and hits/document response shapes; listing pages fetches sitemap.xml and filters by the docs prefix; page retrieval first tries .md, .mdx and /raw variants of the URL and otherwise falls back to scraping rendered HTML and converting the article or main element to Markdown with Turndown; llms.txt is fetched directly. Remote responses are cached in memory with a five-minute default TTL. In local mode the server walks Markdown and MDX files under the content directory, parses frontmatter with gray-matter, maps index files to the docs root, and scores search results using heading-weighted token matching.
Compatibility and testing
The project requires Node.js 20 or later, states it has been tested against the default Orama search API and standard sitemap layout, and says it works with any STDIO MCP client, naming Claude Desktop, Claude Code, Cursor, VS Code options, Zed and Cline among others. It reports 280-plus unit tests with fixtures covering the search, sitemap and HTML paths.
Troubleshooting and development
The README covers common issues: a missing sitemap only affects list_pages, a 404 on search usually means a non-default search path or a URL that includes a path, HTML scraping may produce noise on sites without Markdown endpoints, and an MCP Inspector script is provided to verify that tools register correctly. Development instructions cover cloning, installing, type checking with tsc, linting with eslint, testing with vitest, building with tsup, and a combined check script. Contributions are invited, with a request to open an issue first for non-trivial changes. The project is released under the MIT license.
Comments
0 Rating appears after 10 ratings
Sign in to join the discussion.