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

Even though readOnlyHint and idempotentHint annotations already establish the safety profile, the description adds important behavioral detail: the `legs` array structure, the absence of a campaign-level ruleset field, and the difference between the default summary shape and `detail: 'full'`. This is exactly the kind of non-obvious behavior an agent needs to interpret results correctly.

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 dense but every sentence earns its place: purpose, structural gotcha, default output, and full-output behavior are all covered in two sentences. The most important selection predicate is front-loaded, and no content is wasted on restating the name or obvious schema details.

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 only one optional parameter, strong annotations, and an output schema present, the description covers everything needed to select and invoke the tool correctly: ownership filter, response shape, and the key `legs`-array nuance. Nothing essential is missing for an agent to make an informed call.

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 coverage is 100%, and the schema already describes the `detail` enum. The description goes further by explaining what the summary shape contains (counts plus `playId`/`vaultId` roster pairs) and what full shape adds (raw ObjectId arrays, full descriptions, X-card history). This gives the agent concrete expectations for each parameter value beyond the schema text.

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 campaigns where the calling user is the DM/owner.' This clearly distinguishes the tool from siblings like play_list_participated_campaigns, which would include campaigns the user merely participates in. The title and description align without being tautological.

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 clearly defines the selection predicate — campaigns the calling user owns — and explains the summary vs. full output choice, giving the agent enough context to know when it applies. However, it does not explicitly contrast itself with sibling alternatives such as play_list_participated_campaigns or play_get_campaign, so it stops short of full when-to-use/when-not-to-use guidance.

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