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.

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.

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.

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.

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.

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.

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.

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.

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.