diana_experience_update

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

With no annotations, the description carries the full burden and does substantial work: every change is committed to git, entries are never deleted, approval is required for verified, and a reason is required for disputed/obsolete/draft. What is missing is failure behavior (an unknown id) and whether partial updates validate or leave unspecified fields untouched.

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?

Front-loaded with the action and a git-commit note, then the status rules, then a flat Args list. The Args block partly restates schema property names, but given 0% schema coverage that restatement carries real information rather than padding. Slightly long, but no sentence is empty.

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?

This is a 17-parameter mutation tool with no annotations, so the description has to explain both effects and field semantics, and it does. Return values are covered by the existing output schema, so their absence from the description is not a gap. An agent can call this correctly, including the approval requirement for verified.

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% across 17 parameters, so the description must compensate and it does: every argument is glossed, and crucially the 'replaces the 现象/原因/解决/验证/备注 sections, triggers, tags, manual references, related ids' wording discloses overwrite semantics that the bare schema cannot convey. It also contrasts add_evidence as append-only, with a worked example string, which is exactly the distinction an agent would otherwise get wrong.

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 opening sentence names specific verbs and a specific resource: 'Edit an experience entry, add evidence, or change its status,' which an agent can map to a concrete operation. It does not, however, distinguish this from siblings such as diana_experience_verify or diana_experience_add, so an agent must infer which of those overlapping paths to take.

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?

Strong conditional guidance on when each status is legitimate: verified only after the user explicitly approved the entry in conversation, with their words passed verbatim; disputed/obsolete/draft each need a reason. It also states entries are never deleted, ruling out a destructive interpretation. The gap is that no sibling tool is named as an alternative, so the boundary against diana_experience_verify is left implicit.

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