Skip to main content
Glama
isolamenter

Lanhu MCP

by isolamenter
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Lanhu MCP 0.2

简体中文

Lanhu MCP is a local, Unity-only MCP server that converts a Lanhu design page into a validated Packet v1, a Unity Plan v1, and an experimental staged UGUI Prefab YAML snapshot.

IMPORTANT

The current renderer writes Unity YAML directly; it does not run the Unity Editor. Static verification is required but does not prove that the project compiles, imports without Missing Scripts, or visually matches Lanhu. Complete theUnity acceptance checks before treating generated output as production-ready.

What it supports

  • Unity 2022.3 LTS and Unity 6 LTS.

  • UGUI hierarchy and presentation components: GameObject, RectTransform, CanvasRenderer, Image, Text, masks, layout groups, LayoutElement, Outline, Shadow, and CanvasGroup.

  • Conservative best-effort inference for Button, Slider, Toggle, ToggleGroup, InputField, Dropdown, ScrollRect, and Scrollbar.

  • Downloaded sprites, deterministic .meta files, a Prefab Source Map, and an ownership manifest.

Semantic inference is not business-logic restoration. Review inferred component bindings in Unity. No C# Unity Editor importer is shipped in 0.2; the current Direct YAML path is best suited to inspectable snapshots, diffs, and pre-generation.

Related MCP server: lanhu-mcp-server

Requirements

  • Python 3.10 or newer.

  • A Lanhu session Cookie for private projects; some DDS sources may require a separate DDS Cookie.

  • A Unity project whose root contains both Assets/ and ProjectSettings/.

  • Unity's built-in UGUI package; editable text uses UnityEngine.UI.Text and the built-in Arial font by default.

Install and run

From a source checkout:

python3 -m venv .venv
.venv/bin/pip install -e .
cp .env.example .env
.venv/bin/lanhu-mcp

HTTP mode is loopback-only and listens at http://127.0.0.1:8126/mcp by default. This server has no remote authentication and must not be exposed to the internet.

For a stdio MCP client, point the client at the absolute path to run-stdio.sh. A typical MCP client entry is:

{
  "mcpServers": {
    "lanhu": {
      "command": "/absolute/path/to/lanhu-mcp/run-stdio.sh"
    }
  }
}

Client configuration keys vary by MCP host. The equivalent command is:

MCP_TRANSPORT=stdio /absolute/path/to/lanhu-mcp/.venv/bin/python -m lanhu_mcp

Configuration

Copy .env.example to .env. For an authorized Lanhu browser session, set the complete request Cookie header value; do not commit or share it. DDS_COOKIE is separate and never inherits LANHU_COOKIE.

Variable

Default

Purpose

LANHU_COOKIE

empty

Cookie sent only to the configured Lanhu host and subdomains.

DDS_COOKIE

empty

Optional Cookie sent only to the configured DDS host and subdomains.

DATA_DIR

./data

Managed Packet and downloaded-asset cache.

HTTP_TIMEOUT

30

Positive request timeout in seconds.

SERVER_HOST

127.0.0.1

HTTP bind host; only loopback addresses are accepted.

SERVER_PORT

8126

HTTP port.

MCP_TRANSPORT

http

http or stdio.

MAX_NODES_PER_RESPONSE

200

Maximum node count for a full response.

MAX_ASSET_BYTES

52428800

Maximum bytes per downloaded asset.

MAX_PACKET_ASSET_BYTES

524288000

Maximum aggregate downloaded bytes per Packet.

ASSET_DOWNLOAD_CONCURRENCY

4

Download workers, from 1 to 16.

HTTP_RETRIES

3

Retry count, from 0 to 3.

UNITY_TEXT_FONT_GUID

empty

Optional default UGUI Font GUID from an imported .ttf/.otf.

UNITY_TEXT_FONT_MAP_JSON

empty

Optional inline source-font-name to UGUI Font GUID map.

UNITY_TEXT_FONT_MAP_PATH

empty

Optional path to a UTF-8 UGUI font map JSON file.

LANHU_BASE_URL and DDS_BASE_URL are advanced HTTPS-only endpoint overrides. Process environment variables take precedence over .env; restart the MCP process after changing configuration.

