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

Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds useful behavioral specifics: it is limited to one subject, includes remaining MCP previews, does not return billing details, and does not change access. These details reinforce the annotations and give the agent a clearer picture of side effects and limits.

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?

Two tight sentences with no filler. The first states the core function, and the second adds valuable negative guarantees. Every clause earns its place, and the key scope limitation is front-loaded.

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 an output schema present, return-value details are covered elsewhere. For a small read-only tool with one parameter, the description adequately covers purpose, scope, and exclusions. The main gap is the weak documentation of subjectSlug, but that was already penalized under parameter semantics.

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 description coverage is 0%, so the description must compensate for the single subjectSlug parameter. It only loosely indicates 'one subject' without explaining what a subjectSlug is, where to obtain one, or what format it should take. The parameter name is somewhat self-explanatory, but the description does not provide enough semantic detail for an agent unfamiliar with the domain.

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 names a specific verb ('Explains') and resource ('which features this account can use for one subject and its remaining MCP previews'), and pairs it with clear exclusions: no billing information and no access changes. It distinguishes the tool from the many get_my_* siblings by focusing on account entitlements and previews rather than progress or history.

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 conveys the tool's scope—used to check per-subject feature access and MCP previews—and explicitly states that billing information is not returned and access is not changed. However, it provides no explicit 'when to use vs. alternatives' guidance or mention of sibling tools, so an agent must infer when this is the right get_my_* choice.

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