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

No annotations are provided, so the description carries the burden. It does disclose useful behavioral traits: it loads the plugin into the editor, continuously monitors the console until an error log appears, returns error content on error, and returns success if timeout is reached without error. It also mentions the .eext file location convention and the timeout parameter's default. However, it does not disclose side effects of loading a plugin (e.g., whether it opens a new editor tab, whether it modifies project state, whether repeated calls stack listeners). For a tool that executes a plugin, this is a meaningful gap. The description does not contradict annotations (there are none).

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 compact paragraph of 4 sentences. It front-loads the primary action and outcome, then provides file path guidance in the second sentence, usage scenario in the third, and timeout behavior in the fourth. Every sentence adds value. It could be slightly more structured (e.g., separating the file path hint from the main behavior), but it is efficient and not bloated. Minor deduction for the ambiguous construction '调试插件到嘉立创EDA' which could be misparsed.

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 this is a 3-param tool with no output schema, the description is reasonably complete: it states what it does, the file path convention, the timeout success condition, and the error-return behavior. It lacks details about the return format (exact error content structure) and whether the plugin is loaded once or reloaded each call, which could matter for repeated invocations. But overall it provides enough context for an agent to decide to call it and understand the outcome. Not a 5 because the ambiguity around the load-monitor lifecycle and return shape could lead to misuse.

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 baseline is 3. The description adds context for pluginPath by specifying the build/dist directory and .eext suffix, which goes beyond the schema's '插件文件的绝对路径' (absolute path to plugin file). It also mentions timeout default in the description but that's already in the schema. It does not add anything about browserPath beyond the schema's description. Given full schema coverage, a 3 is appropriate; the path convention hint is a small bonus but not enough to raise to 4.

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 a specific verb+resource: '调试插件到嘉立创EDA并持续监听控制台，直到出现 error 日志时返回错误内容' (debug plugin in JLC EDA and continuously monitor console, returning error content when error log appears). It distinguishes itself from siblings like import_plugin (which imports a plugin) and get_console_logs (which just retrieves logs) by specifying it loads and monitors for errors with timeout behavior. Some ambiguity remains in the term '调试插件' which could mean 'debug the plugin' or 'debug plugin (as a noun)', but the sentence structure and following details clarify it's about debugging a plugin by loading it and monitoring console output.

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 states it is '适用于需要自动捕获插件运行错误的调试场景' (suitable for debugging scenarios requiring automatic capture of plugin runtime errors). It gives a condition for when to use it. It does not explicitly state when NOT to use it or name alternatives (e.g., use get_console_logs for manual log retrieval, or import_plugin for simple loading without monitoring). However, the clear scenario description plus the file path precondition ('调用前请先确认 pluginPath 指向该目录下的 .eext 文件') provides practical usage guidance. Missing explicit exclusion of alternatives prevents 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?

With no annotations, the description carries the full behavioral disclosure burden. It does disclose one meaningful trait — the tool is a constrained bridge that rejects arbitrary code and only accepts auto-generated whitelist methods — which frames it as a safe, restricted dispatcher. However, it says nothing about validation failure behavior, error responses, or side effects, which matters for a no-annotation tool.

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?

Two short sentences with zero wasted words. The action is front-loaded first and the safety constraint follows immediately; every clause 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 generic dispatcher spanning a huge API catalog with no output schema and no annotations, the description is too thin. It never tells the agent where the whitelist comes from, how to discover valid method IDs, or what happens for an unlisted method; given that siblings like easyeda_api_catalog and easyeda_api_describe exist, the lack of any pointer to them is a genuine gap.

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 itself documents the parameters well (method format with a concrete example, args as a JSON array in official signature order, windowId defaulting to the active window). The description adds no parameter-specific information, so the baseline of 3 holds.

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 ('调用' / call) and resource ('目录内任一官方EasyEDA Pro API' — any official EasyEDA Pro API in the catalog), making it clear this is a generic API dispatcher. It is implicitly distinguished from the hundreds of specific sibling tools, which are the individual endpoints this tool invokes, though the relationship to those siblings is never made explicit.

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 gives no guidance on when to invoke this generic dispatcher versus the many dedicated sibling tools exposing the same APIs, nor does it point the agent to sibling discovery tools like easyeda_api_search or easyeda_api_catalog. The whitelist constraint ('仅允许自动生成白名单中的方法') is a restriction, not actionable usage guidance.

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 states it lists information, implying a read-only operation with no side effects. However, it doesn't describe the exact output format or any potential effects (e.g., requiring an active editor session). For a zero-parameter informational tool, this 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?

The description is a single, front-loaded sentence that conveys the essential purpose without any filler. It is concise and immediately understandable.

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 zero-parameter informational tool, the description is complete. It tells the agent what information is returned (version, namespaces, method counts). No output schema exists, but the description provides enough high-level context to decide whether to call it. It could specify the return structure but isn't necessary for a catalog 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?

There are zero parameters, so the baseline is 4. The description adds no parameter-specific details because none exist. It correctly states what the tool returns without needing to explain parameters.

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 purpose: to list the official EasyEDA Pro API version, namespaces, and method counts for the current package. This is a specific verb-resource combination that distinguishes it from siblings like easyeda_api_search and easyeda_api_call.

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 implies usage: call this tool when you need an overview of the API version and namespace structure. It doesn't explicitly mention alternatives or exclusions, but the purpose is so distinct that an agent can infer when to use it. Slight gap for not mentioning alternatives.

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 fully convey behavioral traits. It states the return content (signature, overloads, description) but does not mention side effects, authentication needs, error behavior (e.g., if the method ID is invalid), or whether it can be called anytime. The description is too sparse to inform an agent about edge cases or operational requirements.

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, succinct sentence that directly states the tool's functionality. There is no redundant information, and the key purpose is stated upfront. It is appropriately concise for a lookup tool.

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 a simple documentation lookup, the description communicates what it returns, which is generally sufficient. However, lacking an output schema, it does not describe the exact structure of the response (e.g., JSON format or fields), and it does not mention any conditions or limitations. For a tool with many siblings and subtle differences, more contextual guidance would be helpful.

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 input schema already provides a clear description for the 'method' parameter, including an example. The tool description itself does not add further parameter details. With 100% schema coverage, the baseline of 3 applies; the description only reinforces the schema's content without adding new semantics.

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?

Description clearly states the tool retrieves the complete signature, overloads, and description of an official EasyEDA Pro API method. It uses a specific verb (获取/get) and resource (API方法/API method), and differentiates from sibling tools like easyeda_api_call (which invokes) and easyeda_api_search (which searches for methods).

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 implies usage: if you need to understand a method's signature before calling it, this is the tool. However, it does not explicitly state when to use this over alternatives or mention any prerequisites. No exclusions are given, so an agent must infer the appropriate context.

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 should carry the burden. It mentions that omitting query lists methods in a namespace, which is a useful behavioral detail. However, it doesn't disclose pagination behavior, default limit behavior, or whether the search is case-insensitive. It adds some value but leaves gaps.

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 is front-loaded with the main purpose and search dimensions. No unnecessary words.

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 no output schema, and the schema covers parameters well. However, for a search tool, it would be useful to know if there are any response format details or limitations. The description is adequate but could clarify behavior like result ranking or filtering.

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 coverage is 100%, so the schema already describes all parameters. The description adds no additional parameter semantics beyond what's in the schema. Since coverage is high, 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 purpose: searching all official EasyEDA Pro APIs by method name, namespace, description, or parameter type. It specifies the resource (official APIs) and the action (search). It doesn't explicitly differentiate from sibling tools like easyeda_api_catalog or easyeda_api_describe, but the search aspect is distinct.

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 implies usage for finding API methods, but it doesn't explicitly state when to use this versus siblings like easyeda_api_catalog or easyeda_api_describe. The schema provides optional parameters that hint at use cases (e.g., query vs namespace), but no explicit guidance is given in the description.

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 alone must disclose behavioral traits. It only says 'check', implying a read-only operation, but does not state side effects, required permissions, or whether it could fail or time out. No information about the output or what 'status' means is provided.

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 sentence with no filler. It is front-loaded with the action and targets, making it easy to scan. 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?

The tool has no output schema, so the description should explain what the check returns or what status details are provided. It only says 'check', leaving the agent without expectations of the result format (e.g., boolean, details object). This is inadequate for a status-checking 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?

The tool has 0 parameters, so the schema provides full coverage. Baseline for 0-param tools is 4. The description does not need to explain parameters, and it does not add unnecessary 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 '检查 EasyEDA API Bridge 和当前连接的嘉立创EDA窗口' uses a specific verb (check) and names two concrete resources: the API Bridge and the currently connected JLC EDA window. This clearly distinguishes it from sibling tools like easyeda_api_call or easyeda_select_window, which perform different actions.

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 does not state when to use this tool versus alternatives. It provides no context about typical scenarios (e.g., diagnostics before calling other APIs) or when not to use it. The agent must infer its purpose from the name and minimal description.

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 states the tool selects a window for subsequent API calls, which implies a stateful side effect (changing the active window context). However, it doesn't disclose whether this is persistent, whether it affects other windows, whether it can be undone, or what happens if the windowId is invalid. For a state-changing tool with zero annotation coverage, this is a significant gap.

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 front-loads the condition ('当连接了多个嘉立创EDA窗口时') and states the action. It's efficient with no wasted words. It could arguably add a bit more behavioral detail, but for its length it's well-structured.

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?

This is a stateful selection tool with no annotations and no output schema. The description doesn't explain the return value, error behavior, or whether the selection persists across calls. Given the tool's role in routing subsequent API calls, an agent would benefit from knowing what happens after selection and how to verify it. The description is minimal and leaves these gaps.

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 the schema already documents the windowId parameter. The description adds the context that the windowId comes from easyeda_bridge_status, which is useful but not essential since the schema already says this. Baseline 3 is appropriate when the schema does the heavy lifting.

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 ('选择' = select) and resource ('窗口' = window), and clarifies the context (when multiple EasyEDA windows are connected). It clearly distinguishes this from the sibling easyeda_bridge_status, which presumably reports status, while this tool selects the active window for subsequent API calls. However, it doesn't explicitly name the sibling alternative, so it's clear but not fully differentiated.

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 implies when to use this tool: when multiple windows are connected and you need to choose which one subsequent API calls target. It doesn't explicitly state when not to use it or name alternatives like easyeda_bridge_status. The context is implied rather than explicit, so it's adequate but has gaps.

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?

Annotations are absent, so the description must carry the full burden. It discloses the return value (new board name or undefined on failure) but provides no information about side effects (e.g., whether the copy is deep or shallow), permissions required, or consequences of the operation. This is insufficient for a mutation tool.

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 extremely short (a signature and a phrase), which is concise, but it lacks structure and front-loading of key information. It mixes code and natural language without clear organization. It earns a middle score because it is brief, but not well-structured for an agent to parse 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?

The tool is simple (copy a board) and the schema covers parameters, but the description omits usage guidelines and behavioral details. There is no information about where the copy is placed, how to verify success beyond the return, or any prerequisites. An agent would be uncertain about how to correctly invoke this tool in practice.

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 description includes the signature with sourceBoardName, but does not explain how to map it to the args array or the windowId parameter. The schema descriptions for args and windowId are generic and do not specify the content for this tool. The description adds no practical meaning beyond the raw signature, and the schema already covers the parameters at 100% 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 states '复制板子' (copy board) and includes the function signature with the parameter name and return type. This clearly identifies the tool's purpose: to copy a board. It is distinguishable from siblings like create_board and delete_board, though it doesn't 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?

There is no guidance on when to use this tool versus other board operations (create, delete, modify). No prerequisites, target audience, or conditions for use are provided. The description simply states the action without context on when it's appropriate.

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?

