Retrieves 3D shell files (STL, STEP, OBJ) for PCB manufacture data. Use it to obtain enclosure geometry for design verification or visualization.
pcb_ManufactureData.get3DShellFile(fileName?: string, fileType?: 'stl' | 'step' | 'obj') -> Promise<File | undefined> 获取 3D 外壳文件 returns: 3D 外壳文件数据
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | 按官方签名顺序排列的JSON参数数组 | |
| windowId | No | 目标EDA窗口ID；省略时使用当前活动窗口 |
Changes observed during successful MCP inspections.
v2.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It does reveal the return shape 'Promise<File | undefined>', implying a possible undefined result when no file exists. But it says nothing about failure modes, whether the file is a download or in-memory object, side effects, or the window-targeting behavior implied by the windowId argument.
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 function signature, followed by two terse lines. Minor redundancy exists: '获取 3D 外壳文件' and 'returns: 3D 外壳文件数据' restate the same concept, and the English/Chinese mix adds slight noise, but no sentence is wasted.
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 no output schema, no annotations, an opaque args schema, and a very large sibling set, the description is under-specified. It covers the core operation and parameter names, but an agent cannot determine when to select this tool among the many manufacture-data getters, what happens when fileName is omitted, or how the returned File is delivered.
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's args array has 'items': {} with no element schema, so the individual parameters would be opaque to an agent. The description's embedded signature compensates by naming fileName (string) and fileType with the explicit 'stl' | 'step' | 'obj' enum. This adds real meaning 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 states a specific verb and resource: '获取 3D 外壳文件' (get 3D shell file), backed by the signature pcb_ManufactureData.get3DShellFile. This is a clear, unambiguous purpose. However, it does not differentiate from siblings such as eda_pcb_manufacture_data_get3_dfile or the many other get_*_file tools, and part of the description is essentially a transliteration of 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?
No guidance is given on when to use this tool versus the ~20 sibling manufacture-data export tools (gerber, bom, dxf, altium, etc.). The fileType enum ('stl' | 'step' | 'obj') implies a 3D-shell export scenario, but there is no explicit when-to-use, when-not-to-use, or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.