编辑节点属性并读回验证

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

Annotations already establish that the operation is mutating and destructive (readOnlyHint=false, destructiveHint=true), so the description aligns with them. It adds one useful behavioral trait beyond the annotations: the tool does not merely set properties but also reads back to verify the change. However, it does not disclose what side effects are involved, whether changes persist, or what happens to pre-existing properties.

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 very short and front-loaded with the core action, and every word is purposeful. But it is essentially identical to the title and provides no elaborative structure, so it reads as under-specified rather than succinctly structured.

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 destructive 6-parameter tool with a nested object, no output schema, and many related siblings, the description is incomplete. An agent cannot infer the return format, how read-back verification is exposed, the meaning of optional parameters, or the scope of the destructive behavior. The description alone is not enough to call this tool correctly in varied contexts.

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 description coverage is 0%, so the description must compensate for the six parameters, but it only gestures at the 'properties' object via '节点属性' and leaves nodeId, projectId, instanceId, operationId, expectedRevision, and runtimeInstanceId entirely unexplained. This is a significant gap for a tool with a nested properties object and optional concurrency-related parameters.

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?

Tautological: description restates name/title.

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?

No guidance is given about when to choose this tool over alternatives like cocos_node_query, cocos_node_create, or cocos_component_set, nor are exclusions or prerequisite conditions mentioned. The description only describes the action itself without any decision context.

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