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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the bar is lower, yet the description still adds substantial context: the marketing:read scope requirement, that unconfigured plans report as disabled, that no activation or scope grant occurs, and that request caps are not a monetary spend guarantee. Provider caveats (Gemini/Perplexity require integrations) further preempt misreading the returned plan.

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 core purpose is front-loaded in the first sentence and the caveats follow in order of importance. It is dense and a single long block rather than separated concerns, and the closing budget/integration caveats are marginal for selection, but no sentence is truly filler.

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 no output schema, the description must carry the return-value burden, and it does by enumerating the configuration fields the plan exposes. For a zero-parameter, annotation-rich read tool this is close to complete; only an explicit pointer to the mutating/measurement sibling would improve it.

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 no parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description instead characterizes what the parameterless read returns (cadence, questions, locale, identity, monthly request cap), which is a useful substitute for argument detail.

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 opens with a specific verb and resource: 'Read the current tenant owner-confirmed automatic OpenAI API measurement plan and native Settings address.' That is clearly distinguishable from measurement-performing siblings, reinforced by 'this tool never activates... or causes a paid probe.' It stops short of naming the sibling an agent should use to actually run a measurement, so sibling routing is implied rather than explicit.

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 establishes clear preconditions and scope: 'marketing:read only', 'Unconfigured plans are disabled', and the explicit exclusion that it never activates plans, grants scopes, or triggers paid probes. What is missing is positive routing — it never says 'to start or change the plan, use X instead', leaving the agent to infer that from sibling names alone.

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