Get Mutation Result

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is largely given. The description does add real value with 'never automatically replays a mutation', clarifying that repeated polling has no side effects. It stays silent, though, on whether the call blocks or polls, what a pending mutation returns, and how timeoutMs affects behavior.

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?

Two sentences, front-loaded with the verb and resource, followed by the safety caveat. No filler, and the most important scoping detail (by mutationId) arrives first.

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?

With no output schema, the description does tell the agent what comes back: status, readback evidence, and verification. Combined with annotations covering the safety profile, the only meaningful omission is the polling/timeout behavior, which matters for a status-query tool with a 120s maximum timeout.

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 50%: mutationId is documented in the schema as 'returned during preparation', and the description only restates that it keys the query. timeoutMs is entirely undocumented in both schema and description, leaving the agent to guess whether it enables long-polling or just bounds the call; given the mid-range coverage, a baseline 3 is appropriate.

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 gives a specific verb ('Queries') and a concrete resource set: status, readback evidence, and verification of a mutation, keyed by mutationId. It is distinguishable from the prepare_* siblings because it is a retrieval step rather than a mutation, though it never names a specific sibling it complements or replaces.

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?

'any prepared or applied mutation' implies the tool is called after a preparation or application step, which is useful context. However, there is no explicit instruction such as 'call after easyeda_prepare_* or easyeda_confirmed_action', and no when-not guidance (e.g., what to do instead for DRC edit results, which has its own sibling).

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