eda_lib_footprint_modify

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 one important behavior: setting properties to null clears them. It also mentions the return type (boolean success). However, it omits details like whether the footprint must exist, what happens on failure, or any side effects. 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 compact but somewhat awkwardly structured, mixing a code-like signature with a Chinese remark. It's not overly long, but the flow is not ideal for quick scanning. Front-loading the signature is efficient, though.

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 provides the signature, parameter types, and a key behavioral note, but lacks explanation of what each parameter represents (e.g., classification, otherProperty semantics). It doesn't mention prerequisites or side effects. For a modify tool with multiple parameters, this is partially complete but leaves gaps for an agent to infer.

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 function parameters with types, which adds significant meaning beyond the generic input schema (which only has 'args' and 'windowId'). It clarifies that footprintUuid and libraryUuid are required, and explains the null-clearing behavior for properties. This compensates well for the schema's lack of inner parameter details.

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 footprint) and provides the function signature with parameters, distinguishing it from sibling tools like eda_lib_symbol_modify. It's specific to footprint modification, but it doesn't elaborate on what aspects of the footprint can be changed beyond listing parameters.

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 doesn't mention conditions for use, exclusions, or recommend related tools. The context of modifying an existing footprint is implied but not explicit.

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