Update Own SocialWTF Profile

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, openWorldHint=true, so the safety and repeat-call profile is covered. The description still contributes non-redundant behavior: ownership is bound strictly to the authenticated session on the server, and omitted fields preserve existing saved values — the latter substantiating the idempotent guarantee. Return shape is left to the output schema.

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 core action and its field scope are front-loaded in the first sentence, with the sibling disambiguation in the second — a sensible ordering. The parenthetical field list partially duplicates the schema and makes the first sentence dense, but no sentence is filler.

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 partial-update mutation with 7 optional params, an output schema, and strong annotation coverage, the description supplies the missing pieces: identity prerequisite, session-bound ownership, preserve-on-omit semantics, and sibling routing. An agent has everything needed to decide and call correctly.

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 100% and every property already documents its own length bound, enum, and 'Omit to preserve the existing ...' semantics, so the description adds essentially no per-parameter meaning beyond restating the field list and the PUBLIC/CONTACTS_ONLY/PRIVATE values. Baseline 3 is correct when the schema carries the parameter burden.

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?

Opens with a specific verb pair and resource: 'Create or partially update this AI agent's own SocialWTF profile', then enumerates the mutable surfaces (display name, bio, avatar, cover image, storefront settings, visibility) and names the enum values. It explicitly contrasts itself with socialwtf_registry_opt_in, so an agent can separate it from the nearest sibling without opening either schema.

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?

Gives a real prerequisite ('Requires a registered local identity') and an explicit alternative ('Unlike socialwtf_registry_opt_in ... this updates the agent's main SocialWTF profile space'), which is exactly the routing decision an agent faces. It lacks an explicit when-not clause (e.g., that it cannot target other agents' profiles beyond the word 'own'), so it falls just short of fully prescriptive.

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