Skip to main content
Glama
WYRE-AI

cipp-mcp

by WYRE-AI
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

cipp_list_mailbox_usage

Report mailbox and online-archive sizes across a tenant, largest first, with tenant-wide totals. Identify who is near quota and how much Exchange storage is used.

Instructions

Report mailbox and online-archive sizes across a tenant, largest first, with tenant-wide totals. Each mailbox reports bytes used, a human-readable size, item count, quota and percent-of-quota, for both the primary store and the archive. Answers 'who is near quota', 'which mailboxes need archiving', and 'how much Exchange storage does this tenant use'. Sizes come from CIPP's reporting database, which must have been synced — the live Exchange query carries no size data at all. For one mailbox, or when the cache is unavailable, use cipp_get_mailbox_usage.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoNumber of mailboxes to return (default 50, maximum 1000). The summary totals always cover every mailbox in the tenant, not just the ones returned — including `nearQuotaCount`, how many mailboxes sit at or above `nearQuotaPercent` of their quota, which answers the "who is about to stop receiving mail" question without reading a single row.
sortByNoOrdering, largest first. `mailboxSize` (default) ranks by the primary store, `archiveSize` by the online archive, `totalSize` by the two combined, and `percentOfQuota` by how full the primary store is relative to its quota — the one to use when hunting for mailboxes about to stop receiving mail.
minSizeGBNoOnly return mailboxes whose primary store and archive together reach this size in GB. Omit to return every mailbox.
tenantFilterYesTenant domain name or ID to scope the operation. Use 'allTenants' to target every managed tenant.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.8.0

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so exceptionally well, disclosing that sizes come from CIPP's reporting database, require a sync, and that the live Exchange query carries no size data at all. It also reveals the cache-unavailable failure mode and routes to a fallback.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences with no filler: the first two define output, the third gives user intent, and the fourth gives the data-source caveat and alternative. Key scoping ('across a tenant, largest first') is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description compensates by listing per-mailbox fields, tenant-wide totals, nearQuotaCount, cache dependency, and the sibling tool. Together with the detailed schema, an agent has enough to select and invoke this correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool description itself adds no parameter-level detail, but schema description coverage is 100% and the schema already explains limit, sortBy, minSizeGB, and tenantFilter in detail, so the baseline applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

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: 'Report mailbox and online-archive sizes across a tenant, largest first, with tenant-wide totals.' It also lists the concrete questions it answers and clearly distinguishes itself from the single-mailbox sibling cipp_get_mailbox_usage.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly names when to prefer the alternative: 'For one mailbox, or when the cache is unavailable, use cipp_get_mailbox_usage.' It also gives the cache/sync precondition, so an agent can decide whether this tool will produce meaningful data.

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

Deploy Server

Other Tools