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

With no annotations, the description carries the full burden. It discloses that the token is the sole credential, that the operation is a read (reveals preference state), and explicitly limits the scope ('nothing else — no email address, no CRM record'). This goes beyond the schema, though it doesn't mention error behavior or response format.

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 description is two sentences with zero redundancy. It front-loads the primary action and follows with the key contextual constraints. Every word contributes meaning; there is no 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 single-parameter read tool with no output schema, the description covers the essential aspects: what it does, what credential is needed, and what it returns (preference state) and what it doesn't. It could be more explicit about the response format or possible errors, but for its simplicity, it is sufficiently 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?

The schema already describes the token as 'Signed preference token' (100% coverage). The description adds crucial semantic value by emphasizing 'The token IS the credential,' which clarifies that the token is not just a parameter but an authentication artifact. This enhances understanding beyond the 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 description clearly states the action ('Read preference') and the resource ('preference') with a specific mechanism ('signed capability'). It also distinguishes the tool by clarifying what it does NOT reveal ('no email address, no CRM record'), which sets it apart from many sibling CRM and contact tools. The purpose is unambiguous.

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?

The description implies usage context by stating 'The token IS the credential' – the agent must possess a valid signed token. However, it does not explicitly contrast with siblings like preference_unsubscribe or preference_token_create, nor does it state when not to use this tool. The guidance is implied but not explicit.

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