Cooper Email

Get mail metrics

cooper_get_metrics

Read-onlyIdempotent

Use this when you need counts of mail over time, current usage, or bounce and complaint rates for this account. Read-only; requires auth and message_read. Inputs: kind (required; events, usage, or rates), inbox_id (optional; inbox id, username, or email), start and end (optional ISO-8601 timestamps; default the last 30 days; used by events and rates), period (optional; hour or day; default day; events only), types (optional comma-separated message.received, message.sent, message.bounced, message.complained; default message.received,message.sent; events only). events returns {object:"metrics", period, data:[{bucket_start, counts}]}. Buckets are UTC. received and sent follow messages.direction inbound and outbound. bounced and complained follow those labels and are zero when the label is absent. usage returns {inbox_count, message_count, thread_count, storage_bytes} and, when the key is not inbox-scoped and inbox_id is omitted, domain_count and workspace_count for this account only. storage_bytes is the UTF-8 size of text plus html plus attachment bytes. It is not the message body. rates returns {sent, bounced, complained, bounce_rate, complaint_rate}. Rates are 0 when sent is 0. A range over 90 days, or a start that is not before end, returns 400 invalid_range. A bad timestamp returns 400 invalid_date. A bad period returns 400 invalid_period. An unknown type returns 400 invalid_type. An unknown kind returns 400 invalid_kind. Another account's inbox, or a different inbox for an inbox-scoped key, returns 404 inbox_not_found. A key without message_read returns 403 permission_denied. A sub-account sees only its own mail, inboxes, domains, and workspaces. Held message bodies are not included.

Input Schema

Name	Required	Description
`end`	No	ISO-8601 end, exclusive. Defaults to now. The span from start to end cannot exceed 90 days.
`kind`	Yes	events for time buckets, usage for current totals, or rates for bounce and complaint rates.
`start`	No	ISO-8601 start, inclusive. Defaults to 30 days before end. Used by events and rates.
`types`	No	Comma-separated events series: message.received, message.sent, message.bounced, message.complained. Default message.received,message.sent.
`period`	No	Bucket size for events. hour or day. Default day. Ignored for usage and rates.
`inbox_id`	No	Inbox id (inb_…), username, or full email address on this account. Omit for the whole account. An inbox-scoped key is limited to its inbox.

Output Schema

Name	Required	Description
`object`	No	Object type name, such as list, message, or thread.
`period`	No	Time range the counts cover.
`domains`	No	Custom domain counts.
`inboxes`	No	Inbox counts.
`inbox_id`	No	Inbox id (inb_…) this object belongs to. Null when it applies to every inbox.
`messages`	No	Message counts, such as sent and received.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 3, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "Mail, inbox, and domain counts for the account or one inbox.",
+  "properties": {
+    "domains": {
+      "description": "Custom domain counts."
+    },
+    "inbox_id": {
+      "description": "Inbox id (inb_…) this object belongs to. Null when it applies to every inbox."
+    },
+    "inboxes": {
+      "description": "Inbox counts."
+    },
+    "messages": {
+      "description": "Message counts, such as sent and received."
+    },
+    "object": {
+      "description": "Object type name, such as list, message, or thread."
+    },
+    "period": {
+      "description": "Time range the counts cover."
+    }
+  },
+  "type": "object"
+}

AddedOct 9, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the read-only, idempotent, and nondestructive annotations, it discloses authentication and message_read requirements, UTC buckets, zero-rate behavior, account and key scoping, held-body exclusion, and specific 400, 403, and 404 failure modes. Its statement that the tool is read-only is consistent with the annotations.

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

Conciseness4/5

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

The description front-loads selection criteria and then proceeds logically through inputs, outputs, errors, and visibility rules. Its dense single paragraph and repetition of schema defaults and output shapes reduce scanability, although nearly all of the detail is operationally useful.

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?

For a three-mode, six-parameter tool, it covers mode selection, defaults, account scope, output meanings, bucket and date behavior, authorization, and error handling. Additional details about storage calculation, event labels, zero rates, and sub-account visibility leave no material invocation gap.

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

Parameters4/5

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

Schema coverage is already 100%, and much of the Inputs section repeats enums, optionality, and defaults. It still adds valuable cross-parameter semantics, including kind-specific applicability, timestamp and range validation with error codes, unknown-value handling, and inbox/key scope interactions.

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 opening identifies three concrete jobs: mail counts over time, current usage, and bounce/complaint rates for this account. This clearly distinguishes the tool from message and thread retrieval, search, and raw event-listing siblings.

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

Usage Guidelines4/5

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

"Use this when" provides explicit selection context, and the kind-specific details clarify when to choose events, usage, or rates. It does not provide when-not guidance or name alternatives such as cooper_list_events or cooper_search_messages for different needs.

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

All Cooper Email tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.