Cooper Email

List webhooks

cooper_list_webhooks

Read-onlyIdempotent

Use this when you need the webhooks on this account, including whether each one is enabled and which inboxes it matches. Read-only; requires auth. No inputs. Returns {object:"list", data:[{id, url, events, inbox_id, inbox_ids, client_id, enabled, consecutive_failures, disabled_at, disabled_reason, secret (redacted), previous_secret_expires_at, previous_secret_active, headers (redacted), last_delivery_status, last_delivery_at, created_at}]}. previous_secret_active is true for 24 hours after a secret rotation. The previous secret value is never returned. An inbox-scoped key lists only hooks stored on that inbox. Fails with 401 unauthorized or 403 permission_denied.

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_webhooks"
  }
}

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": "Webhooks on the account. Secrets are redacted.",
+  "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."
+          },
+          "consecutive_failures": {
+            "description": "Failed deliveries in a row."
+          },
+          "created_at": {
+            "description": "ISO-8601 time the object was created."
+          },
+          "disabled_at": {
+            "description": "ISO-8601 time Cooper disabled the hook, or null."
+          },
+          "disabled_reason": {
+            "description": "Why the hook was disabled, or null."
+          },
+          "enabled": {
+            "description": "True when the object is active."
+          },
+          "events": {
+            "description": "Event types this object delivers."
+          },
+          "headers": {
+            "description": "Extra delivery headers. Values are redacted."
+          },
+          "id": {
+            "description": "Stable id of the returned object. Pass it to the matching get, update, or delete tool."
+          },
+          "inbox_id": {
+            "description": "Inbox id (inb_…) this object belongs to. Null when it applies to every inbox."
+          },
+          "inbox_ids": {
+            "description": "Inbox ids this object is limited to. Empty means every inbox on the account."
+          },
+          "previous_secret_active": {
+            "description": "True while deliveries are also signed with the previous secret."
+          },
+          "previous_secret_expires_at": {
+            "description": "ISO-8601 time the previous secret stops signing, or null."
+          },
+          "secret": {
+            "description": "Signing secret. Shown in full once on create or rotate, redacted otherwise."
+          },
+          "url": {
+            "description": "URL that receives POST deliveries."
+          }
+        },
+        "type": "object"
+      }
+    },
+    "object": {
+      "description": "Object type name, such as list, message, or thread."
+    }
+  },
+  "type": "object"
+}

AddedOct 9, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Beyond the read-only annotations, the description discloses authentication requirements, no inputs, redacted secret/header behavior, previous-secret timing semantics, inbox-scoped key filtering, and 401/403 failure modes. Those details materially help an agent understand side effects and visibility scope.

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 description is front-loaded and mostly structured, but it includes an extensive return-field list even though an output schema exists. That duplicated schema detail makes it longer than necessary for a no-parameter list tool.

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 simple read-only list operation, the definition covers purpose, auth, inputs, scoping behavior, redaction, error cases, and return semantics. Given the annotations and output schema, an agent has enough context to call it correctly.

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?

There are no parameters, so parameter-semantics burden is minimal. The description explicitly confirms 'No inputs', which is sufficient and consistent with the empty schema.

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 clearly states the verb and resource: list the webhooks on this account, including enabled status and inbox matching. It is distinguishable from mutation siblings such as register/delete/update webhook, but it does not explicitly name alternatives or contrast with them.

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?

It gives a clear usage condition: use this when you need the webhooks on this account. It does not state when not to use it or point to related siblings for creation, deletion, or updates.

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.