Since annotations are entirely absent, the description carries the full burden. It does disclose the return value (board name) and the failure condition (undefined), which is useful. However, it does not describe side effects, whether an active document is required, how the optional UUIDs are used, or any potential preconditions. This is partial transparency, not complete.

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 compact, including the signature, Chinese phrase, and return explanation. It is front-loaded with the signature and clear about the output. Mixing English and Chinese is minor. It is efficient but not perfectly structured for an AI parser since it's prose-like.

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 create operation, the description offers the return type and failure indication but lacks context on prerequisites (e.g., active project/document), behavior when optional parameters are omitted, and any naming or collision considerations. The windowId parameter is only explained in the schema, not in the description. Overall, an agent could call it but may not understand the full 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 input schema only provides a generic 'args' array, so the description's signature (schematicUuid?: string, pcbUuid?: string) adds critical meaning about parameters and order. It compensates for the schema's lack of per-argument detail. However, it does not explain what these UUIDs represent or the effect of omitting them, leaving some semantic gap.

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 creates a board ('创建板子') and provides the exact method signature with parameter names and types. It is unambiguous and distinguishes itself from sibling tools like copy_board, delete_board, and modify_board_name by the action 'create'.

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 guidance on when to use this tool versus alternatives (e.g., when to create a new board vs. copy an existing one). No prerequisites are mentioned (e.g., needing an active project), and no exclusions are given. An agent is left to infer when creation is appropriate.

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?

The description discloses an important behavior: if the board does not exist, the call returns `false` instead of throwing, and the return value indicates success. However, with no annotations, it leaves gaps about side effects, irreversibility, and permissions, which are relevant to a destructive operation.

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 compact and front-loaded with the function signature, followed by a short Chinese explanation, a remark, and a return note. Some redundancy exists between the tool name, the signature, and the Chinese text, but the overall length is appropriate.

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 description explains the basic behavior and failure mode but omits important context such as how `boardName` is resolved (display name vs. UUID), the role of `windowId`, and any prerequisite or consequences beyond the boolean return. For a destructive tool with no annotations and no output schema, more context would be valuable.

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 description adds the actual parameter name and type `boardName: string` and return type `Promise<boolean>`, which the generic `args` schema does not name. This helps an agent understand what to put in the positional args array, beyond the schema's generic description.

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 and resource: 'dmt_Board.deleteBoard' and '删除板子' (delete board), making the operation clear. However, it does not explicitly contrast with sibling tools like create or copy board, so differentiation relies on the tool name rather than the description.

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 provided about when to use this tool versus alternatives, prerequisites, or conditions. The description does not mention scenarios, exclusions, or related tools for other resource types.

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 of behavioral disclosure. It states the return type (Promise<Array<IDMT_BoardItem>>) and that it returns an array of detailed properties, but it doesn't disclose whether this is a read-only operation, whether it requires an active project, what happens if no boards exist, or any side effects. For a getter with no annotations, this is a notable gap.

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 compact: a code signature line, a one-line Chinese summary, and a return-type note. It's front-loaded with the core purpose and has no filler. The bilingual mix is slightly redundant (the Chinese repeats the English signature), but it's still efficient and scannable.

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 getter with no output schema and no annotations, the description provides the essential purpose and return type. However, it lacks details about the structure of IDMT_BoardItem, whether the operation requires an open project, and how it differs from the sibling get_board_info/get_current_board_info. Given the tool's simplicity, this is adequate but not complete.

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 the schema already documents both parameters (args and windowId). The description adds no parameter-specific meaning beyond the schema, but the baseline of 3 applies because the schema covers the parameters fully. The description's mention of '工程内' (in the project) provides some context for the windowId parameter's scope, but not explicitly.

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 and resource: '获取工程内所有板子的详细属性' (get detailed properties of all boards in the project), which clearly identifies the tool's function. It distinguishes from siblings like eda_dmt_board_get_board_info and eda_dmt_board_get_current_board_info by the 'all boards' scope, though it doesn't explicitly name those 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?

The description implies usage context: it retrieves all boards' detailed properties in the project, which is distinct from single-board or current-board getters. However, it provides no explicit when-to-use guidance, no exclusions, and no mention of alternatives. The context is clear enough for an agent to infer when to use it, but it doesn't explicitly guide selection among siblings.

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 does state the return type (Promise<IDMT_BoardItem | undefined>) and that undefined means failure, which is some transparency. However, it does not disclose that this is a read-only operation, whether the board must already exist, or what properties are returned. For a tool with zero annotation coverage, this is insufficient behavioral disclosure.

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 extremely short – essentially a signature, a Chinese phrase, and a return note. It avoids fluff and conveys the core purpose efficiently. However, it is so brief that it omits potentially useful context, but conciseness itself is not penalized for being short; it earns a 4 for being to the point without wasted words.

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 getter with no output schema, the description covers the return type and the undefined failure case. It does not explain the role of windowId (though the schema covers it), whether the board must be open in the current window, or what specific properties are included. Given the tool's simplicity, it is minimally complete but leaves room for ambiguity about prerequisites and result content.

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 input schema has 100% description coverage, providing generic explanations for args and windowId. The tool description adds specific meaning by including the function signature 'dmt_Board.getBoardInfo(boardName: string)', which clarifies that the args array should contain a boardName string. This goes beyond the schema's generic 'JSON参数数组' and is valuable for constructing correct calls.

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 (获取板子的详细属性 – get board detailed properties) and the resource (板子/board). It includes the full function signature with parameter name, so an agent knows it retrieves info for a named board. However, it does not differentiate from sibling tools like eda_dmt_board_get_current_board_info or eda_dmt_board_get_all_boards_info, so it's not clear when to pick this over them.

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 guidance on when to use this tool versus alternatives. The description does not mention that this is for a specific board by name, nor does it exclude cases where get_current_board_info or get_all_boards_info would be more appropriate. An agent is left to infer usage from the name and signature.

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 provided, the description carries the full burden. It discloses the return type (Promise<IDMT_BoardItem | undefined>), the failure condition (undefined means retrieval failed), and the precise selection semantics ('last input focus'). This is strong for a read-only getter, though it does not enumerate the fields of IDMT_BoardItem or explicitly state that no modifications occur.

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 compact and well-structured with a signature line, a one-sentence summary, and dedicated remarks/returns fields. The API signature line is slightly redundant with the tool name and return info, but it is informative rather than wasteful. Every line 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 getter with no output schema, the description adequately covers the operation, the meaning of 'current', and the failure return. However, the structure of IDMT_BoardItem is left undocumented, and the generic 'args' parameter remains a black box, which limits how confidently an agent can interpret the result or specify parameters.

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 the schema already documents both args and windowId. The description itself does not add any parameter-level meaning beyond what the schema states; if anything, the args content remains an opaque array with empty item schema. 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 a specific verb and resource: '获取当前板子的详细属性' (get detailed properties of the current board). The remarks further clarify the scope by specifying that it targets the board associated with the currently open and last-input-focused schematic/PCB, which distinguishes it from related tools like get_board_info. It does not explicitly name sibling alternatives, so it stops 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.

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

The remarks provide clear context for when this tool applies: when there is a currently open schematic/PCB with last input focus. However, it does not explicitly state when to prefer alternatives (e.g., get_board_info for a specific board UUID, or get_all_boards_info for listing), nor does it give exclusions. The usage guidance is implied rather than explicit.

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 of behavioral disclosure. It mentions that it returns a boolean indicating success, but does not disclose that this is a mutating operation, any side effects, permission requirements, or whether the operation is destructive. The lack of warning about changing state is a notable gap.

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 extremely concise, consisting of a function signature, a Chinese phrase, and a return type note. It is front-loaded with the essential signature. While it is under-specified in other dimensions, this dimension rewards brevity and structure; the signature is a useful component and there is no 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 simple rename tool with two parameters and a boolean return, the description is insufficient. It does not explain the meaning of the parameters, any constraints (e.g., uniqueness of names), or how to pass the arguments (the schema's args array is described only as a JSON array). An agent would have to guess the parameter order and semantics from the signature alone, which is risky.

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 description provides parameter names and types via the signature (originalBoardName: string, boardName: string), which is more than the schema offers since the schema only has an args array with no item description. However, it does not explain the semantic difference between the two parameters (e.g., original is the current name, new is the target). The description partially compensates for the schema's lack of parameter detail but not fully.

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 (modify board name) and the resource (board) via the function signature and Chinese phrase '修改板子名称'. However, it does not differentiate from similar sibling tools like eda_dmt_folder_modify_folder_name or eda_dmt_panel_modify_panel_name, though the name itself is unambiguous. The verb and resource are specific, but no additional context is given to distinguish it beyond the tool name.

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 guidance on when to use this tool versus alternatives, no mention of prerequisites (e.g., the board must exist), and no exclusions. The description is purely a function signature with no contextual advice for selection.

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?

Annotations are absent, so the description carries the full burden. It discloses the core behavior (tab switch + focus) and the boolean success return, but doesn't mention failure cases, prerequisites (e.g., tabId must exist), or confirm there are no content-modifying side effects.

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 compact and organized into signature, Chinese summary, remarks, and returns, with no filler. The '激活文档' summary line is slightly redundant with the remarks, but overall the structure is efficient.

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 a simple one-argument operation and high schema coverage, the description is mostly adequate. However, with no annotations and no output schema, it does not explain what happens on invalid tabId, how to obtain a valid tabId, or how this tool relates to the many sibling editor_control tools.

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 coverage is 100% and windowId is already described in the schema. The description adds value beyond the schema by exposing the exact signature `tabId: string` and tying tabId to the 'specified document' in the remarks, which helps an agent construct the args array.

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 identifies a specific action—'activate document' / 'switch to the tab of the specified document and put input focus in it'—with a clear resource (document tab) and a tabId parameter. It does not explicitly contrast itself with sibling open/close/split-screen tools, so it falls 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.

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

The remark 'switch to the tab of the specified document' implies the document is already open and the tool is for activating an existing tab, not opening one. There is no explicit when/when-not guidance or mention of alternatives such as open_document, so usage is 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?

No annotations are provided, so the description carries the full burden. It discloses that the tool activates a split screen and returns a boolean success indicator, and remarks that it sets input focus. However, it doesn't disclose side effects (e.g., whether it changes the active window, whether it fails if the splitScreenId is invalid, or whether it affects other split screens). The return type is stated in the signature, but behavioral details are thin.

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 compact: a signature line, a short Chinese summary, and two brief remarks. It front-loads the essential information. The mixed-language content (English signature with Chinese remarks) is a minor structural issue but doesn't waste words.

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 tool with no annotations and no output schema, the description is thin. It doesn't explain how to obtain a splitScreenId (e.g., via get_split_screen_tree or get_split_screen_id_by_tab_id), what happens if the ID is invalid, or how the boolean return should be interpreted beyond 'success'. The sibling tools suggest a rich split-screen management context, and this description doesn't position the tool within it.

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% for the two parameters (args array and windowId), but the description itself only mentions splitScreenId in the signature. The description adds the meaning of the primary parameter (splitScreenId) and the return type, but doesn't explain the args array format or the windowId parameter beyond what the schema already says. Baseline 3 is appropriate since the schema covers the parameters.

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+resource: 'dmt_EditorControl.activateSplitScreen(splitScreenId: string) -> Promise<boolean>' and includes a Chinese summary '激活分屏' (activate split screen). It clearly identifies the action and target. However, it doesn't explicitly distinguish itself from sibling tools like create_split_screen or move_document_to_split_screen, though the name itself is fairly self-explanatory.

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 on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., a split screen must already exist), when it's appropriate to call, or when to prefer create_split_screen or other split-screen management tools. The 'remarks: 使输入焦点' (make input focus) hints at the effect but doesn't provide usage context.

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?

