Retrieve all properties of a library symbol by its UUID, optionally scoped to a specific library, to inspect or verify symbol attributes in EasyEDA Pro.
lib_Symbol.get(symbolUuid: string, libraryUuid?: string) -> Promise<ILIB_SymbolItem | undefined> 获取符号的所有属性 returns: 符号属性
| 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 carries the full burden of behavioral disclosure. The only behavioral signal is the signature's return type 'Promise<ILIB_SymbolItem | undefined>', which hints the call may return undefined when a symbol is not found. Nothing is said about what 'all properties' includes, error behavior, or side effects. This is minimal 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: a signature line plus a short Chinese purpose phrase and return note. It is front-loaded and contains no filler. It could arguably be tightened, but it is appropriately minimal for a simple getter.
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 low-complexity getter with two parameters, the signature plus one-line purpose covers the core contract. There is no output schema, so the return type in the signature is the main completeness signal. However, with no annotations and no usage context (which libraryUuid refers to, what the symbol item contains), it leaves moderate 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 coverage is reported at 100%, but the args array items are empty objects ({}), so the schema itself documents nothing about symbolUuid or libraryUuid. The description compensates by listing the parameters in the function signature with names and types. This adds real meaning beyond the schema, but the optionality semantics of libraryUuid are not explained, so it is not a 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 states a specific verb ('获取' / get) and resource ('符号' / symbol), with a function signature that names the return type (ILIB_SymbolItem). Purpose is clear — retrieve all properties of a library symbol. However, it does not differentiate itself from the sibling eda_lib_symbol_get_render_image, which is also a getter on symbols, 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?
There is no guidance on when to use this tool versus alternatives. Siblings such as eda_lib_symbol_get_render_image, eda_lib_symbol_search, and eda_lib_symbol_search_by_properties exist but are never mentioned, nor is any selection criterion given. The agent must infer usage entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.