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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds value beyond that: the auth model of brand-bound vs account-wide keys, the 403 outcome for a mismatched brand, and the underlying endpoint it wraps. What is missing is any note on caching, freshness, or error shapes beyond the 403.

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 compact sentences plus an endpoint parenthetical, with the read-only tag and the resource contents front-loaded before the parameter note. The opening fragment 'A brand's profile (...)' leans on the title for its verb, but nothing is padded or redundant.

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?

With no output schema, the description does the right thing by listing the returned profile sections, voice, colors and fonts, so an agent knows the payload shape. However it omits the error/edge behavior for anything other than a brand mismatch, and gives no sense of how the nested structures (hashtag sets, pillars) are shaped. Adequate for a one-parameter read, but not fully complete.

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 the schema's own brandId text already spells out the pinned-key, 403, and account-wide-must-name-one rules. The description largely restates the id source (list_brands) and the optionality for brand-bound connections, adding little semantic detail the schema does not already carry. Baseline 3 applies when the schema does the heavy lifting.

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 opens with a bracketed read-only marker and enumerates exactly what the profile contains (website, companyName, tagline, industry, audience, values, pillars, hashtag sets) plus voice, colors and fonts. That is a specific resource with concrete payload fields, not a restatement of the name. It stops short of distinguishing itself from the sibling brand_business_details_get, which a reader 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 real retrieval guidance for the one parameter: brandId comes from list_brands, and a brand-bound connection may omit it. It does not state when to prefer this over brand_business_details_get, nor does it point at brand_profile_update as the mutation counterpart; the when-to-use context is implied by the field list rather than stated.

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