The description states the return value ('Promise<boolean>', '操作是否成功') and the core side effect of closing a document. With no annotations, it does not disclose important behavioral details such as handling of unsaved changes or whether a specific tab is required, leaving the safety profile incomplete.

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?

Three short lines carry the signature, the action, and the return meaning without redundancy. Every phrase earns its place and the essential info 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 close operation, the core semantics are present, but the wrapper schema (args array, optional windowId) is never tied to a concrete invocation. The description also omits how to determine the tabId and any behavior around unsaved work, so an agent has to infer too much.

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 the baseline is 3. The description adds the method signature with tabId:string and the schema explains args are in official signature order, but neither explains what a tabId refers to beyond its obvious name.

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 gives the exact API signature 'dmt_EditorControl.closeDocument(tabId: string)' and the Chinese '关闭文档', clearly identifying the action and resource. It does not explicitly contrast with sibling controls such as open_document or activate_document, so it stops one step short of 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?

There is no guidance on when to choose this tool over alternatives, nor any prerequisites or exclusions. An agent must infer from the name alone that closing a document is the use case.

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 return value shape (sourceSplitScreenId and newSplitScreenId) and that it may return undefined, which is useful. However, it does not mention side effects, such as whether the split screen is immediately visible, whether it requires a specific editor state, or what happens if the tabId is invalid. The description is minimal and does not add behavioral context beyond the signature.

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 compact, containing the signature, a short Chinese phrase '创建分屏' (create split screen), and a return value explanation. It is front-loaded with the action and signature. The bilingual content is slightly redundant but not wasteful. It earns a 4 for being concise and structured, though the Chinese description is not necessary.

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 has no annotations, no output schema, and only a generic args array, the description should provide more context. It explains the return value but lacks information about the splitScreenType enum values, how to obtain a tabId, and what 'undefined' means in practice. The sibling tools suggest a rich split-screen management system, and this description does not fully equip an agent to call it correctly without additional lookups.

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 has 100% description coverage for its two parameters (args and windowId), but the descriptions are generic: 'args' is a JSON array in official signature order, and 'windowId' targets a window. The description adds the method signature with parameter names and types (splitScreenType: EDMT_EditorSplitScreenDirection, tabId: string), which helps map args to meaningful values. However, it does not explain the enum values for splitScreenType or the format of tabId. Baseline 3 is appropriate since the schema covers the parameters but the description adds some semantic value.

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 ('create') and resource ('split screen'), and includes the method signature with parameter types and return type. It is clear this tool creates a split screen in the editor. However, it does not explicitly differentiate from sibling tools like activate_split_screen or get_split_screen_tree, though the name and action are distinct enough.

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 no guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as needing an active document or tab, nor does it explain when a split screen would be appropriate. The only context is the signature and a brief Chinese description, which implies usage but does not state it.

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 present, the description carries the full burden of behavioral disclosure. It does add valuable context: the coordinate-unit remark (0.01inch for schematic/symbol canvases, mil for PCB/footprint canvases) and the return semantics ('false' means the canvas doesn't support the operation or tabId doesn't exist). However, it doesn't state whether this is a persistent/visible mutation or how existing markers are affected, leaving the safety profile partly unspecified.

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 dense but efficient: a signature line, a short purpose in Chinese, a unit remark, and a return explanation. Each element earns its place. It is front-loaded with the signature and purpose. Slightly fragmented across purpose/remarks/returns, but no wasted sentences.

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 generation tool with no annotations and no output schema, the description covers the return value and unit considerations well. However, the IDMT_IndicatorMarkerShape type is never detailed, so an agent doesn't know the required marker fields. Given the complexity of the marker shape structure, this is a meaningful gap, though the unit remark and failure conditions mitigate it.

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 is generic (args array, windowId) with 100% coverage, but the description compensates by spelling out the full signature with parameter types: markers, color {r,g,b,alpha}, lineWidth, zoom, tabId. This adds real meaning beyond the schema, particularly the color object shape and the optional tabId for targeting a specific tab.

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 clear verb and resource: '生成指示标记' (generate indicator markers) with a full method signature. It is distinguishable from its sibling eda_dmt_editor_control_remove_indicator_markers, which is the inverse operation. It doesn't explicitly name the sibling, but the intent is unambiguous.

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 guidance on when to use this tool versus alternatives such as the remove_indicator_markers sibling, nor any prerequisites (e.g., an active canvas or document). The context in which generation applies is only implied by the tabId/windowId parameters. No exclusions or conditions are stated.

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 provided, the description carries the behavioral disclosure burden. It does disclose the core behavior: it retrieves the canvas rendered area and returns image data as a Blob, with the signature exposing that it may also return undefined. However, it does not explain edge cases, whether it captures the current viewport or full canvas, or the image MIME type.

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 very concise and front-loaded with the signature and core purpose. Every line serves a useful role, though the overall entry is terse and could include slightly more behavioral context without becoming verbose.

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, has no required parameters, and the schema already describes windowId, so the missing output schema is partially compensated by the return type in the signature. Still, the description does not clarify what 'current' means, when undefined is returned, or what image format the Blob contains, leaving some ambiguity for an agent deciding whether this tool is appropriate.

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 coverage is 100%, so the baseline is 3. The description adds the tabId?: string parameter in the signature, which helps clarify the first positional argument, but it does not explain tabId's semantics or how it interacts with windowId beyond what the generic args array and windowId description already provide.

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 clear action and target: '获取画布渲染区域图像' (get the canvas rendered area image), backed by the explicit signature showing it returns a Blob. It is specific enough to be understood as a getter for the current editor canvas area, though it does not explicitly differentiate itself from other image-producing sibling 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?

There is no guidance about when to use this tool versus alternatives, and no exclusions or prerequisites are mentioned. Siblings such as eda_sch_manufacture_data_get_png_file or eda_lib_symbol_get_render_image also produce images, but the description does not explain how this tool differs or when it should be preferred.

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?

The description discloses that the return is a Promise resolving to string or undefined, indicating the tool may return no result if the tab is not found. However, since no annotations are provided, the description carries the burden of behavioral disclosure. It does not mention any side effects, error conditions, or requirements (e.g., whether a specific window must be active). For a simple getter, this is minimal but adequate.

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 concise, consisting of a signature, a one-line Chinese purpose statement, and a return note. It is front-loaded with the signature, but the purpose and return are repeated in both English and Chinese, introducing minor redundancy. Overall, it is efficient and to the point.

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 lookup tool with a single conceptual parameter and a well-defined return, the description, combined with the schema, is nearly complete. It covers the purpose and return type, and the schema documents both invocation parameters. A minor gap is that the description's signature omits the windowId parameter, which the schema does document, so an agent relying solely on the description might overlook it. Still, given the tool's simplicity, it is adequately complete.

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 function signature in the description names the primary parameter tabId and its type, which adds clarity beyond the schema's generic 'args' array. However, the description does not explain what a tab ID is or where to obtain it. The schema itself provides descriptions for args and windowId, giving 100% coverage, so the description's contribution is modest but non-redundant.

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 function: get a split screen ID from a tab ID (using tab ID to get split screen ID). It includes the method signature and return type, making the purpose unambiguous. However, it does not contrast with the sibling tool get_tabs_by_split_screen_id, which performs the reverse mapping, so it lacks explicit 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?

No guidance is provided on when to use this tool versus alternatives. The description simply states what it does without mentioning prerequisites, when it is appropriate, or exclusions. An agent must infer from the tool name and sibling names that it is for mapping a tab to a split screen, but no explicit usage guidance is given.

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 present, so the description carries the behavioral disclosure burden. It adds useful context by declaring the return type `Promise<IDMT_EditorSplitScreenItem | undefined>` and explaining that `undefined` means data retrieval failed. However, it does not mention side effects, permissions, or whether the active window is required.

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 concise and front-loaded with the method signature, followed by a one-line purpose and a return-value note. It contains minimal redundancy, though the return line partly repeats the Chinese purpose phrase.

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 getter with zero required parameters, the return type and failure semantics are helpful and mostly sufficient. Still, it lacks usage guidance, clarification of the `args` array, and any behavioral notes beyond the return value, so completeness is moderate.

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 `args` and `windowId` already described in the input schema. The description adds no further parameter semantics, so the baseline score of 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 identifies the exact API method (`dmt_EditorControl.getSplitScreenTree()`) and states the purpose in Chinese: '获取编辑器分屏属性树' (get the editor split-screen property tree). This specific verb+resource pairing makes it distinguishable from sibling split-screen getters like `get_split_screen_id_by_tab_id` and `get_tabs_by_split_screen_id`.

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 guidance on when to use this tool versus alternatives, nor any mention of when not to use it. The method signature and name imply a simple getter, but no explicit usage context or exclusions are provided.

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 provided, the description carries the full behavioral burden. It does disclose the return type and the fact that a tab list is returned, implying a read-only getter, but it does not mention behavior for invalid IDs, empty results, or any side effects.

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 compact: a signature line, a one-line Chinese purpose, and a return note. It has almost no filler, though the purpose is restated in both the signature and the Chinese sentence, which is minor duplication.

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 getter, this is mostly adequate: it names the parameter, return type, and operation. However, since there is no output schema, it does not describe the shape of IDMT_EditorTabItem, and the mapping between splitScreenId and the args array is left implicit rather than explicit.

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 describes args generically and windowId specifically, and the description adds the splitScreenId parameter name and type through the method signature. It still does not explicitly state that splitScreenId must be placed as the first element of the args array, nor does it describe IDMT_EditorTabItem fields.

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?

Description specifies a clear action ('获取' / get), a clear resource (all tabs under a given split screen ID), and a concrete return type (Promise<Array<IDMT_EditorTabItem>>). It is easily distinguished from sibling tools like get_split_screen_id_by_tab_id, which performs the reverse lookup.

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 intended usage is implied: call this when you have a splitScreenId and need all tabs in that split screen. However, there is no explicit guidance on when not to use it or which sibling tool, such as get_split_screen_tree, would be more appropriate for broader split-screen queries.

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 disclosure burden. It reveals the destructive side effect: closing all child split screens, and states the return type (Promise<boolean>). It also documents the precondition. This is solid but stops short of warning about irreversibility or any confirmation prompts.

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 compact and well-organized, leading with the method signature, then a one-line summary, remarks, and returns. Every sentence adds information and there is no 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 mutating tool with no annotations, the description states purpose, precondition, side effects, and return value. The schema fills in parameter semantics. A minor gap is the lack of explicit guidance on whether args should be an empty array given the zero-parameter signature, but the signature itself implies 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 schema description coverage is high (100%) and already explains both parameters: args is a JSON array in official signature order, and windowId targets a window or defaults to active. The description adds no parameter-specific detail, so the baseline 3 applies.

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 identifies the action: 'merge all split screens' and specifies the effect: cancel all child split screens and merge document tabs into the initial split screen. The verb-resource pairing is specific and distinct from sibling split-screen tools, though it does not explicitly name an alternative.

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 states an explicit precondition: '仅当存在子分屏时可用' (only available when child split screens exist), which tells the agent when to call it. It does not mention alternatives or when not to use it, but the precondition is clear and useful.

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 full burden. It does add a useful side-effect note ('移动文档后，编辑器分屏属性树可能会出现变化' – property tree may change) and states the return contract (boolean success). However, it does not disclose whether the document is removed from its original location, whether the operation is reversible, or any permission requirements – gaps that matter for a mutating operation.

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 compact and information-dense: signature, one-line purpose, remarks, and return value – each line earns its place. Slight improvement would be leading with the purpose rather than the signature, but overall it is efficiently structured.

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?

