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

The readOnlyHint annotation already establishes this is a safe, non-mutating call, so the description's main added value is naming the returned payload (profile, sites, account info) — helpful since there is no output schema. Beyond that it adds little behavioral context: no mention of auth scope, whether 'current user' derives from the credential, or result shape. Adequate but not rich relative to the low bar set by annotations.

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?

Two short sentences, front-loaded with the core capability and followed by the routing instruction, with no filler. The phrase 'account info' is somewhat vague and partially overlaps 'current user profile', a small redundancy that keeps it below a 5.

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 zero-parameter identity tool with an annotation covering safety and no output schema, the description does the necessary work by enumerating what comes back and telling the agent to call it first. It could be stronger by distinguishing itself from the account-oriented siblings, but nothing essential to invoking it correctly is missing.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-parameter tool applies. The description correctly implies no inputs are needed by describing it as an identity-discovery call.

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 uses a specific verb ('Get') and names concrete resources: current user profile, accessible sites, and account info. It is clearly distinguishable from most siblings, but it does not explicitly differentiate from the closely related get_account_context and get_x_accounts tools, which an agent could easily confuse it with.

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?

It gives explicit ordering guidance — 'Call this first to discover which sites you can manage' — which is exactly the kind of sequencing instruction an agent needs. However, it does not name alternatives like get_account_context, so the agent gets a when-to-use but not a when-not-to-use signal.

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