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

Annotations already declare readOnly/idempotent/non-destructive, so the description focuses on what they cannot express: permission-scoped visibility for restricted members, a compact row-based return, and a conditional extra field (`websites_without_brand`) only present with `creative:generate`. That is real added context beyond the structured fields; it stops short of detailing the fields in a row, which matters somewhat since there is no 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?

Front-loaded with what the tool returns and the primary sibling alternatives, then the permission caveat and conditional return. Dense but every clause is actionable; the closing 'Make a client's work under THEIR brand' line is more workspace policy than tool guidance and is the one part that could be trimmed.

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 no-parameter read tool with a non-obvious permission model and no output schema, the description covers visibility scoping, result granularity, the conditional extra collection, and all relevant follow-up tools. Only the exact fields in a 'short row' are left unspecified, which is a minor gap for an agent choosing among brands.

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%, so both parameters are already documented; the description only restates that `query` filters by name (and notes it also matches websites). `user_goal` is never mentioned. With the schema doing the heavy lifting, the 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?

States a specific verb and resource ('List the Creative Studio brand workspaces this connection can see') plus the shape of the result ('one short row each'). It also distinguishes itself from siblings by naming get_brand and describe_brand_kit as the tools for a brand's full kit, so an agent can pick correctly without opening the schemas.

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 explicit routing: use get_brand or describe_brand_kit for full kit, get_site_brand for a website without a brand yet, create_brand for a client or pitch with no website. It also states the downstream contract ('use a returned id as brand_id on every other creative tool'), which is exactly the when-to-use information an agent needs.

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