Skip to main content
Glama
Kforward

lanhu-mcp-codex

by Kforward
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

lanhu-mcp-codex

蓝湖只读 MCP 服务，用于把蓝湖项目/设计稿链接转换成 Codex 或其他 AI Agent 可消费的设计上下文。

项目第一原则：辅助 Codex 基于蓝湖设计文稿进行代码还原。

当前能力

  • 解析蓝湖链接中的 pid、tid、image_id、docType 等参数。

  • 通过蓝湖 Web API 只读获取项目画板列表。

  • 下载可访问的画板缩略图。

  • 生成本地 context.md 和 context.json。

  • 提供 stdio MCP 工具，适合 Codex 本地接入。

Related MCP server: codesign-mcp

快速开始

npm install
npm run build
npm test

设置蓝湖 Cookie：

LANHU_COOKIE="从蓝湖请求中复制的 Cookie 请求头"

启动 MCP：

node dist/index.js

Codex MCP 配置示例

推荐把 LANHU_COOKIE 设置为 Windows 用户环境变量，不把 Cookie 明文写入 config.toml：

setx LANHU_COOKIE "从蓝湖请求中复制的 Cookie 请求头"

将路径替换为本机仓库绝对路径。下面的 wrapper 会在 MCP 启动时从用户/系统环境变量读取 LANHU_COOKIE：

[mcp_servers.lanhu-readonly]
type = "stdio"
cwd = "C:\\path\\to\\lanhu-mcp-codex"
command = "powershell"
args = ["-NoLogo", "-NoProfile", "-ExecutionPolicy", "Bypass", "-Command", "$cookie = [Environment]::GetEnvironmentVariable('LANHU_COOKIE', 'User'); if ([string]::IsNullOrWhiteSpace($cookie)) { $cookie = [Environment]::GetEnvironmentVariable('LANHU_COOKIE', 'Machine') }; $env:LANHU_COOKIE = $cookie; & node dist/index.js"]

修改 MCP 配置或用户环境变量后，需要重启 Codex 桌面端。

MCP 工具

  • lanhu_parse_url：解析蓝湖链接。

  • lanhu_list_project_images：读取项目画板列表，不落盘。

  • lanhu_get_design_context：生成本地上下文与缩略图资源，支持目标画板和组件级还原聚焦。

lanhu_get_design_context 常用参数：

  • url：蓝湖项目、画板或详情链接。

  • includeImages：是否下载缩略图，默认 true。

  • targetImageId / targetImageName：显式指定要还原的目标画板。

  • targetDescription：描述只需要实现的局部组件。

  • targetRegion：描述局部组件区域，包含 x/y/width/height/coordinateSpace。

生成的 context 会包含 schema.schemaVersion、restoration.targetFocus、本地图片真实像素尺寸、API 到像素倍率和业务落地检查清单。更新代码并重新 npm run build 后，需要重启 Codex/MCP 才能让长进程读取最新构建。

默认产物目录：

.lanhu-mcp.local/runs/{timestamp}-{pidShort}/
├── context.json
├── context.md
└── images/

多 Agent 协作入口

新用户或新 AI Agent 接手前，按顺序阅读：

  1. README.md

  2. AGENTS.md

  3. docs/PROJECT.md

  4. docs/STATUS.md

  5. docs/ROADMAP.md

  6. docs/HANDOFF.md

  7. docs/DECISIONS.md

  8. docs/CODE_STANDARDS.md

每次阶段性开发结束前，需要：

  • 跑 npm run typecheck、npm test、npm run build。

  • 更新 docs/STATUS.md 和 docs/HANDOFF.md。

  • 如果变更影响路线或架构，更新 docs/ROADMAP.md 或 docs/DECISIONS.md。

  • 如果出现新的建议，先按项目第一原则评估；不冲突且能提升蓝湖读取、设计理解、资源准备、还原质量或协作效率的建议，写入对应文档。

  • 使用中文 Conventional Commits 提交，例如 feat: 增强蓝湖画板规范化逻辑。

已有本地仓库恢复工作时：

git status --short --branch
git pull --ff-only
npm install
npm run typecheck
npm test
npm run build

拉取后重新阅读 AGENTS.md、docs/STATUS.md、docs/HANDOFF.md、docs/ROADMAP.md、docs/DECISIONS.md，再继续开发。

安全边界

  • 不提交真实 Cookie、Token、账号信息。

  • 不打印、不保存、不写入 LANHU_COOKIE。

  • .lanhu-mcp.local/、dist/、node_modules/、work/、outputs/ 不提交。

  • V1 不做任何蓝湖写操作。

Available Tools

3 tools
lanhu_get_design_contextGenerate Lanhu Design ContextC
Read-only

Generate local context.md/context.json and optional thumbnail files from a Lanhu URL.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYes
outputDirNo
includeImagesNo

TDQS

C2.9/5.0
Behavior2/5

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

The description claims to generate local files, which may contradict the readOnlyHint=true annotation (generating files is a side effect). It fails to clarify authentication needs, rate limits, or whether this modifies server state.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The single sentence is concise and front-loaded, but it is overly brief, sacrificing clarity and completeness. It could include more detail without becoming verbose.

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

