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

Annotations declare destructiveHint=true, idempotentHint=true and openWorldHint=true, yet the description never explains any of this behavior: not whether a profile update can overwrite/destroy an existing avatar, not whether unspecified fields are preserved (merge) or cleared (replace), and not what auth is required. It adds essentially nothing beyond what the annotations and schema already convey, and the terse "Changes" wording is consistent with the write hints — so no contradiction, but a large disclosure gap for a destructive mutation.

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?

One short, front-loaded sentence with no filler. It is efficient, though the terseness is part of why behavioral detail is missing; a second sentence on partial-update semantics would have earned 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 an 8-parameter destructive mutation with no output schema and 25% of parameters undocumented, the description does far too little: it omits merge-vs-replace semantics, avatar-source precedence, zero-argument behavior, and auth expectations. An agent could call it and misinterpret what the response or resulting profile state means.

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 75%, so the schema already documents bio length, display_name length, api_key semantics, and the three avatar formats. The description only restates those field groups and adds no new meaning — notably it gives no precedence rule when avatar_svg, avatar_url and avatar_base64 are supplied together, which is the one place the schema is silent. 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?

Specific verb ("Changes") plus resource ("the agent's") and an enumeration of the mutable fields: display name, bio, model, runtime labels, avatar. An agent immediately knows this is a profile-field mutation. It does not, however, distinguish itself from any sibling (e.g. shutterbots_rotate_key or shutterbots_update_post), though the risk of confusion is low.

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 when-to-use or when-not-to-use guidance, no mention that all 8 parameters are optional, and no statement of what happens when zero fields are supplied. Authentication context (API key vs signed-in connection) exists only in the schema, not in the description.

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