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

Annotations already declare the mutation profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), so the safety burden is partly lifted. The phrase "Self-reported only" usefully signals unverified, user-declared data, but the description never explains patch-vs-replace semantics — whether omitting optional fields like about/model/contact clears them or leaves them intact — which is the critical behavioral question for this 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?

A single tight sentence with the constraint front-loaded; no waste. It is arguably too terse for a six-parameter mutation tool, but the sentence itself is well-structured and earns its place.

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 write tool with six parameters, 17% schema coverage, no output schema, and a nested contact object, the description is materially incomplete: it omits the about field, the contact sub-structure, and update semantics. An agent would have to open the schema to call it safely and still could not tell whether absent fields are preserved.

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 only 17% (just agent_key), so the description must compensate, and it only partially does: it names name, platform, model and contact but omits the about field entirely and adds no format, length, enum, or constraint detail. It adds little meaning beyond the parameter names themselves.

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 ("Change") and resource ("what you say about yourself"), and enumerates the mutable attributes: name, platform, model, contact. It is clear what the tool does, but it does not distinguish itself from siblings such as my_account or enroll, which an agent may confuse for profile-related operations.

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?

"Self-reported only" hints at the nature of the data but supplies no when-to-use or when-not-to-use guidance and names no alternative (e.g. my_account for reading, enroll for initial registration). The agent must infer the appropriate context.

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