Adequate for a 2-parameter tool with no output schema, covering purpose, signature, one side effect, and return semantics. However, it lacks workflow context: how to source tabId/splitScreenId, the precondition that a target split screen must exist, and confirmation of whether the source split screen loses the document. These are material gaps for correct invocation.

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 baseline is 3. The description adds value by exposing the parameter names and types (tabId: string, splitScreenId: string) in the signature line, which compensates for the generic 'args' array in the schema. However, it does not explain how to obtain valid tabId or splitScreenId values (e.g., via get_tabs_by_split_screen_id or get_split_screen_id_by_tab_id).

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 action ('将文档移动到指定分屏' – move document to specified split screen) with the signature showing tabId and splitScreenId, making the verb, resource, and target explicit. It reads distinctly from siblings like create_split_screen or activate_split_screen, though it does not explicitly name its closest 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 when-to-use guidance is given. There is no mention that a split screen must already exist (e.g., via create_split_screen), no indication of when to prefer this over merge_all_document_from_split_screen or tile_all_document_to_split_screen, and no exclusions or prerequisites. The remarks only describe a side effect, not usage context.

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 does disclose the success/failure semantics (returns a tab ID, or undefined on failure), which is useful. However, it does not mention side effects on the current window/tab, whether the document must already be loaded, or what happens if the document is already open.

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 compact and front-loads the exact API signature followed by the Chinese purpose and return explanation. It contains no filler, though it is brief enough that some of the missing contextual detail could have been added without bloating it.

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 open-document operation, the description covers the essential return behavior and failure signal, and the schema covers windowId. It remains incomplete because it does not explain how to obtain a valid documentUuid, how splitScreenId affects behavior, or when to prefer the sibling open_library_document 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?

The schema only exposes a generic args array and windowId, so the description's signature is essential: it documents documentUuid as a string and splitScreenId as an optional string. This adds real meaning beyond the schema's generic JSON-array placeholder.

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 the operation clearly: '打开文档' (open document) and provides the exact method signature openDocument(documentUuid, splitScreenId). It identifies a specific verb, resource, and return value (tab ID), but does not explicitly differentiate itself from the sibling eda_dmt_editor_control_open_library_document.

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 guidance on when to use this tool versus alternatives such as open_library_document, activate_document, or close_document. The description implies its use from the name but provides no selection criteria, prerequisites, or exclusions.

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 provided, so description carries full burden. It only mentions return value (tab ID or undefined for failure) but does not disclose side effects, prerequisites, or whether it changes the active tab or requires permissions. For an opening action, this is minimal.

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 short and front-loaded with the signature, which is useful. It avoids verbosity and includes essential return information, though it could be more organized by separating signature from description.

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 document-opening tool, it gives signature, return value, and failure condition. But it lacks context on when to use it, whether splitScreenId is optional and its purpose, and any required setup. Given no annotations, it is incomplete but not severely lacking.

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 description includes the full signature with parameter names and types (libraryUuid, libraryType with enum, uuid, splitScreenId), providing more detail than the generic args array schema. However, it does not explain the meaning of each parameter beyond its name (e.g., what libraryUuid and uuid refer to).

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 opens library symbol and footprint documents, with the full function signature and return type. It distinguishes from siblings like open_document by specifying 'library' documents, though it doesn't explicitly contrast with similar open 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?

No guidance on when to use this tool versus alternatives like eda_dmt_editor_control_open_document or library-specific open tools. It lacks conditions for choosing this over other open or activate tools.

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 full burden. It discloses that the interface removes ALL generated indicator markers, and that returning false means the canvas doesn't support the operation or tabId doesn't exist. However, it doesn't mention whether removal is destructive/reversible or any side effects beyond the return value.

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 concise, mixing a signature with a short Chinese explanation and remarks. It's front-loaded with the purpose and includes return semantics without unnecessary fluff.

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 removal tool, it explains the all-removal behavior and the boolean return meaning. It doesn't clarify behavior when tabId is omitted (though schema implies optionality), but this is minor for a tool of this simplicity.

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 coverage is 100% for both args and windowId. The description adds the function signature showing tabId as an optional parameter, but provides no additional semantics about tabId beyond what the schema implies. It's baseline 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?

The description clearly states the operation: '移除指示标记' (remove indicator markers). It's a specific verb+resource, not a tautology. It doesn't explicitly differentiate from the sibling generate_indicator_markers, but the inverse nature is obvious from the names.

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 provided on when to use this tool versus the generate counterpart or any alternatives. There's no mention of prerequisites (e.g., that markers must already exist) or when removal is appropriate.

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 primary effect (creating split screens for all open tabs) and the return type (boolean). However, it does not describe what happens if the precondition is violated, whether existing split screens are replaced, or any side effects on the UI layout. This is moderate transparency but lacks fuller behavioral context expected without annotations.

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 concise and includes the essential information: the method signature, a one-line purpose, a usage remark, and the return value. It is somewhat redundant to include the method signature line when the tool name already conveys it, but the structure is clear and front-loaded with the core purpose. Minor redundancy prevents a 5.

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 tool with no output schema and no annotations, the description does a decent job: it explains the purpose, the condition of use, and the return. However, it omits details about failure modes, behavior when the precondition is not met, and any potential side effects on the split-screen layout. An agent would benefit from knowing these aspects to handle errors gracefully, so completeness is moderate.

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 input schema has full description coverage for both parameters ('args' and 'windowId'), explaining their purpose. The description does not add any additional meaning beyond the schema. Since schema coverage is 100%, the baseline of 3 is appropriate; the description neither enhances nor contradicts parameter understanding.

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: 'tile all documents' and provides the Chinese equivalent '平铺所有文档' along with an explanation that it creates split screens for all open document tabs. This is specific and distinguishes it from sibling tools that operate on individual documents or split screens.

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 clear precondition: '仅当不存在子分屏时可用' (only available when no child split screen exists). This tells the agent when it is appropriate to call this toolretically. It does not explicitly mention alternatives or when-not-to-use beyond this condition, 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?

No annotations are provided, so the description carries the burden. It discloses the return value shape and the false condition (canvas doesn't support zoom or tabId doesn't exist). It also adds a remark about coordinate unit spans for different canvas types. However, it doesn't describe side effects (e.g., does it change the current view? is it reversible?) or whether it requires an active document. The return type and false condition are useful behavioral disclosures.

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 compact: a signature line, a one-line Chinese summary, a remarks line, and a returns line. It front-loads the signature and purpose. The remarks about coordinate units are relevant but somewhat tangential to the zoom operation itself. Overall, every line earns its place, though the structure is a bit dense with mixed languages.

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 has no output schema and no annotations, the description does a decent job: it provides the return type, the false condition, and a unit remark. However, it lacks information about the meaning of the percent value, valid ranges, whether the zoom is relative or absolute, and how it differs from the many sibling zoom tools. For a tool with 2 parameters and no output schema, this is adequate but has clear gaps.

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% per context signals, but the schema itself is generic: it only describes 'args' as a JSON parameter array and 'windowId' as a target window ID. The description adds the function signature 'zoom(percent: number, tabId?: string)' which clarifies the first parameter is a percentage and the second is an optional tab ID. This adds meaning beyond the generic schema, but it doesn't explain what 'percent' means (e.g., 100 = actual size? 200 = 2x?) or the valid range. The description partially compensates for the generic schema.

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 ('zoom') and resource ('dmt_EditorControl'), and includes the function signature with return type. It clearly indicates this sets a zoom percentage. However, it doesn't explicitly differentiate from the many sibling zoom tools (zoom_to, zoom_to_region, zoom_to_all_primitives, etc.), so it's clear but lacks 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 implies usage: call this to set a zoom percentage on the editor control. It doesn't explicitly state when to use this vs. the other zoom-related siblings (zoom_to, zoom_to_region, zoom_to_selected_primitives, etc.). The 'remarks' about coordinate units provide some context but not usage guidance. No exclusions or alternatives are mentioned.

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 must disclose behavior itself. It does so by stating the return type (region data or false), the meaning of false (canvas doesn't support or tabId doesn't exist), and critical coordinate unit differences across canvas types (0.01 inch for schematic/symbol, mil for PCB/footprint). This is valuable context beyond the schema, though it does not mention side effects or whether the zoom is persistent.

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 reasonably concise, mixing signature, Chinese purpose, remarks, and returns in a compact form. The purpose is front-loaded with the signature and the Chinese phrase. It could be better structured (separating remarks from main description) but is not overly verbose.

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 zoom tool with four optional parameters, the description provides the essential info: parameter names/types, return type, and canvas unit differences. It does not explain the role of scaleRatio or whether the zoom is absolute vs relative, but these may be inferable from the name. The false return condition and unit note add completeness. Overall, it covers the core needs for correct invocation.

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 only describes 'args' and 'windowId' generically, so the description carries the burden of explaining the actual parameters. It provides the signature with names and types (x, y, scaleRatio, tabId) and the coordinate unit remarks, which adds meaning. However, it does not explain the semantics of each parameter (e.g., what scaleRatio represents, or whether x/y are center coordinates), leaving some inference needed.

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 zooms to coordinates via the signature and Chinese text '缩放到坐标' (zoom to coordinates). It specifies the operation on the editor control and provides the parameter types. While it doesn't explicitly differentiate from sibling zoom tools (e.g., zoom_to_region, zoom_to_selected_primitives), the purpose is unambiguous enough for an agent to understand the basic action.

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 gives no guidance on when to use this tool versus the many sibling zoom tools (zoom_to_region, zoom_to_all_primitives, zoom_to_selected_primitives, etc.). It does not mention alternatives or provide conditions for selecting this specific zoom method, leaving the agent to infer usage from the name alone.

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 provided, the description carries the full behavioral burden, and it delivers meaningful disclosure: the `false` return condition (unsupported canvas or nonexistent tabId) and the per-canvas coordinate unit difference (0.01inch for schematic/symbol vs mil for PCB/package) are genuinely useful beyond the basic purpose. It does not state that this is a non-destructive view operation, but the failure semantics and unit caveat are above-average disclosure.

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 compact: signature line, one-line Chinese summary, remarks, and returns. The signature is front-loaded, and the remarks and returns lines each add non-redundant information. Minor redundancy exists between the tool name, the signature, and the Chinese translation, but overall there is little waste.

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 description covers return shape, failure conditions, and unit semantics — the core facts needed to interpret results. However, with no annotations and no output schema, it could do more: it never clarifies how this differs from the sibling zoom tools, what canvas/document it acts on by default, or whether it preserves current zoom state. Adequate for invocation, but with clear gaps around tool selection.

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?

