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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, and the description adds substantial behavior beyond them: it returns null when none is pending, describes the analysis inputs, the single-change proposal, the result contents (findings with evidence, current vs proposed text, before/after replays), and explicitly states nothing is applied. This is rich, non-obvious behavioral disclosure.

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 four sentences with no filler. It front-loads the core action and null behavior, then adds necessary context about what a checkup is and what the result contains. Every sentence contributes distinct information.

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?

Given the simple single-parameter schema, rich annotations, and no output schema, the description is complete enough for an agent to call this correctly. It explains the return value, the null case, the result shape, and the non-applying behavior, so no critical operational information is missing.

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 only parameter, workspaceId, is fully described in the input schema, including the user-key vs workspace-key nuance. The description does not add new parameter-level details, so the schema carries the semantic weight; therefore 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?

The description starts with a specific verb and resource: 'Get the workspace's open draft checkup proposal,' and adds the null-when-pending behavior. It clearly distinguishes this from accept/run/reject siblings by describing what the checkup is and noting that nothing is applied until campaignstack_accept_draft_checkup.

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 makes clear this is the read-only retrieval counterpart and explicitly references accept_draft_checkup as the mutating follow-up. It does not fully enumerate when to prefer this over run_draft_checkup or reject_draft_checkup, but the read-only framing plus 'open draft checkup proposal' provides strong contextual guidance.

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