The server intentionally clears DATA_DIR/packets and DATA_DIR/assets on startup. A packet_id and its downloaded files are therefore valid only for the current server process; call lanhu_prepare_design again after a restart.

Prepare Unity text

Editable UnityEngine.UI.Text output is enabled by default. During generation, Lanhu MCP scans the target project's Assets/ tree for .ttf/.otf files and matches normalized source names in this order: family + style/weight, then family. The matched font's .meta GUID is written internally as m_Font with fileID 12800000; users do not need to configure GUIDs for normal name-based matching.

Explicit text_font_map_json or UNITY_TEXT_FONT_MAP_* values override automatic matches, and text_font_guid/UNITY_TEXT_FONT_GUID supplies a default. These GUIDs must reference imported .ttf/.otf files, not TMP .asset files. Ambiguous or unmatched names produce warnings; unmatched text falls back to built-in Arial. Set use_text_components=false only when intentionally choosing visual-only rasterized text output.

Quick start workflow

The examples below show MCP tool payloads, not shell commands.

1. List designs

{
  "url": "https://lanhuapp.com/web/#/item/project/product?..."
}

Call lanhu_list_designs, then select a design by exact name, unique partial name, zero-based list index, or the image_id already present in the URL.

2. Prepare and download

Call lanhu_prepare_design:

{
  "url": "https://lanhuapp.com/web/#/item/project/product?...",
  "design": "Home",
  "force_refresh": false
}

Keep the returned packet_id. This step fetches sources, normalizes nodes, downloads assets into the managed cache, validates the Packet, and records partial download failures as warnings.

3. Inspect readiness

Call lanhu_inspect_design before writing Unity files:

{
  "packet_id": "0123456789abcdef0123",
  "view": "summary"
}

Review unity_readiness.status, blockers, review_items, missing assets, and missing font mappings. Use view="unity_plan" to inspect the exact creation/component plan, view="assets" for download state, and view="slices" for Sprite candidates.

4. Generate the Prefab snapshot

{
  "packet_id": "0123456789abcdef0123",
  "unity_project_path": "/absolute/path/to/UnityProject",
  "overwrite": false,
  "prefab_visual_mode": "layered",
  "use_text_components": true,
  "component_policy": "conservative"
}

The Unity project path must be the project root, not its Assets/ directory.

5. Verify generated files

Generation runs a staged static verification automatically. It also returns prefab_asset_path and source_map_asset_path, which can be checked again with lanhu_verify_unity_prefab:

{
  "unity_project_path": "/absolute/path/to/UnityProject",
  "prefab_asset_path": "Assets/LanhuMCP/Home/Prefabs/01234567_ViewRoot.prefab",
  "source_map_asset_path": "Assets/LanhuMCP/Home/Prefabs/01234567_ViewRoot.design-to-unity.json"
}

pass_with_warnings requires review; it is not the same as production acceptance.

Tool reference

lanhu_list_designs

Parameter

Required

Default

Description

url

Yes

—

Lanhu project URL containing pid/project_id.

lanhu_prepare_design

Parameter

Required

Default

Description

url

Yes

—

Lanhu project URL.

design

No

null

Name, unique partial name, list index, or URL image_id.

force_refresh

No

false

Bypass an intact same-version cache in the current process.

lanhu_inspect_design

Parameter

Required

Default

Description

packet_id

Yes

—

ID returned by prepare.

view

No

summary

summary, full, tree, nodes, assets, slices, unity_profile, or unity_plan.

node_ids

For nodes

null

One node ID or a list of IDs.

max_depth

No

3

Tree depth, clamped to 0–20.

include_style

No

true

Include style/text fields in tree output.

include_reference

No

false

Include the whole-design reference in slices/plan output.

component_policy

No

conservative

conservative or structure_only for the Unity Plan.

lanhu_generate_unity_prefab

Parameter

Required

Default

Description

packet_id

Yes

—

Prepared Packet ID.

unity_project_path

Yes

—

Unity root containing Assets/ and ProjectSettings/.

asset_root

No

Assets/LanhuMCP

Generated directory below Assets/.

prefab_name

No

<packet-prefix>_ViewRoot

Optional generated Prefab name.

overwrite

No

false

Replace only paths owned by the same Packet manifest.

include_reference

No

false

Copy/include the whole-design reference asset.

use_text_components

No

true