Although schema coverage is 100% for the wrapper properties (args, windowId), the actual functional parameter tabId is buried in an untyped `items: {}` array. The description is the only place that reveals the real API signature `tabId?: string`, its optionality, and the fact that a nonexistent tabId causes a `false` return — substantive meaning the schema does not provide.

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 action on a specific resource: 'zoomToAllPrimitives' / '缩放到所有图元（适应全部）' (zoom to all primitives, fit everything). The 'all' qualifier semantically distinguishes it from sibling zoom tools like zoom_to_selected_primitives and zoom_to_region, though it never names them explicitly.

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 on when to choose this tool over the sibling zoom family (zoom, zoom_to, zoom_to_region, zoom_to_selected_primitives). The only auxiliary content is a unit-conversion remark, which is behavioral, not usage direction. An agent is left to infer selection criteria from the name alone.

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 of behavioral disclosure. It mentions the return type (Promise<boolean>) and the coordinate unit spans for different canvas types, but it does not disclose side effects (e.g., whether the view is altered irreversibly), error conditions, or whether the operation is read-only. For a zoom operation, the lack of safety info is a notable gap.

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 bit clunky: it starts with a raw method signature, then a Chinese remark, then an English remark about units, and a returns note. It repeats the method name and parameters in both signature and name. It's not overly long but could be more structured and front-loaded with the essential purpose rather than the signature duplication.

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 zoom-to-region tool, the description lacks many details an agent would need: the coordinate system origin and orientation, what 'left/right/top/bottom' refer to (bounding box?), whether the zoom is absolute or relative, behavior for out-of-bounds coordinates, and the meaning of the boolean return beyond 'success'. It does mention unit spans, which is helpful, but overall it is incomplete for confident invocation, especially with no output schema to clarify results.

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 input schema only defines 'args' as an opaque array and 'windowId', offering no per-parameter meaning. The description compensates partially by listing the parameters (left, right, top, bottom, tabId) with types in the signature, and it adds crucial unit context: '0.01inch' for schematic/symbol canvases and 'mil' for PCB/package canvases. However, it doesn't explain the coordinate origin, range constraints, or the meaning of each boundary relative to the canvas, leaving semantic gaps.

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 purpose: zoom to a region, as expressed by the method signature and the Chinese remark '缩放到区域' (zoom to region). The verb 'zoomToRegion' and the parameters make it specific, distinguishing it from sibling zoom tools like 'zoom', 'zoom_to', and 'zoom_to_all_primitives' by indicating it targets a rectangular region. However, it doesn't explicitly contrast with these siblings, so it loses a point.

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 guidance on when to use this tool versus alternatives like eda_dmt_editor_control_zoom, eda_dmt_editor_control_zoom_to, or zoom_to_selected_primitives. The description only provides the signature and unit notes, leaving the agent to infer applicability. No explicit exclusions or preferred scenarios are mentioned.

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 provided, the description carries the full burden of behavioral disclosure. It does disclose the return type (bounding box or false) and explains that false indicates an unsupported canvas or missing tabId. It also provides unit scaling remarks for different editor types. However, it does not mention behavior when nothing is selected, any side effects beyond zooming, or prerequisites like an active document. These are notable gaps for a mutation-like operation.

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 relatively compact, consisting of a signature, a one-line purpose, a remarks line, and a returns line. It is front-loaded with the signature and the core action. The structure is logical, though the mix of English and Chinese might be slightly disorienting. It earns its place without excessive verbosity.

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 description covers the return type and unit differences, but it does not explicitly explain how to map the tabId parameter to the args array in the schema, nor does it mention prerequisites like having selected primitives or an open editor. For a zoom tool with no output schema, this is a moderate gap. An agent might be unsure whether to pass tabId via args or windowId, and what happens with no selection. It is functional but not fully complete.

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 input schema is generic (args array and windowId) with minimal descriptions. The description adds meaningful semantics by providing the official signature with the tabId parameter, indicating it is optional and its type. This clarifies how the args array should be structured (with tabId as the first element). Since schema coverage is high but generic, the description compensates by giving the concrete parameter format.

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 zooms to selected primitives (适应选中). The verb and resource are specific and the purpose is unambiguous. While it does not explicitly contrast with sibling zoom tools like zoom_to_all_primitives, the name and description alone make the distinction clear enough for an agent.

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 does not explicitly state when to use this tool versus alternative zoom functions. It is implied that it should be used when the user wants to fit the view to currently selected primitives, but no exclusions or alternative recommendations are provided. This is an implied usage context, not an explicit one.

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?

Annotations are absent, so the description must carry behavioral burden. It only provides the function signature, which states the callback and onlyOnce flag but does not explain side effects, what triggers the event, whether duplicate IDs are allowed, or how the listener interacts with the editor's tab lifecycle. No mention of permissions, execution context, or cleanup requirements. This is minimal disclosure beyond the raw API.

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 line with the full function signature plus a short Chinese sentence. It is efficient and front-loaded with the signature, but lacks structured explanation or examples that would aid comprehension. Still, it conveys all necessary technical details without wasted words.

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 description covers the function signature and return type (void), which is useful, but it omits details about what EDMT_EditorTabEventType values exist, what the callback props represent semantically, and how windowId (from schema) integrates with the signature. An agent can call it correctly syntactically but may lack understanding of event semantics and lifecycle. Given the moderate complexity, it is partially complete.

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 merely defines an 'args' array with no structure, making it impossible to know parameter order or types. The description's TypeScript signature fully specifies each parameter (id, eventType, callFn, onlyOnce) and the shape of the callback's props object, providing critical semantics that the schema lacks. This is exceptional value-add.

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 function name and Chinese description '新增编辑器标签页事件监听' (add editor tab event listener), making the tool's purpose explicit: it registers a listener for editor tab events. The resource (editor tab) is specific and distinct from other event listeners like mouse, primitive, or net events. However, it does not explicitly contrast with sibling tools such as eda_dmt_event_is_event_listener_already_exist or remove_event_listener, so differentiation is implied rather than stated.

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 usage guidance is provided. The description does not indicate when to use this tool versus alternatives, how it relates to the other event listener tools (check existence, remove), or what scenarios call for editor tab event listening. The context is implied by the name and function signature but not made explicit for an agent choosing among many event-related tools.

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 burden. It discloses the return type (boolean meaning 'event listener exists') and the method signature, but it does not explicitly note that the call is non-mutating, what happens for an invalid id, or that windowId defaults to the active window.

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 signature is front-loaded and the prose is minimal. The only waste is that 'returns: 事件监听是否存在' repeats the meaning of '查询事件监听是否存在'.

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 existence check with a single string parameter, the description plus the schema's windowId explanation is enough to call the tool. It lacks a note on where listener ids come from and any error behavior, but the tool's simplicity keeps this gap minor.

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 input schema only describes args as a generic JSON array, so the description adds real value by specifying the id: string signature. It does not explain where the id comes from or its format, but for a one-string-argument predicate this is mostly sufficient.

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 operation — dmt_Event.isEventListenerAlreadyExist(id: string) — and explains in Chinese that it checks whether an event listener exists, returning a boolean. This clearly distinguishes it from the PCB/SCH/I18N listener-check siblings through the dmt_Event prefix, so an agent can tell what it operates on.

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 provided about when to call this check versus alternatives. It does not say to use it before eda_dmt_event_add_editor_tab_event_listener to avoid duplicates, nor does it point to the equivalent PCB/schematic tools.

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?

