Retrieve detailed properties of a schematic by its UUID to access design data. Use this to fetch schematic attributes for analysis or automation.
dmt_Schematic.getSchematicInfo(schematicUuid: string) -> Promise<IDMT_SchematicItem | undefined>
获取原理图的详细属性
returns: 原理图的详细属性，如若为 undefined 则获取失败
| 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 present, so the description must carry the behavioral burden. It discloses the return type (Promise<IDMT_SchematicItem | undefined>) and states that undefined means failure, which is useful. However, it does not mention prerequisites like the schematic needing to be open, or any side effects (likely none for a getter, but not stated).
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 three short lines covering signature, purpose, and return semantics. It avoids fluff, though the Chinese phrasing might be less universally readable, and the purpose line is not front-loaded in English.
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, the description explains the return value and failure indicator. It does not address potential edge cases like an invalid UUID or the need for an active window when windowId is omitted. The lack of differentiation from many sibling tools also leaves 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?
Schema coverage is 100% but the descriptions are generic: args is an array in official signature order, and windowId targets the active window. The description's signature adds meaning by identifying the schematicUuid as the required argument, but it does not detail how to pass it inside the array or clarify the order beyond the signature.
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 gets detailed schematic properties ('获取原理图的详细属性') and provides the function signature with a schematicUuid parameter, making the purpose clear. It is specific enough to distinguish from listing tools like get_all_schematics_info, though it does not explicitly contrast with 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?
There is no guidance on when to use this tool versus alternatives such as get_current_schematic_info or get_schematic_page_info. The description only explains what it does without contextual triggers or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.