Model Context Protocol (MCP)-сервер для платформы совместного дизайна Lanhu (蓝湖).
Дайте LLM-моделям и ИИ-ассистентам по программирова возможно напрямую просматривать артборды, извлекатно попиксельно точные CSS-свой ства и аерархии слоёв, а также скачиваемые экспортируемые ассеты — с нулевом расходом vision-токенов.
Когда вы реализуете UI-дизайн с помощью ИИ-агентов программирования (Claude, Cursor, Copilot, Antigravity и т.д.), передача скриншотов часто приводит к:
Высоким затратам токенов для vision-моделей
Непрецизион crashesному позиционированию, угаданным отступам and approximate colors
Галлюцинированным размерам шрифтов и межстрочным интервалам
Невозможности автоматически извлекать и скачивать SVG/изображения
Lanhu MCP Server преобразует структурированные спецификации Lanhu напрямую в типизированные деревья данных:
⚡ Ноль лишних vision-токенов: чистые структурированные JSON-данные вместо тяжёлых скриншотов.
📐 Попиксельная точность: точные границы слоёв (x, y, width, height), цвета (HEX/RGBA), типографика (fontSize, fontWeight, fontFamily, lineHeight), радиус скругления, заливки, границы и тени.
🎨 Умное извлечение ассетов: автоматически находит slice-ассеты, выдаёт прямые CDN-ссылки для скачивания и поддерживает конвертацию без потерь в современные форматы WebP или SVG.
Устойчивая аутентификация: постоянное управление сессией с автоматическим headless-обновлением токена через Playwright.
Related MCP server: lanhu-mcp-server
РазведКоманд и проектов: получайте команды, проектные файлы и легко ищите проекты по командам.
Просмотр артбордов: получайте список артбордов (screens), превью-миниатюры и ищите экраны по имени.
Глубокая аннотация слоёв: рекурсивно получайте полные деревья слоёв со всеми CSS/UI-свойствами.
Пайплайн ассетов: скачивайте SVG-векторы и растровые изображения прямо в локальную папку.
Автоматический хранитель сессии: headless-скрипт Playwright незаметно поддерживает сессию Lanhu в фоне без постоянных ручных входов.
Python: >= 3.10
Менеджер пакетов: uv (настоятельно рекомендуется)
MCP-клиент: Cursor, Claude Desktop, Claude Code, Antigravity, Windsurf, Cline, Codex, VS Code или любой другой совместимый с MCP инструмент.
uvx (без установки)Вы можете запустить lanhu-mcp напрямую, без клонирования репозитория:
uvx --from git+https://github.com/xinayida/lanhu-mcp.git lanhu-mcp# Clone the repository
git clone https://github.com/xinayida/lanhu-mcp.git
cd lanhu-mcp
# Sync environment and dependencies
uv sync
# Run the server (stdio mode)
uv run lanhu-mcpLanhu MCP подключается к lanhuapp.com с помощью cookie браузерной сессии. Данные читаются из ~/.lanhu/cookie (атрибуты файла 0600).
Запустите включённый в комплект скрипт автоматизации Playwright:
uv run scripts/refresh_cookie.pyЕсли вы уже вошли в систему: скрипт в headless-режиме проверяет сессию, обновляет токен и записывает ~/.lanhu/cookie.
Если сессия истекла: автоматически открывается окно Chrome для разового входа (код из SMS или пароль). После успешной аутентификации скрипт сохраняет сессию и закрывает браузер.
Совет для плановых задач: используйте флаг
--headless-onlyв cron-заданиях, чтобы периодически обновлять cookie без всплывающих окон:uv run scripts/refresh_cookie.py --headless-only
Вызовите MCP-инструмент напрямую в ИИ-чате:
lanhu_set_cookie(cookie="session=...; user_token=...")Чтобы получить cookie вручную:
Откройте lanhuapp.com в Chrome и откройте DevTools (F12).
Перейдите на вкладку Network, кликните любой запрос к lanhuapp.com.
В разделе Request Headers скопируйте полную строку Cookie, содержащую session и user_token.
Создайте .env в корне проекта или передайте LANHU_COOKIE:
cp .env.example .env
# Edit .env and set LANHU_COOKIE=session=...; user_token=...Добавьте lanhu-mcp в предпочитаемый MCP-клиент:
Перейдите в Cursor Settings → MCP → Add new MCP Server:
Name: lanhu
Type: command
Command:
uvx --from git+https://github.com/xinayida/lanhu-mcp.git lanhu-mcpИли настройте через ~/.cursor/mcp.json:
{
"mcpServers": {
"lanhu": {
"command": "uvx",
"args": ["--from", "git+https://github.com/xinayida/lanhu-mcp.git", "lanhu-mcp"]
}
}
}Добавьте в claude_desktop_config.json (macOS: ~/Library/Application Support/Claude/claude_desktop_config.json):
{
"mcpServers": {
"lanhu": {
"command": "uvx",
"args": ["--from", "git+https://github.com/xinayida/lanhu-mcp.git", "lanhu-mcp"]
}
}
}Используйте с помощью Claude Code CLI:
claude mcp add lanhu uvx --from git+https://github.com/xinayida/lanhu-mcp.git lanhu-mcpДобавьте в конфигурацию Antigravity или settings.json:
{
"mcpServers": {
"lanhu": {
"command": "uvx",
"args": ["--from", "git+https://github.com/xinayida/lanhu-mcp.git", "lanhu-mcp"]
}
}
}Добавьте в ~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"lanhu": {
"command": "uvx",
"args": ["--from", "git+https://github.com/xinayida/lanhu-mcp.git", "lanhu-mcp"]
}
}
}Добавьте в ваш cline_mcp_settings.json:
{
"mcpServers": {
"lanhu": {
"command": "uvx",
"args": ["--from", "git+https://github.com/xinayida/lanhu-mcp.git", "lanhu-mcp"],
"disabled": false,
"autoApprove": []
}
}
}Добавьте с использованием Codex CLI:
codex mcp add lanhu uvx "--from" "git+https://github.com/xinayida/lanhu-mcp.git" "lanhu-mcp"или отредактируйте ~/.codex/config.toml:
[mcp_servers.lanhu]
command = "uvx"
args = ["--from", "git+https://github.com/xinayida/lanhu-mcp.git", "lanhu-mcp"]Добавьте через MCP-расширение VS Codeы или в настройках:
{
"mcpServers": {
"lanhu": {
"command": "uvx",
"args": ["--from", "git+https://github.com/xinayida/lanhu-mcp.git", "lanhu-mcp"]
}
}
}Инструмент | Описание | Ключевые параметры |
| Задаёт cookie аутенти или screen, сохраняет в |
|
| Получает список команд пользователя (заодно выступает проверкой статуса аутентификации) | (нет) |
| Получает дизайн-проекты в конкретной команде |
|
| Ищет проекты в команде по ключевому слову |
|
| Перечисляет все артборды/экраны проекта с размерами и миниатюрами |
|
| Ищет артборды по ключевому слову |
|
| ⭐ Ключевой инструмент: получает полное дерево слоёв, CSS-стили, типографику и ассеты |
|
| Получает экспортируемые содержимое/иконки со ссылками для скачивания |
|
| Скачивает ассет на диск (поддерживает WebP без потерь / SVG / PNG) |
|
Попросите ИИ-агента реализовать ваш интерфейс по дизайну Lanhu:
User: "Please implement the checkout screen from our Lanhu project and download necessary icons."Андент выполнит следующее автономною цепочку:
graph LR
A[1. lanhu_get_teams] --> B[2. lanhu_get_projects]
B --> C[3. lanhu_get_screens]
C --> D[4. lanhu_get_annotations]
D --> E[5. Generate Code CSS/HTML/React/Flutter]
D --> F[6. lanhu_download_asset]# 1. Fetch team list
teams = lanhu_get_teams()
team_id = teams[0]["id"]
# 2. Get project list
projects = lanhu_get_projects(team_id=team_id)
project_id = projects[0]["id"]
# 3. Get artboards list
screens = lanhu_get_screens(project_id=project_id, team_id=team_id)
image_id = screens[0]["id"]
# 4. Extract full annotations
annotations = lanhu_get_annotations(
project_id=project_id,
image_id=image_id,
team_id=team_id
)
# 5. Download icons/slices
assets = lanhu_get_assets(project_id=project_id, image_id=image_id, team_id=team_id)
lanhu_download_asset(
asset_id=assets[0]["id"],
asset_name=assets[0]["name"],
download_url=assets[0]["download_url"],
format="webp" # or "svg"
)Вызов lanhu_get_annotations возвращает структурированный JSON:
{
"id": "651234567890abcdef",
"name": "Checkout Page",
"width": 375.0,
"height": 812.0,
"thumbnail_url": "https://...",
"layers": [
{
"id": "layer_01",
"name": "Submit Button",
"type": "rect",
"bounds": { "x": 16.0, "y": 740.0, "width": 343.0, "height": 48.0 },
"border_radius": 8.0,
"opacity": 1.0,
"visible": true,
"fills": [
{ "type": "color", "color": "#0066FF", "opacity": 1.0 }
],
"shadows": [
{ "x": 0.0, "y": 4.0, "blur": 12.0, "spread": 0.0, "color": "#0066FF33" }
],
"children": [
{
"id": "layer_02",
"name": "Button Label",
"type": "text",
"text": "Confirm & Pay",
"bounds": { "x": 140.0, "y": 754.0, "width": 95.0, "height": 20.0 },
"font": {
"size": 16.0,
"weight": "600",
"family": "PingFang SC",
"line_height": 20.0,
"letter_spacing": 0.0,
"color": "#FFFFFF",
"text_align": "center"
}
}
]
}
],
"assets": [
{
"id": "asset_01:svg",
"name": "icon_cart",
"format": "svg",
"download_url": "https://..."
}
]
}Переменная | По умолчанию | Описание |
| (пусто) | Резервная строка cookie (fallback) ( |
|
| Директория, куда сохраняются скачанные ассеты |
|
| Время ожидания HTTP -запроса к API в секундах |
|
| Уровень логирования ( |
Этот проект — независимый инструмент с открытым исходным кодом, созданный в образовательных, тестовых и исследовательских целях продуктивности ИИ. Он взаимодействует с Lanhu через реверс-инженерные веб-интерфейсы. Пожалуйста, соблюдайте Условия использования Lanhu при работе с этим инструментом. Авторы не несут ответственности за неправомерное использование.
Проект распространяется по лицензии MIT.
下载指定的切图/图标到本地文件（位图默认自动转为 WebP 格式），返回保存路径。
需要先调用 lanhu_get_assets 获取资源的 download_url 等信息。
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | 文件格式：webp/svg/png（位图切图默认推荐 webp） | webp |
| asset_id | Yes | 资源 ID（从 lanhu_get_assets 获取） | |
| save_dir | No | 保存目录（可选，默认 ~/Downloads/lanhu_assets） | |
| asset_name | Yes | 资源名称，用作文件名 | |
| download_url | Yes | 下载链接（从 lanhu_get_assets 获取） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the burden of behavioral disclosure. It does so by stating that the tool writes to a local file, converts bitmap assets to WebP by default, returns a saved path, and depends on a prior lanhu_get_assets call. It does not mention overwrite behavior or cookie/authentication requirements, which keeps it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is two short sentences with no filler: the first packs action, conversion, and return value; the second gives the prerequisite. Both sentences earn their place and the key behavior is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple download tool with no output schema, the description covers the core return value and the mandatory upstream call, and the schema covers parameter semantics. Minor gaps remain around whether the save directory is auto-created and whether authenticated cookies are required, so it is complete but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter already has semantic documentation; the baseline is 3. The description only reinforces that download_url comes from lanhu_get_assets and restates the WebP default, adding no schema-independent parameter detail such as directory-creation or naming behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a concrete verb and resource ('download specified cutout/icon to local file') and names the outcome (returns the saved path). It also notes the WebP conversion, making the tool's purpose unmistakable and distinguishing it from sibling listing tools like lanhu_get_assets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to call lanhu_get_assets first to obtain download_url and other required asset information, which gives clear invocation sequencing. It does not explicitly state when not to use the tool or name alternative download paths, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取单张设计图的完整标注数据（最核心的工具）。
返回内容包含：
所有图层的树形结构（位置、尺寸、颜色、字体、行高、圆角、阴影、边框等）
文本图层的文字内容与字体样式
可下载的切图/图标列表（含 download_url）
画板尺寸与缩略图
| Name | Required | Description | Default |
|---|---|---|---|
| team_id | Yes | 团队 ID | |
| image_id | Yes | 设计图 ID（从 lanhu_get_screens 获取） | |
| project_id | Yes | 项目 ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
无注解，描述承担全部责任。它列出了返回内容（树形结构、切图列表、画板尺寸等），提供了行为信息，但未明确是否只读、是否需要认证、失败时返回什么、是否有速率限制。'获取'暗示读取操作，但未明确确认。返回内容细节是积极因素，但覆盖面有限。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
描述使用一个短句和列表高效传递关键信息，避免冗余。返回内容分类清晰，结构良好。未超长，语言精炼。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
考虑到工具复杂性（无输出schema），描述详细列出了返回的内容类别，涵盖主要使用所需信息。虽然未提及认证或错误处理，但兄弟工具中有lanhu_set_cookie，且参数描述已提示image_id来源，整体信息足以支持正确调用。欠缺的是使用场景和前提，但描述已相当完整。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
输入schema中所有参数都有中文描述，覆盖率达100%，描述未额外解释参数含义，符合基线（schema已承担解释重任）。没有需要补偿的缺口，因此3分合适。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
描述明确说明工具用途：获取单张设计图的完整标注数据，并详细列出了返回内容（图层树、文本、切图、画板尺寸），清晰区分于兄弟工具（如获取屏幕列表或资产）。动词'获取'配合'设计图标注数据'，资源具体。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
描述声称是'最核心的工具'，但未明确指明何时使用它而非兄弟工具，也未提及前置步骤（如先获取团队/项目/屏幕ID）。没有排除用途或替代方案。参数描述中提供了一些来源信息，但描述本身未强化使用场景。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取设计图中所有可下载的切图/图标资源列表（含 svg/png 直链）。
| Name | Required | Description | Default |
|---|---|---|---|
| team_id | Yes | 团队 ID | |
| image_id | Yes | 设计图 ID | |
| project_id | Yes | 项目 ID |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
没有提供任何注解，描述承担全部行为披露责任。它说明了返回的是可下载资源列表并包含直链，但对返回的格式、是否涉及认证、是否分页或限流等行为细节未作说明。虽然不矛盾，但信息有限，且没有注解补充，因此只能给予中等分数。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
描述仅一句话，简洁明了，没有冗余。'所有可下载'和'svg/png 直链'这两个关键信息放在前半部分，符合前置要求。虽然缺少使用指南，但从简洁性角度看，句子组织高效。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
工具较为简单，参数均有 schema 描述，且存在输出 schema，因此描述无需解释返回字段。但描述未提供任何使用上下文，如调用时机或与下载工具的关系，使得代理难以判断何时使用。整体而言，描述刚好覆盖核心功能，但缺少重要的使用指引，因此给出中等分数。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
输入 schema 对所有三个必填参数提供了中文描述（团队 ID、设计图 ID、项目 ID），覆盖率 100%。描述文本未增加任何额外参数含义，因此依据标准，当 schema 已充分覆盖时，基础分为 3 是合适的。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
描述明确说明工具的功能是获取设计图中所有可下载的切图/图标资源列表，并指出包含 svg/png 直链。动词'获取'和资源'资源列表'清晰，与兄弟工具中的下载工具（lanhu_download_asset）形成区分，但没有直接说明区别，因此未达到满分。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
描述没有提供任何使用指南，比如何时使用此工具而非下载工具、是否需要先设置 cookie 或获得授权等。没有提及前置条件或替代方案，代理只能凭名称和描述猜测。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取团队下的设计项目列表。
| Name | Required | Description | Default |
|---|---|---|---|
| team_id | Yes | 团队 ID（从 lanhu_get_teams 获取） |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the action (get a list) without disclosing any behavioral traits such as pagination, ordering, or potential empty results. It does not go beyond the basic action, leaving the agent uninformed about call behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the purpose and scope. There is no wasted verbiage, and the essential dependency hint is embedded efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is simple (one parameter, has output schema), the description is minimally sufficient. However, it omits mention of potential pagination, result limits, or error cases, and the dependency on a prior call is only hinted at in the schema, not in the main description. This leaves minor gaps for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema already explains team_id with the same '从 lanhu_get_teams 获取' note. The description adds no additional meaning beyond what the schema provides, so it meets the baseline for a well-covered parameter but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb '获取' (get) and the resource '设计项目列表' (design project list) scoped to a team. It distinguishes from lanhu_get_teams (which returns teams) but does not explicitly contrast with lanhu_search_projects, so it meets the clarity bar without full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a prerequisite hint by stating '从 lanhu_get_teams 获取' (obtained from lanhu_get_teams) for the team_id parameter, implying a dependency on that sibling tool. However, it does not offer explicit when-to-use versus lanhu_search_projects or any exclusions, leaving usage context partially implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取指定项目下的所有设计图（画板）列表，返回缩略图与尺寸信息。
| Name | Required | Description | Default |
|---|---|---|---|
| team_id | Yes | 团队 ID | |
| project_id | Yes | 项目 ID（从 lanhu_get_projects 获取） |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the tool returns thumbnails and size information, which indicates a read operation. However, it does not explicitly state that it is read-only, any authentication requirements, pagination behavior, or error conditions. As a simple get-list operation, the basic transparency is adequate 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that states the action, scope, and return value without any filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with two documented parameters and an output schema, the description is nearly complete. It states what is returned, and the schema covers parameter origins. Minor omissions like pagination or result limits are not critical for this low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters documented. The description itself adds no additional parameter details beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb '获取' (get) the list of all design images/artboards under a specified project, and specifies the returned data (thumbnail and size). It distinguishes itself from sibling tools by focusing on screens/artboards, not teams, projects, annotations, or assets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives, nor exclusions. The schema hints that project_id comes from lanhu_get_projects, implying a prerequisite flow, but the description itself does not mention this. Usage is therefore only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取当前登录用户所在的团队列表。也可用于验证认证是否有效。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It mentions a secondary behavior (auth validation), which hints at failure on invalid authentication. However, it does not specify prerequisites (e.g., setting a cookie via a sibling tool) or the exact behavior when authentication fails, and it does not explicitly state read-only semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences that front-load the primary purpose and append a useful secondary use. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless getter, the description covers the core function and an extra use case. An output schema is present, so return values need not be described. The only minor gap is not stating that authentication must be configured first, but the auth-validation hint partially addresses this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description has nothing to explain about parameter meaning. The baseline for 0-parameter tools is 4, and the description adds no unnecessary parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('获取' / get) and resource ('团队列表' / team list) for the current logged-in user, and adds a secondary purpose (verifying authentication validity). This clearly distinguishes it from sibling tools that operate on projects, screens, or assets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly indicates when to use it (list teams and check auth validity), which is clear context. It does not explicitly name alternatives, but sibling tools target different resources, so the usage scenario is unambiguous without exclusion statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
在指定项目中按名称关键词搜索设计图。
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | 搜索关键词 | |
| team_id | Yes | 团队 ID | |
| project_id | Yes | 项目 ID |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral characteristics. However, it only states the search intent and gives no indication of whether the operation is read-only, whether it requires prior cookie setup (e.g., lanhu_set_cookie), or any limits such as pagination or response size. The existing output schema is present but not referenced, so the description carries an insufficient burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that conveys the core purpose without redundancy. It is front-loaded with the action and resource. While it is minimal, it is appropriately concise for a straightforward search operation, though it could have been slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with three required parameters and a known output schema, so the description does not need to detail return values. However, because there are no annotations and no usage guidance, the description lacks the context an agent needs to decide when to invoke it and what to expect in terms of behavior (e.g., read-only nature, prior authentication via lanhu_set_cookie). The existing schema covers parameter definitions but not operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for all three parameters (keyword, team_id, project_id) at 100% coverage, so the baseline is 3. The description does not add any specific semantic detail beyond what the schema already provides, but that is acceptable given the coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (search) and the resource (design images) with a scoping condition ('in the specified project') and the search criterion (by name keyword). It is specific enough to distinguish from sibling tools like lanhu_search_projects, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to use this tool versus alternatives. The description does not state conditions, prerequisites, or mention other search tools like lanhu_search_projects. The agent is left to infer context from the sibling list, which is not dependable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
在团队下按名称关键词搜索项目。
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | 搜索关键词 | |
| team_id | Yes | 团队 ID（从 lanhu_get_teams 获取） |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
没有提供注释，因此描述承担全部行为披露责任。描述仅说‘按名称关键词搜索’，但未透露搜索是否匹配子串、是否分页、返回数量限制、是否可能无结果或失败模式等。对于一个搜索工具，缺少这些行为细节可能让代理产生错误预期。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
一行简洁的描述，直接陈述核心功能，无冗余信息。信息前置且易于理解。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
工具简单且有输出模式，但缺少关于搜索行为（如大小写、模糊性、结果排序）的说明。对于基本使用可能足够，但未覆盖所有代理可能需要的执行细节，尤其没有注释的情况下。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
输入模式覆盖率为100%，两个参数均有说明。描述中‘按名称关键词’重复了 keyword 参数的含义，但未增添新语义。由于模式已完整，基线为3，描述未提供额外价值。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
描述明确说明了工具的作用：在团队下（team_id）按名称关键词（keyword）搜索项目。动词具体（搜索），对象清楚（项目），且与兄弟工具（如 lanhu_get_projects）区分明确。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
描述未提供任何使用场景或与其他工具的对比。未说明何时用搜索而非获取项目列表，也未提及排除条件或前置要求。虽然参数架构中提及 team_id 来自 lanhu_get_teams，但这不算是使用指南，仅是参数说明。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
设置蓝湖认证 Cookie（并持久化到 ~/.lanhu/cookie）。
一般无需手动调用：Cookie 文件由 scripts/refresh_cookie.py 自动维护， MCP 启动时自动读取。仅在自动刷新不可用时，才需要从浏览器手动复制： DevTools → Network → 任一 lanhuapp.com 请求 → Request Headers → 复制完整 Cookie 头（须含 session 和 user_token）→ 传给本工具。 设置后可调用 lanhu_get_teams 验证是否生效。
| Name | Required | Description | Default |
|---|---|---|---|
| cookie | Yes | 浏览器 Cookie 字符串，必须包含 session 和 user_token 两项，例如: session=.eJy...; user_token=eyJ... |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden, and it delivers: it discloses that the cookie is persisted to ~/.lanhu/cookie, that scripts/refresh_cookie.py auto-maintains the file, and that MCP reads it at startup. It also tells the agent that the cookie must contain session and user_token and that verification via lanhu_get_teams is recommended. It does not explicitly state failure behavior or overwriting semantics, but the main side effect (persistence) is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is split into clear sections: purpose, default state, fallback trigger, copy steps, and verification. While slightly long, each sentence serves a purpose for a manual fallback tool; the key constraint (only when auto-refresh fails) is front-loaded. No filler words or tautology.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple one-parameter setter with no output schema or annotations, and the description covers its role, the condition for use, parameter source, and a verification step. It omits explicit return-value or error-handling details, but for setting a cookie the operational context is sufficiently complete. The reference to lanhu_get_teams closes the feedback loop.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; the cookie parameter is already described as a browser Cookie string that must contain session and user_token with an example. The description merely repeats the requirement and adds sourcing instructions (DevTools → Network), which is procedural guidance rather than new semantic parameter meaning. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: '设置蓝湖认证 Cookie' (set Lanhu authentication cookie) and specifies persistence to ~/.lanhu/cookie. The verb and resource are specific, and it is self-evidently distinct from all sibling getters/search tools. It also frames the tool as a fallback, which helps disambiguate its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says '一般无需手动调用' (generally no need to call manually) and defines the exact condition for use: '仅在自动刷新不可用时' (only when auto-refresh is unavailable). It provides concrete browser-copy steps and recommends calling lanhu_get_teams to verify, giving the agent a clear when-to-use and post-condition check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0lanhu_download_assetlanhu_get_annotationslanhu_get_assetslanhu_get_projectslanhu_get_screenslanhu_get_teamslanhu_search_imageslanhu_search_projectslanhu_set_cookieScored across 9 tools
Several tools have overlapping retrieval surfaces: get_projects vs search_projects and get_screens vs search_images are list-vs-search pairs, and get_annotations already includes downloadable assets that get_assets re-exposes. Descriptions clarify the intended use, but an agent could still select a broader tool when a narrower one is needed.
All tools share the lanhu_ prefix and follow a consistent verb_noun snake_case pattern (set_, get_, search_, download_), with no mixed conventions or vague generic names.
9 tools is well-scoped for a design-handoff/annotation server: auth, team/project navigation, screen listing, annotation retrieval, and asset download each have a focused tool.
The read-only workflow is well covered: authenticate, navigate teams/projects/screens, fetch annotations, and download assets. Minor gaps such as no direct get-by-id for a single project/screen (relying on list/search) and the redundant asset list inside get_annotations keep it from a perfect score.
Serves your design system and coding standards to coding agents, so they stop guessing.
Search 700+ design layers and fetch the build prompt for HTML, Next.js, React, Vue and more.
Give your AI agents a design superpower. Generate, edit, and publish publication-grade decks, reports, landing pages, resumes, and marketing visuals directly within your agent workflow. Delivering frontier-level design quality at 3× the speed and 53× lower cost -from conversational prompt to live link or vector PDF in minutes.
UI design from prompts, screenshots, and URLs for AI coding agents and theme tokens.
