Cooper Email

List inboxes

cooper_list_inboxes

Read-onlyIdempotent

Use this when you need to know which inboxes exist on the signed-in account, for example to pick an inbox_id before sending or reading mail, or to tell the user their address. Read-only; requires auth. Inputs: status (optional; active or paused; omit to list every inbox), q (optional case-insensitive substring of email, username, or display_name; prefix matches come first), label (optional exact label), limit (optional; default 100, maximum 500), page_token (optional cursor). Returns {data:[{id, username, email, display_name, created_at, require_sender_auth, labels, expires_at, status, paused_at, metadata, client_id, signature}], next_page_token}. signature is {text, html} or null. A limit outside 1 to 500 returns HTTP 400 invalid_limit. A bad page_token returns HTTP 400 invalid_page_token. An unknown status returns 400 invalid_status.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "cooper_list_inboxes"
  }
}

Input Schema

Name	Required	Description
`q`	No	Optional case-insensitive substring of email, username, or display_name. Prefix matches are listed first. % and _ match those characters.
`label`	No	Optional exact label. Only inboxes that carry this label are returned.
`limit`	No	Page size. Default 100. Maximum 500. Outside 1 to 500 returns invalid_limit.
`status`	No	Optional filter. active or paused. Omit to list every inbox.
`page_token`	No	Cursor from next_page_token. A bad token returns invalid_page_token.

Output Schema

Name	Required	Description
`data`	No	Items on this page, in the order the tool description gives.
`object`	No	Object type name, such as list, message, or thread.
`next_page_token`	No	Cursor for the next page, or null when this is the last page. Pass it back as page_token.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 8, 2026

addedOutput schema / properties / data / items / properties / alias_format

Added value: +{
+  "description": "Read-only plus-address pattern username+{tag}@domain. Mail to that address is stored in this inbox."
+}

Changed1 schema field changedNov 3, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "One page of inboxes on the account.",
+  "properties": {
+    "data": {
+      "description": "Items on this page, in the order the tool description gives.",
+      "items": {
+        "properties": {
+          "client_id": {
+            "description": "Caller idempotency key stored with the object, or null."
+          },
+          "created_at": {
+            "description": "ISO-8601 time the object was created."
+          },
+          "display_name": {
+            "description": "From display name, or null."
+          },
+          "email": {
+            "description": "Full email address of the inbox."
+          },
+          "expires_at": {
+            "description": "ISO-8601 time the object expires, or null for no expiry."
+          },
+          "id": {
+            "description": "Inbox id (inb_…). Pass it as inbox_id to other tools."
+          },
+          "labels": {
+            "description": "Labels on the object."
+          },
+          "metadata": {
+            "description": "Caller key-value data stored on the object."
+          },
+          "paused_at": {
+            "description": "ISO-8601 time the inbox was paused, or null."
+          },
+          "require_sender_auth": {
+            "description": "When true, only mail that passes DMARC/DKIM can create an owner task."
+          },
+          "screening": {
+            "description": "Inbound screening mode: off, observe, or hold."
+          },
+          "send_mode": {
+            "description": "direct sends immediately. approval turns sends into drafts a verified owner approves."
+          },
+          "signature": {
+            "description": "Signature {text, html} added to sends, or null."
+          },
+          "status": {
+            "description": "active or paused."
+          },
+          "username": {
+            "description": "Local part of the address."
+          }
+        },
+        "type": "object"
+      }
+    },
+    "next_page_token": {
+      "description": "Cursor for the next page, or null when this is the last page. Pass it back as page_token."
+    },
+    "object": {
+      "description": "Object type name, such as list, message, or thread."
+    }
+  },
+  "type": "object"
+}

Changed4 schema fields changedOct 9, 2026

addedInput schema / properties / label

Added value: +{
+  "description": "Optional exact label. Only inboxes that carry this label are returned.",
+  "type": "string"
+}

addedInput schema / properties / limit

Added value: +{
+  "description": "Page size. Default 100. Maximum 500. Outside 1 to 500 returns invalid_limit.",
+  "type": "number"
+}

addedInput schema / properties / page_token

Added value: +{
+  "description": "Cursor from next_page_token. A bad token returns invalid_page_token.",
+  "type": "string"
+}

addedInput schema / properties / q

Added value: +{
+  "description": "Optional case-insensitive substring of email, username, or display_name. Prefix matches are listed first. % and _ match those characters.",
+  "type": "string"
+}

Changed1 schema field changedOct 8, 2026

addedInput schema / properties / status

Added value: +{
+  "description": "Optional filter. active or paused. Omit to list every inbox.",
+  "enum": [
+    "active",
+    "paused"
+  ],
+  "type": "string"
+}

First observedSep 27, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the description is not carrying the safety burden alone; still it adds genuine context beyond them: an auth requirement, cursor pagination via next_page_token, and three specific failure modes (400 invalid_limit, invalid_page_token, invalid_status). The main redundancy is the full return-object enumeration, which the existing output schema already covers.

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

Conciseness3/5

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

The purpose and the downstream-use hook are correctly front-loaded, but the middle of the description becomes an 'Inputs:' enumeration that duplicates the schema verbatim, followed by a full field-by-field return shape that duplicates the output schema. Those two blocks are the bulk of the text and earn little, so the definition is longer than it needs to be.

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

Completeness4/5

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

Given a tool with an output schema, complete annotation coverage, and 100% schema description coverage, the definition supplies everything an agent needs to call it correctly, including auth, pagination, and error behavior. Nothing essential is missing; the only issue is that some included material is redundant rather than additive.

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?

Schema description coverage is 100%, so all five parameters are already documented in the schema, and the description's 'Inputs:' list largely restates them (status active/paused, limit 100/500, exact label, cursor). The one marginal addition is the note that prefix matches sort first, which also appears in the schema. Baseline 3 is appropriate.

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?

States a specific verb and resource (list inboxes on the signed-in account) and goes further by naming the concrete downstream reasons an agent would call it: picking an inbox_id before sending or reading mail, or reporting the user's address. That framing separates it cleanly from the write-side sibling cooper_create_inboxes and from unrelated list tools such as cooper_list_domains or cooper_list_messages.

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?

Usage context is explicit and actionable ('use this when you need to know which inboxes exist... for example to pick an inbox_id before sending or reading mail'), and per-parameter guidance is given for omitting status to widen the result set. There is no explicit exclusion or named alternative to avoid, but for a listing tool with no true sibling substitute the guidance is sufficient to select it correctly.

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.