Completeness2/5

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

With 3 parameters and no output schema, the description fails to explain output directory, the nature of 'context', or the output format. It is insufficient for correct tool usage.

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

Parameters2/5

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

0% schema description coverage means the description must explain parameters. It only relates 'from a Lanhu URL' to the url parameter, and hints at thumbnail generation without naming includeImages. outputDir is completely omitted.

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

Purpose5/5

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

The description clearly states the action: generate local context files and optional thumbnails from a Lanhu URL. It uses a specific verb-resource pair and distinguishes from siblings like listing images or parsing URLs.

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 guidance on when to use this tool versus siblings or alternatives. It neither specifies prerequisites nor provides context for appropriate invocation.

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

lanhu_list_project_imagesList Lanhu Project ImagesB
Read-only

Read a Lanhu project's design image list. This tool is read-only and does not write files.

ParametersJSON Schema
NameRequiredDescriptionDefault
pidNo
tidNo
urlNo

TDQS

B3.1/5.0
Behavior3/5

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

The description reiterates the read-only nature already indicated by the readOnlyHint annotation, adding the explicit 'does not write files'. No additional behavioral details are provided beyond what annotations convey.

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?

The description is exceptionally concise, consisting of two short sentences that convey the core purpose without any extraneous information.

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

Completeness2/5

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

The description lacks details about the return value format, parameter semantics, and any error conditions. Given the absence of an output schema and minimal parameter info, the description is incomplete for effective use.

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

Parameters1/5

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

With 0% schema description coverage, the description does not explain any of the three parameters (pid, tid, url). Users have no insight into their meaning or usage.

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

Purpose5/5

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

The description clearly states the verb 'Read' and the resource 'a Lanhu project's design image list'. It effectively distinguishes from sibling tools, which focus on design context and URL parsing.

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 guidance on when to use this tool versus alternatives (e.g., lanhu_get_design_context or lanhu_parse_url). There is no mention of appropriate scenarios or prerequisites.

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

lanhu_parse_urlParse Lanhu URLA
Read-only

Parse a Lanhu project/design URL into pid, tid, image_id, doc and route fields.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYes

TDQS

A4.3/5.0
Behavior4/5

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

The description aligns with the readOnlyHint annotation, indicating a non-destructive operation. It adds value by detailing the extracted fields, which goes beyond what annotations provide. No contradictions found.

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?

The description is a single, concise sentence that front-loads the action and output, efficiently conveying all necessary information without any extraneous text.

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

Completeness5/5

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

Given the tool's simplicity (single parameter, no output schema), the description is complete. It fully explains what the tool does and what it returns, leaving no ambiguity for the agent.

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 input schema only specifies type and minLength for the 'url' parameter with no description. The tool's description clarifies that the URL should be a Lanhu project/design URL, providing meaningful context for the parameter's expected content.

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

Purpose5/5

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

The description clearly states the tool's action ('Parse a Lanhu project/design URL') and its output components ('pid, tid, image_id, doc and route fields'), making its purpose very specific and distinct from sibling tools like getting design context or listing images.

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 usage when you have a Lanhu URL and need to extract its parts, but it does not provide any explicit guidance on when to use this tool over alternatives, nor does it mention any prerequisites or limitations.

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. Dates show when Glama detected each change.

  1. 3 tool updatesv0.1.0
    • First observedlanhu_get_design_context
    • First observedlanhu_list_project_images
    • First observedlanhu_parse_url
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: one generates context files, one lists images (read-only), and one parses URLs. No overlap.

Naming Consistency5/5

All tools follow the consistent pattern 'lanhu_verb_noun' with snake_case, using clear verbs (get, list, parse).

Tool Count4/5

3 tools is slightly on the low side but appropriate for a focused domain like Lanhu design integration; each tool earns its place.

Completeness3/5

Covers basic operations (parse, get context, list images) but lacks tools for individual image details or design updates, leaving notable gaps.

Maintenance

ActivityStale
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • codesign-mcp

    ccpopy
    A
    license
    A
    quality
    B
    maintenance
    Local MCP server for Tencent CoDesign sharing links, exposing artboards, layer specs, preview images, and exported slices to support design-to-code workflows.
    8
    224
    11
    MIT

  • figma-mcp

    chisanucha-suwan
    A
    license
    Not graded
    quality
    C
    maintenance
    Read-only Figma MCP server that enables design-to-code workflows by talking to the Figma REST API with a personal access token, for use with Claude Code and GitHub Copilot.
    2,160
    MIT

  • 蓝湖 Design Schema MCP

    andyjin5
    A
    license
    A
    quality
    C
    maintenance
    A read-only MCP server for reading and analyzing Lanhu (Blue Lake) design projects, providing tools to retrieve design lists, previews, node trees, schemas, and exportable resources.
    5
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Kforward/lanhu-mcp-codex'

If you have feedback or need assistance with the MCP directory API, please join our Discord server