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

The annotations already cover read-only safety, but the description adds real behavioral context beyond them: calling it early can swallow the 401 that would otherwise start OAuth, and the response never contains raw tokens. This is a non-obvious side effect that an agent could not infer from the schema or annotations.

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?

It is front-loaded with the 'Use ONLY when' rule, and every sentence adds something useful. The example list and the long list of protected tools make it dense, but none of it is padding, since those lists are what make the routing rule actionable.

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?

Although an output schema exists, the description still briefly states the shape of the result (authenticated boolean, tier roles, wallet flag, no raw tokens), and it fully covers the routing and OAuth behavior that make this tool easy to misuse. Nothing an agent needs in order to call it correctly 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 tool takes zero parameters, so there is nothing to explain and the baseline is 4. The description correctly says nothing about inputs and instead spends its words on when to call the tool.

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 states a specific verb and resource: check whether the user is signed in to the XP marketplace. It clearly distinguishes this tool from all the protected siblings (account, my tickets, wallet, favorites, referral, order tools) and names exactly what state it reports.

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?

It gives an explicit when (the user asks directly, or after a tool returned AUTH_REQUIRED and the user wants a re-check) and an explicit when-not (no preflight before protected tools), naming the alternatives to call instead. The reasoning behind the exclusion — a 401 that gets swallowed and prevents the MCP client from triggering OAuth — is also given.

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