Since annotations are absent, the description bears the full burden of behavioral disclosure. It does reveal that the function returns a boolean indicating whether the specified listener was removed. However, it does not describe side effects, behavior when the listener does not exist, or whether removal is idempotent, leaving the behavioral profile largely opaque.

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 extremely compact: a signature line, a short Chinese phrase, and a returns line. It front-loads the core information and contains no filler. It is appropriately concise, though it borders on being under-specified rather than genuinely helpful.

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 tool with no annotations and no output schema, the description is incomplete. It omits how the event listener id is acquired, what true/false concretely mean beyond 'removed', and how this tool relates to the many sibling event-listener tools. An agent might guess the call shape, but key contextual information is missing.

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 already provides 100% coverage of both parameters (args array and optional windowId), so the baseline is 3. The description's signature adds the useful hint that the first argument is a string 'id', clarifying the otherwise generic args array. But it stops short of explaining what the id represents or how it is obtained, so it adds only marginal semantic value.

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 operation: 'dmt_Event.removeEventListener(id: string) -> boolean' and '移除事件监听' (remove event listener). This gives a specific verb and resource, making the tool's core purpose evident at a glance. It does not explicitly differentiate from sibling event-removal tools like eda_pcb_event_remove_event_listener, but the DMT prefix and signature make the scope identifiable.

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 guidance on when to use this tool versus alternatives such as eda_dmt_event_add_editor_tab_event_listener or eda_pcb_event_remove_event_listener. No prerequisites are mentioned, such as the need for an already-registered listener id or how to obtain it. The agent must infer usage solely from the tool name and signature.

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 provided, the description carries the burden of behavioral disclosure. It does disclose the return value: a folder UUID string, or undefined if creation fails, which is useful. It does not disclose side effects (e.g., whether the folder is immediately visible, whether it requires an active team context, or whether duplicate names are rejected). The description adds the failure signal (undefined) but lacks deeper behavioral context like persistence or validation rules.

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 compact: a signature line, a Chinese one-liner, and a return-value note. It front-loads the essential call signature and return behavior. The Chinese '创建文件夹' is redundant with the signature but harmless. It earns a 4 because it is efficient and structured, though the redundancy and lack of parameter explanations prevent a 5.

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 create operation with no output schema and no annotations, the description provides the signature, return type, and failure signal, which covers the basics. It does not explain the context of teamUuid (e.g., how to obtain it, whether it is required to be the current team), nor does it mention any constraints like folder name uniqueness or parent folder existence. Given the tool's simplicity, this is adequate but not complete; an agent might need to consult sibling tools like eda_dmt_team_get_all_teams_info to resolve teamUuid.

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 input schema has 100% description coverage for its two top-level parameters (args array and windowId), but the actual function parameters (folderName, teamUuid, parentFolderUuid, description) are only listed in the description's signature line. The description adds meaning by showing the order and optionality of these parameters, which is valuable given the args array format. However, it does not explain the semantics of each parameter beyond their names, such as what teamUuid refers to or how parentFolderUuid affects the folder hierarchy.

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 and resource: 'dmt_Folder.createFolder' creates a folder, with parameters for folder name, team UUID, parent folder UUID, and description. It clearly distinguishes from siblings like eda_dmt_folder_delete_folder, eda_dmt_folder_get_all_folders_uuid, and eda_dmt_folder_modify_folder_name. However, it doesn't explicitly state the domain context (e.g., that it creates a folder in a team's folder tree) beyond the parameter names, and the Chinese '创建文件夹' is a direct restatement of the name.

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 implies usage by listing the required parameters (folderName, teamUuid) and optional ones (parentFolderUuid, description), which tells an agent what is needed to create a folder. It does not explicitly state when to use this tool versus alternatives like eda_dmt_folder_move_folder_to_folder or eda_dmt_folder_modify_folder_name, nor does it mention prerequisites like team membership or permissions. The context is clear enough for a simple create operation, but there is no explicit when/when-not guidance.

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 provided, the description carries the full burden of behavioral disclosure. It only says 'delete folder' and returns a boolean, but does not mention that deletion is irreversible, may fail if the folder contains items, requires specific permissions, or what happens on non-existent folders. For a destructive operation, this is a significant gap.

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 extremely brief—a single signature line and a two-word Chinese phrase plus a return explanation. It is front-loaded with the signature and contains no redundant text. However, it is so sparse that it borders on under-specification rather than being well-structured.

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 destructive mutation tool with no annotations and no output schema, the description is incomplete. It fails to disclose side effects, preconditions, error behavior, or any safety information. An agent cannot assess the consequences of calling this tool beyond knowing it returns a boolean. The simplicity of the operation does not excuse the lack of 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 description includes the method signature 'deleteFolder(teamUuid: string, folderUuid: string)', which names and types both parameters. The input schema only defines an opaque 'args' array and a windowId, so the description provides the essential parameter meaning that the schema lacks. It adds value beyond the schema.

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 '删除文件夹' (delete folder) and provides the method signature with resource (folder) and verb (delete). It is distinct from sibling tools that create, modify, move, or get folder info. The purpose is unambiguous.

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 guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., folder must be empty), when deletion is appropriate, or any conditions that should lead an agent to choose this over other folder operations. The description simply states the operation without context.

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 full burden. It explicitly discloses a non-obvious behavior: '本接口忽略层级信息，将会返回所有层级的文件夹的 UUID 并放置于一维数组中' (ignores hierarchy, returns all folder UUIDs flattened in a 1D array). It also states the return type (Promise<Array<string>>). It does not mention failure modes or side effects, but for a read-only getter these are less critical.

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 compact: a one-line signature, a one-line purpose, and a one-line remark plus returns. It stays on point without fluff and front-loads the core purpose before the behavioral remark. It could be structured more cleanly, but it is appropriately sized for the tool's simplicity.

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 getter, the description covers purpose, return type, and the notable flattening behavior. The main gap is the ambiguous requiredness of teamUuid: the signature implies it is required, while the schema reports 0 required parameters, and the description does not clarify what happens if it is omitted. No output schema is present, but the stated string-array return is sufficient.

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 only defines a generic 'args' array with empty items, so the signature's 'teamUuid: string' is the only hint about the actual parameter, adding some value beyond the schema. However, the description does not explain what teamUuid represents, whether it is required, or how it maps to the args array beyond the schema's 'official signature order' note. Since reported schema description coverage is 100%, the baseline 3 applies.

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 '获取所有文件夹的 UUID' (get all folders' UUIDs), identifying a specific verb and resource. The code signature dmt_Folder.getAllFoldersUuid(teamUuid: string) reinforces the operation, and the remarks add that it returns all hierarchy levels flattened. While it does not explicitly name sibling alternatives, the 'all folders UUID' scope distinguishes it from tools like get_folder_info or create_folder.

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 gives no guidance on when to use this tool versus siblings such as eda_dmt_folder_get_folder_info (specific folder details) or eda_dmt_folder_create_folder. There are no exclusions, prerequisites, or alternative tool mentions. It only states what the tool does without any selection criteria.

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 provided, the description carries the full behavioral burden. It does disclose meaningful semantics: the return type `IDMT_FolderItem | undefined` and the failure contract '若为 undefined 则获取失败' (undefined means the fetch failed), which informs result handling. Other behavioral traits — permissions, error behavior, absence of side effects — are not covered, so the disclosure is useful but incomplete.

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?

Three compact components — signature, purpose statement, and return semantics — with no filler; every line earns its place. The minor flaw is ordering: the raw TypeScript signature is front-loaded ahead of the clearer natural-language purpose, and the mixed English/Chinese presentation slightly obscures the intent.

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?

With no output schema and no annotations, the description is the only source of return information, yet it never describes what attributes IDMT_FolderItem actually contains, leaving the agent to guess at the payload shape. It does cover purpose, parameters, and undefined-on-failure, which is adequate for a simple getter, but UUID sourcing and return-field details are missing.

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 describes args generically as '按官方签名顺序排列的JSON参数数组' (JSON parameter array in official signature order), giving the agent no idea what to put inside. The description's signature reveals the actual parameters — teamUuid and folderUuid, both strings — which concretely tells the agent what values to supply. This meaningfully exceeds the schema despite its 100% 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 combines the signature `dmt_Folder.getFolderInfo(teamUuid, folderUuid)` with the Chinese phrase '获取文件夹详细属性' (get folder detailed attributes), yielding a clear verb+resource: retrieve one folder's attributes by UUID. This is distinct from siblings like create_folder, delete_folder, and modify_folder_name, though it does not explicitly differentiate itself from get_all_folders_uuid.

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 guidance on when to use this tool versus alternatives such as eda_dmt_folder_get_all_folders_uuid, nor any hint about how to obtain valid teamUuid/folderUuid values (e.g., resolving them before calling). The agent must infer the usage context purely from the naming pattern, with no explicit exclusions or conditions stated.

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 carry the behavioral burden. It mentions that the operation is asynchronous and has a delay, which is useful, but it fails to disclose potential side effects, permissions, or whether the operation is reversible. This is a mutation tool, and the description doesn't warn about prerequisites or errors accordingly.

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 relatively concise, with a clear signature, a brief usage note, and a returns line. It front-loads the signature and the remark about the delay, but it could be more efficient by discarding the redundant 'remarks' label. Overall, it's compact and well-structured.

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's moderate complexity (a single mutation with a few parameters) and the lack of annotations or output schema, the description covers the basic mechanics but omits details like what constitutes success (e.g., does it throw on failure?) and how to retrieve the updated description. It's adequate but not thorough.

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 has a high coverage (100%) of the parameters via the description of the args array, but the schema itself does not explicitly describe each argument. The description's signature line lists teamUuid, folderUuid, and description, but does not explain their roles or formats beyond what the names imply. Since coverage is high, a baseline of 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 it modifies folder descriptions, including the required team and folder UUIDs and the optional new description. However, it does not distinguish itself from the sibling 'modify_folder_name' explicitly, but the resource and field are specific enough.

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 explicit guidance on when to use this tool versus alternatives like modify_folder_name. It simply says it modifies the description, leaving the agent to infer that this is for description updates only.

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?

There are no annotations, so the description must carry the behavioral burden. It states the return value ('returns: whether modification succeeded') and the action, but it does not disclose side effects, required permissions, behavior on missing folder IDs, or whether the operation is reversible. This is minimal for a mutation tool; the agent has no idea about failure modes or prerequisites beyond the parameter names.

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 very short: a function signature and a one-line Chinese purpose plus return note. It is front-loaded with the signature and includes no unnecessary words. It's appropriately concise, though it could be slightly better structured if it separated the purpose from the signature, but as is it's efficient.

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 mutation tool with no annotations and no output schema, the description is incomplete. It does state the return boolean, but it doesn't explain prerequisites (like having valid UUIDs), error handling, or any side effects. An agent might know how to call it but not understand failure conditions or how to verify success beyond the boolean. More context is needed for a robust call.

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 input schema only defines 'args' and 'windowId' with no semantic detail, so the description's function signature is the only source for the actual parameters: teamUuid, folderUuid, folderName. It provides names and types, which is essential, but it doesn't explain what these represent (e.g., how to obtain teamUuid) or any constraints. Since the schema is high coverage for its own fields but the actual parameters are absent, the description partially compensates but not deeply, so a 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 states the function signature 'dmt_Folder.modifyFolderName' and a clear purpose line '修改文件夹名称' (modify folder name). This clearly identifies the verb (modify) and resource (folder name), and it is distinct from sibling tools like modify_folder_description or move_folder_to_folder, so an agent can easily distinguish it.

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 gives no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, conditions, or exclusions; it simply states the operation. An agent must infer from the name and context that this is the tool for renaming a folder, but no explicit when/when-not guidance is provided.

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 carry the full burden of behavioral disclosure. It states the function returns a boolean ('是否移动成功') but does not explain side effects, what happens on failure (e.g., partial moves), whether it is synchronous, or potential error conditions. The signature implies it's a mutation, but the description lacks behavioral context such as whether the move is reversible or if it affects related entities.

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 concise and includes the signature, a one-line Chinese summary, and a return description. However, the structure is slightly disorganized: the signature and return are on the same line, then the Chinese summary, then 'returns' repetition. It is compact but could be more readable with clear separation and front-loading of the core purpose. The mixed-language content may also reduce clarity for an English-focused agent.

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?

There is no output schema, no annotations, and the schema is minimal (generic args array). The description provides only the signature and return type, but lacks: what a successful move means, error/exception behavior, constraints (e.g., cannot move to descendant folder), and how the optional 'parentFolderUuid' interacts with the current parent. Given the tool's complexity (3 parameters, mutation), this is insufficient for an agent to reliably invoke it without risking incorrect behavior.

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 input schema only describes a generic 'args' array and 'windowId', providing no per-parameter detail. The description compensates by listing the official signature: teamUuid (string), folderUuid (string), parentFolderUuid (optional string), and the return type. This adds meaning beyond the schema, but it does not explain what each UUID represents (e.g., source vs. destination folder) or the semantics of 'parentFolderUuid' as the target location. Schema coverage is 100% in the sense that the args array is described, but the description only partially compensates for the lack of detailed parameter documentation.

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 operation: 'moveFolderToFolder' with Chinese '移动文件夹' (move folder). It identifies the resource (folder) and the action (move to folder). However, it does not explicitly differentiate from sibling move tools like eda_dmt_project_move_project_to_folder, though the name itself is specific enough for a folder operation. A dedicated textual distinction would have pushed it to 5.

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 provided on when to use this tool versus alternatives. The description only gives the function signature and return type. There is no mention of prerequisites (e.g., team UUID, folder UUID requirements) or when moving a folder is appropriate compared to other folder operations like create/delete/modify. The agent must infer usage from the name alone.

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?

The description discloses that the tool returns the new panel's UUID, and that 'undefined' indicates failure. This is useful behavioral information, but it doesn't mention side effects, permissions, or whether it operates on the active panel vs. a specified one. With no annotations provided, the description carries the full burden, and this is minimal but not misleading.

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 very concise, consisting of a signature line, a short Chinese label, and a return note. It's front-loaded with the core action and parameter. No wasted words, though it mixes English and Chinese, which could be slightly confusing.

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 description covers the core aspects: what it does, the parameter, and the return value. However, it lacks usage context, examples, or any note about side effects or failure conditions beyond 'undefined'. For a simple copy operation, this is adequate but could be more helpful with an example or note on how to retrieve the panelUuid.

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 input schema only shows a generic 'args' array, but the description provides the actual signature: 'panelUuid: string'. This adds meaning by specifying the parameter name and type, which the schema lacks. It clarifies how to construct the args array, going beyond the generic schema description.

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 the action clearly: '复制面板' (copy panel) with a function signature showing the parameter and return type. It's specific about what it does, and the name eda_dmt_panel_copy_panel matches. It doesn't explicitly differentiate from sibling copy tools (e.g., eda_dmt_board_copy_board) but the purpose is unambiguous.

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 on when to use this tool versus alternatives. There's no mention of prerequisites, when copying is appropriate, or how it differs from creating a panel. The description only states what it does, not when to invoke it.

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 provided, the description carries the full burden of behavioral disclosure. It only mentions the return type (UUID or undefined) and that undefined indicates failure. It does not state any side effects (e.g., whether a new panel is automatically opened), permissions needed, or whether it affects the current document context. This is minimal for a mutation tool.

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 very short and to the point, consisting of the function signature, a one-line Chinese description, and a return note. It is front-loaded with the action. It is concise and efficient, though it lacks any structured sections.

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 description is incomplete for an agent to call the tool correctly. It does not explain what arguments go into the 'args' array, nor does it mention any preconditions (e.g., an active project or workspace) or potential errors beyond a generic failure. Given the tool's role in a large EDA API, an agent needs more guidance to construct a valid call.

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 the baseline is 3. The schema describes both parameters: 'args' as a JSON array in official signature order and 'windowId' as an optional target window. The description adds nothing about parameters, so it does not improve on the schema. However, the 'args' parameter is vague (no list of expected fields), but that is a schema limitation, not something the description addresses.

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 '创建面板' (create panel) along with the function signature, making the purpose clear. However, it does not differentiate from other create-type tools like board creation, though the tool name itself is explicit. It adds a bit of detail on return value and failure condition, which helps.

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 guidance on when to use this tool versus alternatives. It does not mention any prerequisites, such as needing an active workspace, nor does it reference sibling tools like eda_dmt_panel_copy_panel or eda_dmt_panel_modify_panel_name. An agent is left to infer when to call this.

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 provided, the description carries the full burden of behavioral disclosure. It only says 'delete panel' and returns a boolean, but does not disclose irreversibility, side effects, required permissions, or what happens if the panel does not exist. The destructive nature is implied but not elaborated.

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 highly concise and front-loaded with the function signature, followed by a one-line Chinese summary and return type. Every element is useful and there is no 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 simple delete operation with no output schema, the description and signature cover the core mechanics, including the boolean return value. However, it does not explicitly state that panelUuid is required (the schema marks required parameters as 0), nor does it mention error behavior, reversibility, or whether the operation depends on the active window.

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 signature adds meaningful parameter semantics by naming 'panelUuid' with type 'string' and specifying the official call order, which compensates for the generic 'args' array in the input schema. It does not, however, clarify the optional windowId parameter or parameter formatting beyond what the schema already states.

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 a specific verb and resource: 'dmt_Panel.deletePanel' and '删除面板' (delete panel). The signature makes the operation unambiguous and distinguishes it from sibling panel operations like copy, create, or modify.

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 implies usage: use this when you need to delete a panel. However, it does not provide explicit context, prerequisites, or alternatives, such as when to use panel modification versus deletion.

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?

There are no annotations provided, so the description must carry the full burden of behavioral disclosure. It mentions it returns a Promise<Array<IDMT_PanelItem>>, which indicates it's a read operation, but it does not clarify whether it accesses the current project or requires a specific window, nor does it mention any side effects or limitations (e.g., performance with many panels).

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 extremely short and includes a code-like signature and Chinese text. It is concise but under-specified; the information provided is minimal and does not add much beyond the function signature. It could be more structured by explaining the return format or what 'detailed attributes' means.

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 that there is no output schema and no annotations, the description is incomplete for an agent to know what to expect. It does not describe the shape of the returned array items (IDMT_PanelItem), nor does it mention any prerequisites (e.g., active project). The tool is relatively simple but with no output schema, more detail is needed.

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 has 100% coverage, with the 'args' parameter described as a JSON array and 'windowId' described as the target window ID. The description adds no additional parameter semantics, but since the schema already explains them, the baseline is 3; however, the description does imply the tool operates within a project context, which is somewhat helpful. Thus, a 4 is appropriate as the schema is sufficient.

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 'getAllPanelsInfo' and explains it retrieves detailed attributes of all panels in the project, which is clear. However, it does not explicitly distinguish it from the sibling 'eda_dmt_panel_get_all_panels_info' with other panel-related getters like 'eda_dmt_panel_get_panel_info' (single panel) or 'eda_dmt_panel_get_current_panel_info'. The purpose is understandable but lacks explicit 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 does not provide any guidance on when to use this tool versus other panel-related tools, such as when to use 'eda_dmt_panel_get_panel_info' for a specific panel or 'eda_dmt_panel_get_current_panel_info' for the current panel. There is no mention of context or alternatives, leaving the agent to infer usage from the name.

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 provided, the description carries the disclosure burden. It identifies the operation as a read-only getter, explains exactly what 'current' means (open and last input focus), and documents that undefined indicates retrieval failure. For a simple getter, the key behavioral semantics are disclosed.

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 compact and front-loaded with the API signature, followed by a one-line Chinese summary, a clarifying remark, and return semantics. There is slight redundancy between the main summary and the remarks line, but the structure is clear and not bloated.

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 getter with no output schema, the definition is largely complete: it provides the return type, the failure sentinel, and the exact panel selection rule. A note about sibling tools or the shape of IDMT_PanelItem would improve completeness, but the core information needed to invoke it correctly is present.

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 coverage is 100% for the two parameters (args and windowId), so the baseline is 3. The description adds no parameter-specific detail beyond what the input schema already states, which is acceptable because the schema fully documents the parameters.

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 a specific action ('获取当前面板的详细属性') on a distinct resource, and adds the API signature with return type. The 'current' scope is further refined as the open panel with last input focus, which separates it from get_all_panels_info and get_panel_info, though it does not explicitly name those siblings.

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 implies when to use it: when you need the attributes of the currently active/focused panel, and it clarifies the selection criterion. However, it gives no explicit comparison to sibling tools like eda_dmt_panel_get_panel_info or eda_dmt_panel_get_all_panels_info, and no exclusion conditions, so usage guidance is mostly inferred.

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 full burden. It does disclose the return type (Promise<IDMT_PanelItem | undefined>) and defines undefined as indicating failure ('如若为 undefined 则获取失败'), which is useful. However, it does not mention side effects, permission requirements, or error behavior beyond the undefined case.

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 compact: a signature line plus two short Chinese phrases for purpose and return semantics. There is no filler or redundant restatement, though the structure is somewhat minimal.

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 read operation, the description covers the core purpose and return-failure convention, but it lacks guidance on how to obtain a valid panelUuid and does not explain the returned IDMT_PanelItem structure. It is minimally sufficient but not complete.

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?

Although the schema has generic 'args' and 'windowId' descriptions, the description adds the official signature 'dmt_Panel.getPanelInfo(panelUuid: string)', clarifying that the first positional argument is a string panelUuid. This meaningfully supplements the opaque 'args' array in the input schema.

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 clear verb and resource: '获取面板的详细属性' (get panel's detailed attributes), and the function signature identifies it as fetching a single panel item by UUID. It is distinguishable from siblings like eda_dmt_panel_get_all_panels_info and eda_dmt_panel_get_current_panel_info by name, though the description itself does not explicitly contrast them.

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 provided about when to use this tool versus alternatives such as get_all_panels_info (for all panels) or get_current_panel_info (for the active panel). The intended use can be inferred from the name, but the description never states selection criteria or exclusions.

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?

The description discloses the return type 'Promise<boolean>' and clarifies the boolean indicates success ('返回: 是否修改成功'), which is useful. However, with no annotations, it does not mention permissions, failure behavior for invalid UUIDs, or immediate side effects, leaving the agent to assume basic rename 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 compact and front-loaded with the function signature, followed by a one-line Chinese purpose and a return note. Minor redundancy exists because the return type appears in both the signature and the Chinese 'returns: 是否修改成功', but this does not impair clarity.

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 two-parameter rename tool, the description covers the inputs and boolean result, but lacks context on how to obtain the panel UUID, expected failure behavior, or whether the panel must be open/selected. With no output schema or annotations, it provides the minimum needed for a syntactically correct call but not deeper 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 input schema only describes 'args' as an array in official signature order and an optional 'windowId', so it does not document the actual parameters. The description fills this critical gap with the exact signature 'panelUuid: string, panelName: string', telling the agent precisely what values to pass and in what order.

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 operation through the signature 'modifyPanelName(panelUuid: string, panelName: string)' and the Chinese phrase '修改面板名称' (modify panel name), specifying both the resource (panel) and action (rename). It is distinguishable from sibling panel tools by the explicit rename intent, though it does not explicitly call out 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 about when to use this tool versus alternatives, nor any prerequisites, exclusions, or context such as how to obtain a valid panelUuid. The agent must infer usage solely from the tool name and terse description.

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 provided, the description must carry the full burden of behavioral disclosure. It does this well by stating that even if the PCB is associated with a reuse module, no new reuse module symbol is created, and it explicitly documents the return value semantics (new UUID or undefined on failure). It does not mention whether the copy is destructive, but that is implicitly clear. The remark and return type provide valuable behavioral context beyond a simple 'copy' statement.

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 concise and well-structured: it starts with the function signature for instant recognition, follows with the purpose in Chinese, then a behavioral remark, and finally the return value description. It avoids unnecessary fluff while packing in the essential details. The only minor issue is the mixed-language style, but that does not detract from clarity.

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 copy operation, the description covers the action, parameters, return value, and a significant behavioral nuance (reuse module handling). It does not mention any preconditions or side effects beyond the reuse module note, but for a simple copy that is acceptable. The presence of the signature and return semantics makes it adequately complete for an agent to invoke the tool correctly.

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 description explicitly provides the parameter names, types, and optionality (pcbUuid: string, boardName?: string), which is critical because the input schema only describes a generic 'args' array without indicating what parameters go in it. This directly adds meaning beyond the schema, and the optional flag is clearly conveyed. The schema's 100% coverage remark refers to the property structure, not the semantic content, so the description is essential.

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 purpose: '复制 PCB' (copy PCB) and provides the full function signature, making the verb and resource unambiguous. While it doesn't explicitly distinguish from sibling copy tools (e.g., copy_board, copy_panel), the PCB-specific naming and description are sufficient for an agent to identify the correct operation.

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 provided on when to use this tool versus alternatives like eda_dmt_board_copy_board or eda_dmt_panel_copy_panel. There is no mention of prerequisites, context, or exclusions. The only remark is about reuse module behavior, which is a behavioral note, not usage guidance.

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 burden of behavioral disclosure. It does add useful return semantics: a PCB UUID is returned, and undefined means creation failed. However, it does not disclose side effects, prerequisites, or whether the newly created PCB becomes active or appears in a specific project.

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 minimal and front-loaded: API signature, one-line purpose, and return/failure semantics. Every line earns its place, and there is no filler or repetition.

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 creation tool, the description is mostly complete: it gives the optional parameter, the promise return type, and the failure signal. Since there is no output schema, the explicit return description is valuable. It could provide more context about creation side effects, but the essential invocation details are present.

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 only describes 'args' as a JSON array in official signature order, but the description supplies the actual meaningful parameter via 'boardName?: string'. This adds real semantic value beyond the generic schema. windowId semantics are already covered by the schema.

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 '创建 PCB' (creates a PCB) and provides the API signature dmt_Pcb.createPcb. It specifies a concrete verb and resource, and the name distinguishes it from sibling operations like copy/delete/get/modify, though it does not explicitly contrast them.

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 guidance about when to use this tool versus alternatives such as eda_dmt_pcb_copy_pcb or other create_* tools. Usage context is only implied by the verb 'create' and the resource name, with no exclusions or prerequisites.

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 provided, the description carries full burden for behavioral disclosure. It clearly states that if the PCB is linked to a reused module symbol, deleting the PCB will also delete the associated schematic and reused module symbol, and that if the symbol cannot be deleted, it is skipped. This is critical side-effect information that an agent needs to know before invoking the tool.

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 concise, with a one-line signature, a one-line purpose, and a single remark about side effects. It is front-loaded with the signature and purpose before the remark. However, the remark is a bit verbose and could be slightly simplified, but it is efficient overall.

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 that the tool has no output schema and no annotations, the description covers the key behavioral side effects (deleting associated schematic and symbol) and return type (boolean). It doesn't specify any error conditions or what happens if the PCB doesn't exist, but overall it is complete enough for an agent to use it correctly in most cases.

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 input schema has 100% description coverage for parameters (args array and windowId), but the descriptions are generic ('按官方签名顺序排列的JSON参数数组'). The main description adds the signature 'pcbUuid: string', which clarifies the actual parameter, but it doesn't explain the exact format or required fields beyond that. Baseline 3 is appropriate as schema does most of the work, and the description adds marginal value.

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 opens with a clear signature showing the verb 'deletePcb' and the resource 'PCB', and the Chinese line '删除 PCB' translates to 'Delete PCB', making the purpose explicit. It is easily distinguishable from sibling tools like copy, create, or modify PCB 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?

The description implies the tool is used for deleting a PCB but does not state when to use it versus other delete tools (e.g., eda_dmt_board_delete_board) or when not to use it. It does not mention any prerequisites, such as needing to be in a project context or having the PCB open.

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 provided, the description carries the full burden of behavioral disclosure. It does convey a non-mutating read operation and a Promise<Array<IDMT_PcbItem>> return, but it says nothing about whether it reflects the current project, how windowId affects results, potential for large result sets, or error behavior. It is minimally 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 short but somewhat redundant: the signature line 'dmt_Pcb.getAllPcbsInfo() -> Promise<Array<IDMT_PcbItem>>' repeats the tool name and return type, and the final 'returns' line duplicates the main statement. It is not bloated, but it earns only average marks because lines do not each add distinct information.

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 read-only list tool, the description provides the essential action and return shape, but it omits relevant context such as the meaning of windowId, whether '工程内' means the currently active project, and what IDMT_PcbItem contains. With no output schema or annotations, an agent has only a vague idea of what will be returned.

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 the baseline is 3. The description adds no parameter-specific meaning: it does not mention windowId or how the args array should be used. The schema already describes both parameters generically, so no credit beyond baseline is warranted.

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 clear verb-resource pair: '获取工程内所有 PCB 的详细属性' (get detailed attributes of all PCBs in the project), and the function signature indicates it returns an array of IDMT_PcbItem. It is distinguishable from siblings like eda_dmt_pcb_get_pcb_info and eda_dmt_pcb_get_current_pcb_info by the 'all PCBs' scope, though it does not explicitly call out those distinctions.

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 provided on when to use this tool versus alternatives such as get_pcb_info, get_current_pcb_info, or other get_all_*_info siblings. The only implied usage is in the name 'get_all'. There are no exclusions, prerequisites, or contextual hints.

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 provided, the description carries the full burden of behavioral disclosure. It does disclose that the function returns undefined if retrieval fails, which is useful. However, it does not mention whether the operation is read-only (likely but not stated), any prerequisites like requiring an open PCB, or error-throwing behavior beyond the undefined return. This is partial transparency but misses key details for a getter.

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 short and includes a code signature line, a remarks section, and a returns section, which is reasonably structured. It conveys the essential behavior in a compact form without excessive verbosity. However, the structure could be improved by separating the return behavior more clearly, but it is not padded with unnecessary information.

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 getter, the description is fairly complete: it states what it fetches, the scope (current PCB with last focus), and the failure return value (undefined). It does not describe the IDMT_PcbItem structure, but there is no output schema, and for a getter the agent may not need full detail. The main missing piece is an explicit note that a PCB must be open, but this is implied by 'current open PCB.' Overall, it covers the essential 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?

Schema coverage is 100%: both parameters (args and windowId) have descriptions in the schema. The description itself does not elaborate on parameters, so it adds no extra meaning beyond the schema. The baseline for high coverage is 3, and since the description provides no additional parameter context, this score 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 it fetches detailed properties of the current PCB, using the verb '获取' (get) and a specific resource. The name 'current_pcb_info' already suggests the scope, and the description confirms it targets the currently open PCB with last input focus. However, it does not explicitly distinguish itself from sibling tools like eda_dmt_pcb_get_pcb_info, which retrieves a specific PCB by ID, though the word 'current' provides implicit 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 no guidance on when to use this tool versus alternatives. It does not state that it is the go-to for getting info about the currently active PCB, nor does it mention when to use eda_dmt_pcb_get_pcb_info for a specific PCB. The only hint is the word 'current' in the name and description, leaving the agent to infer the appropriate usage context.

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 full burden of behavioral disclosure. It usefully reports the return type `Promise<IDMT_PcbItem | undefined>` and states that `undefined` indicates failure. However, it does not disclose side effects, whether read-only behavior can be assumed, error behavior for invalid UUIDs, or permissions requirements. Still, the undefined-means-failure note adds meaningful behavioral context.

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 short and front-loaded with the signature and purpose. The return/failure note is useful and compact. Minor redundancy exists between the signature and the prose '获取 PCB 的详细属性', but overall the text is appropriately sized and every line serves a purpose.

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 and the schema covers the two top-level parameters, but there is no output schema and the description only vaguely defines the returned object as 'detailed properties'. It does not describe what fields of `IDMT_PcbItem` an agent can rely on, and it does not distinguish this lookup from the all/current PCB sibling tools. The absence of usage guidance and return-structure detail leaves material gaps.

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 only generically describes `args` as a JSON parameter array, but the description's signature `dmt_Pcb.getPcbInfo(pcbUuid: string)` supplies the essential parameter name, order, and type. This significantly clarifies what must be placed inside the generic `args` array, going beyond the structured schema 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 states a clear action ('get PCB detailed properties') and resource (PCB), with the exact function signature `getPcbInfo(pcbUuid: string)`. It is specific enough to identify the tool as a single-PCB lookup, though it does not explicitly differentiate itself from sibling tools like `eda_dmt_pcb_get_all_pcbs_info` or `eda_dmt_pcb_get_current_pcb_info`.

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 gives the parameter name `pcbUuid`, which implicitly suggests usage when a PCB UUID is known, but it never states when to use this tool versus alternatives. It does not mention `get_all_pcbs_info` or `get_current_pcb_info`, nor any exclusions or prerequisites, so an agent receives no explicit routing guidance.

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 provided, the description carries the full burden of behavioral disclosure. It discloses a meaningful side effect: if the PCB is associated with a reuse module symbol, renaming will also rename the reuse module symbol and the associated schematic name. It also states the return type (Promise<boolean>) and the return meaning ('是否修改成功'), which is useful. It does not discuss reversibility or permissions, but the key non-obvious side effect is covered.

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 compact: signature, one-line purpose, a focused remark about side effects, and the return meaning. Every sentence earns its place, and the core purpose is front-loaded before the side-effect note.

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 two-parameter rename with no annotations and no output schema, the description covers the purpose, side effect, and return. However, it lacks guidance on how to discover the pcbUuid, whether a specific window must be active, and any constraints on the new name. These are not fully compensated by the schema, which only describes the generic args array and windowId.

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 input schema only exposes generic `args` and `windowId`, but the description provides the exact function signature with parameter names and types: `(pcbUuid: string, pcbName: string)`. This adds meaning beyond the opaque schema and establishes the required order for the args array. The parameter names are self-explanatory, though deeper semantic detail (e.g., where to find pcbUuid, name constraints) is not included.

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 clear verb and resource: '修改 PCB 名称' (modify PCB name), and the signature `modifyPcbName(pcbUuid, pcbName)` reinforces the operation. The resource (PCB) is distinct from the many sibling modifiers like board_name, panel_name, project_name, and schematic_name, so an agent can tell it apart without opening sibling 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?

No guidance is given about when to use this tool versus alternatives such as modify_board_name or modify_panel_name. It does not mention prerequisites, how to obtain the pcbUuid, or whether a specific window/document must be active. The distinction is left entirely to the tool name and implicit resource understanding.

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?

There are no annotations, so the description carries the full burden. It does disclose that a failed copy returns undefined, which is helpful, but it doesn't mention side effects (e.g., whether the original project is modified, if permissions are needed, or if the copy is synchronous). The description is minimal and lacks behavioral depth beyond the basic return value.

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 concise: a function signature line and a brief Chinese summary, followed by return value explanation. It is front-loaded with the operation name and parameters. While efficient, it lacks explanatory sentences that could provide context, but it earns a 4 for being tightly packed without 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?

For a copy operation, the description covers the essential: what it does, the required parameter, and the return value (including failure case). However, it omits details about the scope of the copy (e.g., does it copy all associated schematics/boards?), potential errors beyond undefined, and any prerequisites like the source project existing. Given no output schema or annotations, it is adequate but leaves gaps an agent might need to handle.

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 description explicitly lists all five parameters with their types and names (sourceProjectUuid, targetTeamUuid, targetFolderUuid, newProjectFriendlyName, newProjectName), which is essential because the input schema only provides 'args' and 'windowId' without describing individual parameters. This adds significant meaning beyond the schema, making the parameter roles clear even if their exact semantics are not detailed.

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 operation: copying a project via dmt_Project.copyProject, and mentions it returns the new project UUID. The verb 'copy' and the resource 'project' are explicit, and the Chinese phrase '复制工程' reinforces this. However, it doesn't differentiate from siblings like create_project or move_project, though the name itself is fairly self-explanatory.

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 provided on when to use this tool instead of alternatives. There is no mention of prerequisites, context, or typical scenarios. The description only states the function signature and return behavior, leaving the agent to infer when copying is appropriate.

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 carry the full burden. It discloses the return value (UUID or undefined on failure) but says nothing about side effects, required permissions, whether the project is opened, or any other behavioral context. For a creation mutation, this is a significant gap.

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 extremely terse—just a signature and a one-line Chinese description of the return behavior. It's concise and front-loaded with the signature, but the language (Chinese) and lack of explanatory prose may reduce clarity for non-Chinese agents, though the core info is present.

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 schema's lack of parameter detail and no annotations, the description provides the signature and return semantics, which is adequate for a basic creation call. However, it omits details like whether the teamUuid or folderUuid are required, what collaborationMode values are accepted, and any post-creation behavior, leaving some ambiguity.

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 description lists all six function parameters with their types (projectFriendlyName, projectName, teamUuid, folderUuid, description, collaborationMode) via the signature, which adds meaning beyond the schema's opaque 'args' array. It clarifies the argument order and optionality, substantially helping an agent construct the call.

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 the tool creates a project ('创建工程') and provides the full function signature, which makes the purpose clear. It doesn't differentiate from sibling creation tools (e.g., create_board, create_pcb), but the verb 'create' and the project-specific name are explicit enough.

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 about when to use this tool versus alternatives like eda_dmt_project_copy_project or eda_dmt_board_create_board. There are no prerequisites, context cues, or exclusions mentioned, leaving the agent to infer from the name alone.

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 full burden. It discloses the return type (boolean success), but omits critical behavioral details: deletion is likely permanent and destructive, may affect associated documents, and may require confirmation. The word 'delete' implies destructiveness, but the description does not state the scope or reversibility.

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?

Three short lines deliver the signature, purpose, and return meaning with no filler. The 'returns' line slightly duplicates the -> boolean, but it adds semantic value by clarifying that the boolean indicates success, so the redundancy is minor.

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 destructive mutation with no annotations and no output schema, the description is under-specified. It does not state that projectUuid is required, how to obtain it, whether deletion is permanent, or what side effects occur on associated data. An agent would need to infer these from the name and sibling tools.

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 only describes args as a generic array and windowId; it does not define the actual parameters. The description's signature 'deleteProject(projectUuid: string)' supplies the essential parameter name and type, without which the agent could not construct a valid call. This fully compensates for the opaque schema sub-structure.

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 the operation explicitly: 'dmt_Project.deleteProject(projectUuid: string)' and '删除工程', clearly identifying the action (delete) and resource (project). It does not explicitly contrast with sibling deletion tools, but the resource name provides enough distinction. The function signature adds precise technical clarity.

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 on when to use this tool vs alternatives. There is no mention of when deletion is appropriate, prerequisites such as obtaining the project UUID, or situations where a different tool (e.g., move_project or modify) should be used. The description only states what the tool does, not when to invoke it.

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 burden. It discloses the mutual exclusivity of teamUuid and folderUuid and the precedence rule, which is valuable. However, it doesn't state that this is a read-only operation, nor does it mention any potential performance implications for large numbers of projects, or that it returns a list of UUID strings only. The description adds some behavior but not full transparency.

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 reasonably concise, using bullet points for the remarks, which improves readability. The signature line is useful. Some redundancy between the signature and the Chinese description, but overall it's efficient. Front-loads the main purpose before details.

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 list fetch with optional filters, and the description covers the filter semantics, mutual exclusion, and return type (array of UUIDs). No output schema exists, but the return type is stated in the signature. It's complete enough for an agent to call correctly, though it could mention that workspaceUuid scopes the team/folder, which it does.

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 input schema provides placeholder 'args' array and windowId, with no real parameter details. But the description names the actual parameters teamUuid, folderUuid, workspaceUuid and explains their meaning and constraints. This goes beyond the schema, which has 100% coverage but is generic. The description adds the semantics, but could be more detailed on types or examples.

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 that it retrieves all project UUIDs, with optional filtering by team or folder. The function name and signature also align with this purpose. It is distinguished from siblings like get_project_info and get_current_project_info by explicitly being a bulk fetch of UUIDs, though it doesn't 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?

The description provides clear usage context: when teamUuid is specified, get projects under that team; when folderUuid specified, under that folder; workspaceUuid further scopes. It also specifies that teamUuid and folderUuid are mutually exclusive, with folderUuid taking precedence if both given. It doesn't explicitly say when not to use it, but the when-to-use is clear enough.

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