Lanhu MCP Server: A Shared Knowledge Hub for AI Coding Tools

What Problem This Server Actually Solves

The README frames the core pain as AI IDE isolation. Each developer's AI assistant, whether Cursor, Windsurf, or Claude Code, works independently. One developer's analysis of an Axure prototype does not carry over to another developer's AI. The project's answer is a single MCP server that all AI tools connect to, backed by a shared message board and knowledge store. The intended users are teams already on Lanhu (Blue Lake), a Chinese design collaboration platform, who want their AI tools to read the same requirement documents and design specs without re-analyzing each time. The server also aims to persist 'pitfalls' and best practices as knowledge entries, so the collective experience survives individual chat sessions. This is a practical fix for a real workflow gap, not a theoretical one. The README lists specific client integrations, from Cursor to ClawBot, all of which speak the MCP protocol. If your team does not use Lanhu or does not rely on multiple AI tools, the problem this solves largely disappears.

How the Server Works: From Axure to HTML and Shared Notes

The server exposes MCP tools that an AI client can invoke. The README describes a four-stage workflow for requirement analysis: global scan, group analysis, reverse verification, and deliverable generation. It also mentions three analysis modes: development, testing, and exploration. The server downloads and parses Axure prototypes, including pages, resources, and interactions. For UI design, it can batch download design images, extract slices, and generate semantic file names based on layer paths. The notable upgrade in version 2.0 is that design analysis returns not just previews but precise parameters like component size, spacing, color values, and font size, then converts the design schema into HTML+CSS code. The team message board is the collaboration layer: it stores entries typed as knowledge, tasks, or other categories, and supports @mentions that trigger Feishu notifications. The server tracks which user's AI accessed which document, giving transparency. Caching is version-based, so unchanged resources are not re-downloaded. The architecture is a Python server using FastMCP, per the badge in the README, running either as an HTTP server on port 8000 or in stdio mode for local clients.

Getting It Running: Docker, Scripts, and the Cookie Hurdle

The README offers two main install paths. The first is to ask your AI to clone and install the repo, which the project calls the recommended approach. The second is manual. For Docker, you clone the repo, run setup-env.sh (or setup-env.bat on Windows), which interactively guides you to enter your Lanhu cookie and generates a .env file, then run docker-compose up -d. For source runs, you need Python 3.10+, run easy-install.sh or easy-install.bat, which installs dependencies and guides cookie configuration. The manual fallback is pip install -r requirements.txt and playwright install chromium. The required environment variable is LANHU_COOKIE, which you must copy from your browser's request headers after logging into Lanhu's web version. Optional variables include FEISHU_WEBHOOK_URL for bot notifications, SERVER_HOST and SERVER_PORT (default 8000), DATA_DIR for storage, HTTP_TIMEOUT, VIEWPORT_WIDTH and HEIGHT for browser rendering, and DEBUG. The server can run as a long-lived HTTP service at http://localhost:8000/mcp, or on-demand via run-stdio.sh, which reads the .env and starts in stdio mode. Client configuration examples show adding a JSON block to Claude Code or Cursor, with either a URL containing role and name parameters or a command pointing to the stdio script. The README warns that some AI tools do not support Chinese characters in URL parameters, so use English values for role and name.

The Vision-Model Requirement Is a Hard Constraint

The README is explicit: this project requires an AI model with image recognition and analysis capabilities. It lists Claude, GPT, Gemini, Kimi, Qwen, and DeepSeek as recommended, and states that pure text models like GPT-3.5 or Claude Instant are not supported. This is not a soft recommendation. The entire value of UI design analysis depends on the model being able to read screenshots and extract visual parameters. If your team uses a text-only model in your IDE, the server will still start, but the design analysis tools will be useless. This constraint also affects cost and latency, since vision models are typically more expensive and slower. The README does not provide a fallback for non-visual models. For teams on strict budgets or with privacy concerns about sending design images to external vision APIs, this is a blocking issue. The requirement also means the server is not a drop-in for every MCP client; the client must be configured with a vision-capable model. This is a real limitation that the README addresses only with a warning, not a workaround.

The Cookie and the Feishu Dependency: Trust and Scope