Generate editable UnityEngine.UI.Text; false explicitly chooses rasterized text.

component_policy

No

conservative

conservative or structure_only.

prefab_visual_mode

No

layered

layered or flattened_reference_overlay.

text_font_guid

No

empty

Optional default UGUI Font GUID from an imported .ttf/.otf.

text_font_map_json

No

configured/empty

Optional source-font-name to UGUI Font GUID mapping; overrides automatic name matches.

lanhu_verify_unity_prefab

Parameter

Required

Default

Description

unity_project_path

Yes

—

Unity project root.

prefab_asset_path

Yes

—

Prefab path beginning with Assets/.

source_map_asset_path

No

adjacent derived name

Source Map path beginning with Assets/.

Every tool response includes api_version: "0.2" and an envelope status. Expected failures use {code, message, details, retryable}. A successful envelope may still contain a domain result_status, readiness blockers, generation warnings, or verification status pass_with_warnings; inspect those fields before continuing.

Rendering and overwrite policies

Visual modes

  • layered is the default editable output. Recognized and downloaded source assets are copied into Sprites/ and bound to layer Image components.

  • flattened_reference_overlay uses the whole-design reference image as the visible baseline. It deliberately suppresses normal source-layer visuals while retaining hierarchy, metadata, and transparent interaction overlays. It requires a usable design.reference_asset_ref; if that reference download is missing or failed, do not use this mode.

include_reference=true copies the whole-design reference; it does not control whether normal slices are downloaded or imported.

Component policies

  • conservative emits inferred interactive components only when confidence is at least 0.8, no semantic review is required, and all required serialized references are available.

  • structure_only emits hierarchy and presentation components without inferred interaction.

Overwrite safety and limitation

Output is built in staging, statically verified, and transactionally committed. overwrite=false rejects collisions. overwrite=true can replace only files listed in the same Packet's ownership manifest; failures restore replaced files, and historical orphans are reported rather than deleted.

WARNING

Ownership protection prevents overwriting unrelated files, but it does not merge edits inside an owned generated Prefab. Direct YAML performs a full snapshot regeneration. Withoverwrite=true, scripts, UnityEvents, animations, extra children, and manual field changes added directly to the generated Prefab may be lost. Keep custom behavior outside the generated Prefab or preserve it manually until an Editor-based incremental importer exists.

Generated output

With the default asset_root, output resembles:

Assets/LanhuMCP/<design-name>/
├── Sprites/
│   ├── <generated images>
│   └── <generated image .meta files>
├── Prefabs/
│   ├── <name>.prefab
│   ├── <name>.prefab.meta
│   ├── <name>.design-to-unity.json
│   └── <name>.design-to-unity.json.meta
└── lanhu-mcp-manifest.json

  • The Source Map records source node IDs, Unity fileIDs, assets, component counts, policies, and expected import gates.

  • The ownership manifest records the Packet owner and SHA-256 of every generated file; do not delete it if you intend to use overwrite=true later.

Unity acceptance checks

Static status means:

  • pass: no static YAML/schema/reference problem was found.

  • pass_with_warnings: files are structurally usable but listed bindings or resources require review.

  • fail: regenerate or fix the reported files/references before Unity import.

After a static pass or reviewed pass_with_warnings:

  1. Open/refresh the project in the matching supported Unity Editor.

  2. Confirm the project compiles and the Console has no relevant import errors.

  3. Open the Prefab and check for Missing Scripts.

  4. Confirm generated textures import as Sprites and the Source Map imports as a TextAsset.

  5. Review UGUI Text font appearance and inferred Slider, Toggle, InputField, Dropdown, ScrollRect, Scrollbar, mask, and layout bindings.

  6. Capture a Prefab/GameView screenshot and compare it with the Lanhu reference.

Static verification cannot replace these steps.

Troubleshooting

Symptom/code

Meaning and action

output_collision

A target already exists. Inspect its owner; use overwrite=true only when intentionally replacing output owned by the same Packet.

packet_asset_missing

The prepared Packet points outside or no longer has its managed cached asset. Prepare the design again in the current server process.

missing_asset / unresolved assets

Inspect view="assets"; refresh the Packet and resolve download/export failures before generation.

ugui_text_font_match_ambiguous

