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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description's 'Read-only' adds little. However, 'order once paid' reveals a meaningful behavioral nuance: the order field appears conditionally after payment. This goes beyond the annotations and helps set expectations.

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 a single, tight sentence with the core concept front-loaded ('Current state of a checkout session') and a concise parenthetical list of contents. No filler words; every element earns its place.

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 simple read-by-id tool, the description combined with annotations and an output schema is largely complete. It covers the return content and a conditional behavior. The main gaps are the lack of parameter guidance and any mention of alternative tools, but these are minor given the tool's low complexity.

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 zero description coverage and the tool description does not mention checkout_session_id at all. While the parameter name is self-explanatory, the description fails to explain how to obtain it, what format it follows, or any relationship to the checkout lifecycle. The description adds no value beyond the schema's type and length constraints.

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 title and description clearly state the tool reads a checkout session, enumerating specific content (status, line items, totals, messages, order once paid) and explicitly marking it read-only. This distinguishes it from sibling mutations like create_checkout, update_checkout, cancel_checkout, and complete_checkout.

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 when the current state of a checkout session is needed, but it does not explicitly compare with alternatives or state when not to use it. There is no direct routing to a sibling for write operations, though the read-only label provides basic context.

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