cipp_get_mailbox_usage

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

No annotations are present, so the description carries the behavioral burden. It meaningfully discloses that this tool reads live from Exchange, bypasses cached report data, and returns real sizes when names are hidden. It doesn't explicitly state read-only behavior or mention latency/rate limits, but 'reads live' and 'Report' sufficiently convey the safety profile for this tool.

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 sentences and no filler. The core capability is front-loaded in the first sentence, and the differentiating behavior is packed efficiently into the second. Every word contributes useful 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?

For a single-mailbox read tool with two fully documented parameters and no output schema, the description is nearly complete: it enumerates the returned types (sizes, item counts, quotas, percent-of-quota) and explains why live data matters. Minor omissions like error handling or performance implications do not materially reduce callability.

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 input schema already documents both required parameters at 100% coverage, including the no-allTenants restriction. The description reinforces the single-mailbox scope but adds little beyond what the schema already states, so the baseline of 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?

Description names the exact resource ('primary mailbox size and online-archive size for a single mailbox') and the action ('Report'), with specific returned fields. It also explicitly contrasts itself with cipp_list_mailbox_usage, making the distinction clear without needing to inspect schemas.

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 names the sibling alternative (cipp_list_mailbox_usage) and gives concrete conditions for choosing this tool: live Exchange reads, no CIPP report-cache sync, and accurate sizes even for tenants that conceal names in usage reports. The 'single mailbox' phrasing also implies the list sibling for bulk needs.

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