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

Annotations already cover safety (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds a genuine semantic constraint — 'the consumer is never the counterparty' — and flags auditor as read-only, consistent with the annotations. It does not disclose auth requirements or what happens on an unrecognized actor, so it goes only modestly beyond the structured fields.

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?

Very compact and front-loaded with the value list, with no filler sentences. The fragmentary grammar ('Who is asking? maker, ...') is terse to the point of being slightly cryptic, but nothing is wasted.

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?

An output schema exists, so return values need not be explained, and the actor-class enumeration covers the input domain. However, for an identity-resolution tool the description omits when resolution is required, what happens for an unrecognized or unauthenticated caller, and how it relates to the resolve_* siblings, leaving real gaps.

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 schema has one parameter (actor_class) with 0% description coverage and no enum, so the description carries the full burden — and it effectively supplies the value set: maker, brand_owner, agency, distributor, retailer_media_team, auditor. It does not name the parameter or explain format constraints, but the enumeration substantially compensates for the empty schema.

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 name 'resolve_actor' plus the enumeration of actor classes implies the tool identifies the calling party's role, but the description never states the verb or the resource explicitly — 'Who is asking?' is a rhetorical question, not a purpose statement. It does not distinguish itself from the sibling resolve_* tools (resolve_gtin, resolve_jurisdiction), which an agent must differentiate.

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?

There is no explicit when-to-use or when-not-to-use guidance, and no alternative tool is named. The parenthetical '(read only)' on auditor hints at a read-only path but does not tell the agent when to call this versus check_eligibility or a2a_handoff.

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