Multiple .ttf/.otf files matched the same normalized source name; provide an explicit map or rename the files more precisely.

ugui_text_font_substitution

No project font matched the source name, so that text uses built-in Arial.

Empty/transparent output in flattened_reference_overlay

The mode suppresses layer visuals and depends on the reference image. Inspect the reference asset, or regenerate with layered.

Unsupported Unity version

Use Unity 2022.3 LTS or Unity 6 LTS; other versions are rejected before staging.

Static pass but broken Unity output

Static verification does not import or compile Unity. Run the full acceptance checklist above.

Data contracts and migration

Version 0.2 intentionally does not load or migrate legacy/unversioned Packets or Source Maps. Canonical JSON Schemas live in schemas/ and can be regenerated with:

python -m lanhu_mcp.schema_export schemas

See Security, Architecture, Data contracts, 0.2 migration, Unity support, and the Changelog.

Development

uv sync --extra dev
.venv/bin/ruff check src tests
.venv/bin/mypy src/lanhu_mcp
.venv/bin/pytest

License

MIT

Available Tools

5 tools
lanhu_generate_unity_prefabC

Generate a staged, verified UGUI prefab snapshot for a supported Unity LTS project.

ParametersJSON Schema
NameRequiredDescriptionDefault
overwriteNoReplace files owned by the same packet manifest.
packet_idYesPacket id returned by lanhu_prepare_design.
asset_rootNoGenerated asset directory below Assets/.Assets/LanhuMCP
prefab_nameNoOptional prefab name.
text_font_guidNoOptional default Unity Font guid from an imported .ttf/.otf asset.
component_policyNoInteractive component policy.conservative
include_referenceNoCopy and include the design reference asset.
prefab_visual_modeNoPrefab visual rendering strategy.layered
text_font_map_jsonNoOptional JSON source-font-name to Unity Font guid mapping.
unity_project_pathYesUnity project root containing Assets and ProjectSettings.
use_text_componentsNoUse editable UnityEngine.UI.Text nodes.

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description carries the full disclosure burden, but 'staged, verified' only hints at behavior without explaining what staging or verification entails. It fails to disclose that this tool writes files into the Unity project, including possible overwrites (evidenced by the overwrite parameter). An agent cannot anticipate side effects, Unity installation requirements, or execution traits.

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 13-word sentence front-loads the verb and core object with zero waste. Every qualifier ('staged,' 'verified,' 'supported Unity LTS') carries distinct meaning, and no sentence repeats schema or annotation content.

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?

For an 11-parameter tool that writes generated assets into a Unity project and belongs to a five-tool workflow, this description is thin. It omits workflow ordering, disk side effects, and what 'supported Unity LTS' actually means. The output schema covers return values, but the behavioral and workflow gaps leave an agent under-informed for a complex, mutating tool.

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 100%, so the baseline is 3 even without parameter detail in the description. The 'UGUI prefab' phrasing loosely contextualizes prefab_name and use_text_components, adding marginal meaning. The description adds no substantive parameter-level insight beyond what the schema already documents.

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 ('Generate') and resource ('UGUI prefab snapshot') with qualifiers ('staged, verified') that set output expectations. The verb differentiates it from siblings like list/prepare/verify/inspect. However, the 'verified' qualifier creates slight ambiguity with lanhu_verify_unity_prefab, stopping 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 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; no alternatives or exclusions are mentioned. 'For a supported Unity LTS project' hints at a prerequisite but doesn't explain workflow position relative to lanhu_prepare_design or lanhu_verify_unity_prefab. An agent must infer the workflow from the packet_id parameter description rather than the tool description.

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

lanhu_inspect_designA

Inspect a prepared design packet through a compact task-oriented view.

ParametersJSON Schema
NameRequiredDescriptionDefault
viewNoInformation view to return.summary
node_idsNoNode ids required by the nodes view.
max_depthNoMaximum hierarchy depth for tree view.
packet_idYesPacket id returned by lanhu_prepare_design.
include_styleNoInclude style/text fields in tree view.
component_policyNoInteractive component generation policy for Unity plan.conservative
include_referenceNoInclude the full design reference in slices or Unity plan.

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4/5.0
Behavior3/5

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

