Cooper Email

List allow or block entries

cooper_list_list_entries

Read-onlyIdempotent

Use this when you need the addresses on an allow or block list. Read-only; requires auth. Inputs: direction (required; send, receive, or reply), type (required; allow or block), inbox_id (optional; inbox id, username, or email; omit for the account-wide list). Returns {data:[{object:"list_entry", direction, type, entry, entry_type, inbox_id, reason, created_at}], next_page_token}. entry_type is email or domain. inbox_id is null on an account-wide entry. Up to 1000 entries per list. Fails with 400 invalid_list, or inbox_not_found when inbox_id is another account's inbox. The per-inbox task allowlist is separate and is unchanged.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "direction": "<direction>",
      "type": "<type>"
    },
    "name": "cooper_list_list_entries"
  }
}

Input Schema

Name	Required	Description
`type`	Yes	allow limits mail to matching addresses when the list is non-empty. block rejects matching addresses.
`inbox_id`	No	Inbox id (inb_…), username, or full email. Omit for the account-wide list.
`direction`	Yes	send checks recipients. receive checks new inbound mail. reply checks mail that answers an outbound Message-ID.

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 3, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "Allow and block list entries.",
+  "properties": {
+    "data": {
+      "description": "Items on this page, in the order the tool description gives.",
+      "items": {
+        "properties": {
+          "created_at": {
+            "description": "ISO-8601 time the object was created."
+          },
+          "deleted": {
+            "description": "True when the object was deleted."
+          },
+          "direction": {
+            "description": "inbound or outbound."
+          },
+          "entry": {
+            "description": "The email address or domain on the list."
+          },
+          "entry_type": {
+            "description": "email or domain."
+          },
+          "inbox_id": {
+            "description": "Inbox the entry applies to, or null for the whole account."
+          },
+          "object": {
+            "description": "Object type name, such as list, message, or thread."
+          },
+          "reason": {
+            "description": "Optional note stored with the entry."
+          },
+          "type": {
+            "description": "allow or block."
+          }
+        },
+        "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"
+}

AddedOct 8, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, yet the description still adds meaningful context beyond them: auth requirement, a 1000-entry cap per list, and concrete failure modes (400 invalid_list, inbox_not_found for another account's inbox). It also clarifies that the per-inbox task allowlist is a separate, unaffected concept, which prevents a real misinterpretation.

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 trigger condition and read-only/auth facts are front-loaded, and the sentence-per-topic structure is easy to scan. It is somewhat dense and telegraphic, and parts of the 'Inputs:' list duplicate the schema verbatim rather than adding value.

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-parameter read tool, the description covers the trigger, required vs optional inputs, auth, list size limits, error behavior, and the entry_type distinction. An output schema exists, so the return-value sketch is redundant but harmless, and nothing an agent needs to call this correctly is missing.

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 the schema already documents direction, type, and inbox_id in comparable detail; the description largely restates those enums. The one genuinely additive note ('inbox_id is null on an account-wide entry') concerns the response rather than the parameter, so the baseline of 3 applies.

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

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource ('the addresses on an allow or block list') and scopes it precisely with the direction/type parameters. It also disambiguates from the per-inbox task allowlist, though it never names its actual siblings (cooper_get_list_entry, cooper_create_list_entry, cooper_delete_list_entry), so an agent still has to infer which sibling handles single-entry reads.

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 you need the addresses on an allow or block list' is an explicit trigger condition, and the inbox_id clause explains when to omit the parameter for the account-wide view. It stops short of routing the agent to alternatives for adding or removing entries, so the exclusion guidance is only partial.

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.