Search for 3D models in the EDA library by keyword, with optional filters for library UUID, classification, and pagination.
lib_3DModel.search(key: string, libraryUuid?: string, classification?: ILIB_ClassificationIndex | Array, itemsOfPage?: number, page?: number) -> Promise<Array> 搜索 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?
With no annotations, the description carries the full burden, but it only says the tool searches and returns a list of 3D model properties. It does not disclose crucial behavioral details such as default library scope, pagination behavior/limits, classification filtering semantics, or whether the operation is strictly read-only, leaving an agent to infer these from 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 and front-loaded with the most important technical information. The Chinese summary and return line add some redundancy with the signature, but there is no fluff or irrelevant 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?
This is a search tool with five parameters and no output schema, so the description should explain search semantics, parameter meanings, and the shape of returned items. It provides only a signature and a minimal Chinese summary, omitting what 'key' matches, how classification is used, what the default library scope is, and what fields the returned items contain. This is insufficient for reliable agent 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 signature in the description adds meaningful parameter information beyond the generic args array: it names key, libraryUuid, classification, itemsOfPage, and page, with optionality and types. However, it does not explain the meaning of key, the ILIB_ClassificationIndex structure, or pagination defaults, so it is not fully self-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 clear verb and resource: 'lib_3DModel.search' plus '搜索 3D 模型' ('search 3D model'), and the return type Promise<Array<ILIB_3DModelSearchItem>> makes the outcome concrete. It is distinguishable from sibling 3D-model CRUD tools like eda_lib_3_dmodel_create/delete/modify, though it does not explicitly differentiate itself from the other lib_*_search 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 such as eda_lib_symbol_search, eda_lib_footprint_search, eda_lib_device_search, or eda_lib_cbb_search. The only usage signal is the tool name and the one-line Chinese purpose; no exclusions, preconditions, or alternative-selection hints are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.