No annotations are provided, so the description carries the burden of behavioral disclosure. 'Inspect' implies a read-only operation, but the description does not explicitly state whether the packet is modified, what data is returned, or that different views may have different computation costs. It adds some context with 'compact task-oriented view' but little detail about side effects or behavior.

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, focused sentence with no redundant wording. It front-loads the core action and object, and every part contributes to the agent's understanding of the tool's purpose.

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?

Given that an output schema exists and all parameters are fully documented in the schema, the description does not need to explain return values or parameter details. The main gap is the lack of explicit guidance on when to use this tool versus list/prepare/generate, but the overall context from the schema and sibling names is sufficient for an agent to operate correctly.

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?

The input schema has 100% description coverage, with each parameter including a meaningful description and defaults/enums documented. The tool description itself adds no additional parameter semantics, so the baseline of 3 is appropriate.

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 uses the specific verb 'Inspect' with the resource 'prepared design packet' and 'compact task-oriented view', clearly distinguishing this tool from siblings like lanhu_prepare_design or lanhu_generate_unity_prefab. The scope is clear enough for an agent to know exactly what the tool does.

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

Usage Guidelines4/5

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

The phrase 'prepared design packet' and the packet_id schema description 'returned by lanhu_prepare_design' convey that this tool should be used after preparation. It does not explicitly enumerate when-not-to-use or name alternatives, but the inspection-vs-preparation/generation distinction is evident from sibling names.

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

lanhu_list_designsA

List the design pages available in a Lanhu project.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesLanhu project URL containing pid/project_id.

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.6/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'list', which implies a read-only operation, but it does not explicitly confirm read-only behavior, mention authentication requirements, or describe any potential side effects or return format. The output schema covers returns, but behavioral transparency beyond that is lacking.

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 verb and resource. Every word serves a purpose, and it is appropriately minimal for a simple tool.

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?

The tool is simple with one parameter fully described in the schema, and an output schema exists (not shown but indicated). The description adequately conveys what the tool does. It could mention that it returns a list of design pages, but that is implied and likely covered by the output schema. Minor gaps like authentication or edge cases 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.

Parameters3/5

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

The schema description covers the single parameter 'url' with a clear explanation ('Lanhu project URL containing pid/project_id'), achieving 100% coverage. The tool description adds no additional parameter information, so the baseline of 3 applies.

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 (list), the resource (design pages), and the context (a Lanhu project). It is easily distinguishable from siblings like lanhu_prepare_design or lanhu_inspect_design, which are about other operations.

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 usage context is implied: this tool lists design pages, while siblings handle other actions. However, the description does not explicitly state when to use this over alternatives or when not to use it. For a simple listing tool, this is acceptable but not exemplary.

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

lanhu_prepare_designB

Fetch, normalize, download, validate, and atomically store one Lanhu design.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesLanhu project URL containing pid/project_id.
designNoDesign name, unique partial name, list index, or null to use image_id from URL.
force_refreshNoBypass a complete same-version packet and asset cache.

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3.2/5.0
Behavior3/5

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. The description mentions several actions (fetch, normalize, download, validate, store) and hints at atomicity, which is valuable. However, it does not disclose potential side effects like cache updates, storage location, or whether it is a read-only or mutation operation. The description does not contradict annotations (since none exist), so a score of 3 is appropriate.

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

Conciseness4/5

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

The description is a concise single sentence, efficiently summarizing the tool's purpose and actions. It is front-loaded with the main verbs. However, it could be more structured to separate the core action from additional details, but it is still effective.

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

Completeness3/5

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

With an output schema present and high parameter coverage, the description covers the essential actions but misses important contextual information such as when to use it versus siblings, error cases, or prerequisites. The tool's complexity (multi-step pipeline) suggests that more detail could be beneficial, but the presence of an output schema mitigates the need for return value explanation.

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%, so the schema already documents all parameters. The description mentions 'atomic store' relevant to design but does not add extra semantics beyond what the schema provides for parameters. The description does not explain parameter interactions or provide examples, so it stays at baseline.

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?

The description clearly states the tool's action (fetch, normalize, download, validate, atomically store) and specific resource (Lanhu design), making it distinct from typical sibling tools. However, it does not explicitly differentiate itself from siblings like lanhu_inspect_design or lanhu_generate_unity_prefab, which might also involve fetching and processing designs.

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?