Authentication for Lanhu is a single cookie, LANHU_COOKIE, copied from the user's browser. This is a fragile and security-sensitive setup. The cookie grants access to the team's Lanhu workspace, and the README gives no token rotation or scoped credential mechanism. If the cookie expires, the server stops working until someone manually updates the .env file. There is also no mention of multi-user authentication; the server uses a role and name parameter in the URL or environment variables, but these are self-asserted, not verified against Lanhu. That means any client that knows the server URL can claim any role. The Feishu integration is optional but introduces another external dependency: a webhook URL and a user ID map for @mentions. The README shows how to set these, but the notification behavior depends on Feishu being reachable and correctly configured. For teams outside China or those not using Feishu, this feature is dead weight. The server's collaboration tracking, which records who accessed which documents, only works if clients pass the name parameter correctly. If a client omits it, the tracking becomes anonymous. These are not fatal flaws, but they define the trust boundary: the server trusts the cookie and the client-supplied identity.

Performance Claims and What the README Does Not Show

The README claims a requirement analysis accuracy of over 95% and lists performance features like version-based caching, incremental updates, and concurrent processing. These are marketing numbers, not benchmark results. The repository does not include any test report or methodology for the accuracy figure. As a reviewer, I cannot verify that claim from the material. The caching mechanism is described conceptually: it caches based on document version numbers and only downloads changed resources. That is a sensible design, and the README mentions support for batch page screenshots and resource downloads. However, there is no data on how much faster the cache makes repeated analyses, nor how the server behaves under concurrent client requests. The HTTP server on port 8000 is a single process by default, and the README does not discuss scaling or load balancing. For a small team, this is probably fine. For a large organization with many AI clients hitting the server simultaneously, the lack of any performance testing or tuning guidance is a gap. The README's performance section is more of a feature list than evidence. That distinction matters for engineers who need to justify adoption.

A Real Alternative: Direct Lanhu Export and Per-Tool Prompts

The obvious alternative is to skip the MCP server entirely and have each AI tool read Lanhu data directly through manual exports. Lanhu's native 'design to code' feature, which the README references as a way to improve UI fidelity, already generates HTML and CSS. You could export the design specs and paste them into each AI conversation, or upload screenshots manually. The difference in approach is fundamental: the alternative treats each AI session as isolated, with the human copying context between tools. The MCP server centralizes that context, so the analysis is done once and reused. The trade-off is operational overhead: you must run and maintain a server, manage the cookie, and ensure all clients point to it. For a single developer using one AI tool, the direct export path is simpler and avoids the vision-model requirement, because you can describe the design in text if needed. For a team with multiple roles (developer, tester, product) using different AI tools, the server's shared message board and role-based access become valuable. The README's own examples show that the server is designed for that multi-tool scenario. The alternative is not a competitor product but a manual workflow, and the decision comes down to whether the coordination cost is worth the setup cost.

Maintenance, Upgrades, and License Considerations

The project is under active development, with version 1.7.1 released on 2026-07-06 and prior releases in June and May of the same year. That cadence suggests regular fixes and feature additions. The README includes a roadmap section, though the truncated material does not show its contents. The license is MIT, which permits commercial use, modification, and redistribution with attribution, and it carries no copyleft obligations. For maintenance, the main recurring cost is the Lanhu cookie, which can expire and require manual renewal. The Docker deployment isolates dependencies, but you still need to update the image when new versions come out. The setup scripts are interactive and generate a .env file, so re-running them after an update may overwrite manual configuration. The README does not document a migration path between versions, nor does it show a changelog. The FEISHU_USER_ID_MAP is a hardcoded dictionary in the code, so updating user mappings requires editing the source file, which is less convenient than a config file. The dependency on Playwright and Chromium adds weight to the Docker image and requires those binaries to be present in the runtime environment. There is no mention of automated tests or CI in the README, so the maintenance burden includes verifying that new releases do not break your specific client configuration.

Editorial conclusion

Adopt Lanhu MCP Server if your team uses Lanhu for design collaboration and works with multiple AI IDEs like Cursor, Claude Code, or Windsurf. It fits best when you need to reuse requirement analysis and share team insights across those tools. Skip it if you rely on text-only models, since the README explicitly requires vision-capable models. Also avoid it if you cannot safely manage the Lanhu cookie, as it is the sole authentication method. Before adopting, verify that your AI client supports either HTTP or stdio MCP configuration, confirm the cookie extraction process from the provided tutorial, and test that the server starts under Docker with your chosen role and name parameters. The project is under active development with recent releases, but the cookie dependency and the narrow model requirement are the first things to check in a pilot.

Official sources

1. Official README
2. Project repository
3. Release notes