Cooper Email

List suppressed addresses

cooper_list_suppressions

Read-onlyIdempotent

Use this when you need the addresses this account will not email after a permanent bounce, a complaint, or a manual add. Read-only; requires auth. Inputs: none. Returns {object:"list", data:[{object:"suppression", address, reason, source_message_id, created_at}]}. reason is bounce, complaint, or manual. source_message_id is the outbound msg_ id that caused a bounce or complaint, or null for a manual row. An inbox-scoped key cannot call this and receives 403 permission_denied. Fails with unauthorized.

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description	Default
`data`	No	Items on this page, in the order the tool description gives.
`object`	No	Object type name, such as list, message, or thread.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 3, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "Suppressed recipient addresses.",
+  "properties": {
+    "data": {
+      "description": "Items on this page, in the order the tool description gives.",
+      "items": {
+        "properties": {
+          "address": {
+            "description": "Suppressed recipient address."
+          },
+          "created_at": {
+            "description": "ISO-8601 time the object was created."
+          },
+          "deleted": {
+            "description": "True when the object was deleted."
+          },
+          "object": {
+            "description": "Object type name, such as list, message, or thread."
+          },
+          "reason": {
+            "description": "bounce, complaint, or manual."
+          },
+          "source_message_id": {
+            "description": "Message that caused the suppression, or null."
+          }
+        },
+        "type": "object"
+      }
+    },
+    "object": {
+      "description": "Object type name, such as list, message, or thread."
+    }
+  },
+  "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?

Goes well past the readOnly/idempotent annotations by disclosing the auth requirement, the hard constraint that an inbox-scoped key gets 403 permission_denied, and the unauthorized failure mode. Those are exactly the operational facts an agent needs before choosing this tool and interpreting an error.

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?

Front-loads the trigger condition, then constraints, then return shape, in a tight sequence. It is somewhat dense and the field-by-field return detail partly duplicates the output schema, but no sentence is wasted.

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?

Covers purpose, auth and error behavior, and the semantics of each returned field (reason enum values, source_message_id null for manual rows). Combined with the existing output schema, nothing an agent needs to call or interpret this tool is missing.

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?

With zero parameters, the baseline is 4, and the description confirms 'Inputs: none' so an agent will not hunt for a required argument. No further parameter meaning is possible or needed.

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 ('the addresses this account will not email') and defines suppression precisely by its three causes: permanent bounce, complaint, manual add. An agent can distinguish this from cooper_delete_suppression or cooper_list_request_refusals without opening any schema.

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?

Gives a clear trigger condition ('use this when you need the addresses this account will not email') and narrows scope to this account, which implicitly excludes other list tools. It stops short of naming an alternative, e.g. pointing to cooper_delete_suppression for removal, so it is clear context without explicit routing.

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.