The description does not provide any guidance on when to use this tool versus alternatives such as lanhu_inspect_design or lanhu_generate_unity_prefab. There is no mention of prerequisites, use cases, or scenarios where this tool is preferred. The presence of a 'url' parameter gives some context, but it is insufficient.

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

lanhu_verify_unity_prefabB

Statically verify generated prefab YAML, ownership metadata, source map, sprites, and file ids.

ParametersJSON Schema
NameRequiredDescriptionDefault
prefab_asset_pathYesPrefab path below Assets/.
unity_project_pathYesUnity project root containing Assets and ProjectSettings.
source_map_asset_pathNoOptional source map path below Assets/.

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3.2/5.0
Behavior2/5

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

With no annotations provided, the description must fully disclose behavior. It says 'Statically verify,' which implies a non-mutating analysis, but it does not specify what checks are performed, whether any side effects exist, or what the output format is. The lack of detail is a significant gap for a tool with no annotation support.

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, tightly worded sentence that starts with the verb and immediately lists the verified items. There is no redundancy or filler, and every word contributes to the meaning.

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?

Despite having an output schema, the description is incomplete for a tool that verifies multiple artifacts. It does not explain the verification process, what constitutes success/failure, or the role of the optional source_map parameter. With no annotations, an agent lacks sufficient context to use the tool confidently.

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?

All three parameters have schema descriptions covering 100% of them, so the baseline is 3. The description does not add any parameter-level detail beyond the schema; it lists the verified artifacts but does not clarify how they map to the parameters or any constraints. Thus the description adds little value over the schema.

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 states a specific action ('verify') applied to a concrete set of artifacts (prefab YAML, ownership metadata, source map, sprites, file ids). This clearly distinguishes it from the sibling tools, especially lanhu_generate_unity_prefab, which would create rather than verify.

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?

The description offers no guidance on when to invoke this tool versus its siblings. It does not mention prerequisites (e.g., must be called after generation) or conditions for using the optional source map parameter. The workflow is implied by the sibling names but never stated.

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.

  1. 5 tool updatesv0.2.0
    • First observedlanhu_generate_unity_prefab
    • First observedlanhu_inspect_design
    • First observedlanhu_list_designs
    • First observedlanhu_prepare_design
    • First observedlanhu_verify_unity_prefab
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.7/5.0

Scored across 5 tools

Disambiguation5/5

Each tool maps to a distinct stage in the design-to-prefab pipeline: listing, preparing, inspecting, generating, and verifying. The overlap between list_designs and inspect_design is minimal because one targets project pages and the other targets prepared packets.

Naming Consistency5/5

All tools share the lanhu_ prefix and follow a consistent snake_case verb_noun pattern. The verbs list, prepare, inspect, generate, and verify clearly indicate the action while the nouns identify the target artifact.

Tool Count5/5

Five tools is well-scoped for a focused design-to-Unity-prefab workflow. Each tool has a clear purpose and no redundant operations clutter the surface.

Completeness5/5

The tool set covers the full lifecycle from discovering available designs, preparing and inspecting them, to generating and verifying a Unity prefab. There are no obvious dead ends or missing critical operations for the stated domain.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • lanhu-context-mcp

    refinist
    A
    license
    Not graded
    quality
    A
    maintenance
    Converts Lanhu design URLs into AI-ready implementation context including HTML+CSS (Tailwind), image downloads, design tokens, and guidance.
    284 npm
    44
    MIT

  • lanhu-mcp-server

    DC911360
    A
    license
    A
    quality
    B
    maintenance
    Enables AI coding tools to read Lanhu design data and automate Design to Code, including project browsing, layer tree extraction, DDS semantic components, and code generation.
    14
    83 npm
    3
    MIT

  • lanhu-ui

    revfanc
    A
    license
    B
    quality
    B
    maintenance
    Fetches Lanhu UI design specs and assets with minimal tokens, enabling coding agents to implement high-fidelity UI by providing precise coordinates, styles, and downloaded resources.
    2
    2
    MIT

  • Figma MCP

    isolamenter
    A
    license
    A
    quality
    C
    maintenance
    Converts Figma designs (frames, components, instances) into inspectable packets and static Unity UGUI YAML prefabs via the Figma REST API, enabling direct design-to-Unity asset generation.
    5
    MIT