Skip to main content
Glama
Sign In

Cooper Email

by com.cooperemail
OverviewDiscussionsAdmin

Enable instant replies

cooper_enable_instant_replies
Idempotent

Use this when an owner message should wake the agent within seconds. Idempotent. Requires auth. Inputs: inbox_id (required), url (public http or https URL, required unless enabled is false), headers (optional; up to 5 extra headers named Authorization or X-*; omit them on a later call to keep the stored headers; pass an empty object to clear them), enabled (optional boolean; false deletes the wake webhook). Returns {object:"inbox_wake", inbox_id, enabled:true, webhook} on create (HTTP 201, secret revealed once) or update (HTTP 200, secret redacted). enabled false returns {object:"inbox_wake", inbox_id, enabled:false, deleted}. The hook is registered for task.received, owner.reply, and chat.message on that inbox. One owner message produces one POST of task.received. The body includes related [{type, id}] for owner.reply and, for an app message, chat.message. The event log still stores each type. A webhook created with POST /api/v1/webhooks still receives every event it lists. A second call for the same inbox updates the same hook. Localhost and private addresses are rejected. If this client can receive a callback, events/subscribe for message.received is cheaper and needs no URL.

Input Schema

NameRequiredDescriptionDefault
urlNoPublic https URL that receives the wake POST. Required unless enabled is false.
enabledNoSet false to delete the wake webhook for this inbox. Omit or true to register or update it.
headersNoUp to 5 extra headers sent on delivery. Names must be Authorization or X-*. Omit to keep stored headers. An empty object clears them. Values are stored encrypted and returned as redacted.
inbox_idYesInbox id (inb_…), username, or full email address

Output Schema

NameRequiredDescriptionDefault
objectNoObject type name, such as list, message, or thread.
deletedNoTrue when the object was deleted.
enabledNoTrue when the object is active.
webhookNoThe wake webhook. The secret is shown in full only on create.
inbox_idNoInbox id (inb_…) this object belongs to. Null when it applies to every inbox.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "The wake webhook for this inbox.",
+  "properties": {
+    "deleted": {
+      "description": "True when the object was deleted."
+    },
+    "enabled": {
+      "description": "True when the object is active."
+    },
+    "inbox_id": {
+      "description": "Inbox id (inb_…) this object belongs to. Null when it applies to every inbox."
+    },
+    "object": {
+      "description": "Object type name, such as list, message, or thread."
+    },
+    "webhook": {
+      "description": "The wake webhook. The secret is shown in full only on create.",
+      "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"
+}
  2. Added

TDQS

A4.5/5.0
Behavior5/5

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

Goes far beyond the annotations (idempotent, openWorld, non-destructive): it discloses secret-revealed-once vs redacted behavior, HTTP 201/200 status codes, that a second call updates the same hook, that localhost/private addresses are rejected, which events the hook registers for, and the exact delivery/body semantics. That is unusually rich behavioral detail for a mutation tool.

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?

Purpose and the key alternative are front-loaded, which is good, but the body becomes a dense run-on block covering return shapes that the output schema already conveys. The information is mostly valuable, yet it would read far better as short bullet points than as a multi-clause paragraph.

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 tool with nested header objects, one-of-required logic, delete semantics, and side effects on multiple event types, the description covers calling context, edge cases (private addresses rejected), and update/delete semantics. Nothing an agent needs in order to invoke it safely 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 coverage is 100%, so the schema already documents url, enabled, headers, and inbox_id in nearly the same words (including header retention, empty-object clearing, and 'required unless enabled is false'). The description largely restates these rather than adding new meaning, so the baseline 3 applies.

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?

Names a specific verb+resource ('enable instant replies' / wake webhook) and states its effect precisely: an owner message wakes the agent within seconds. It is clearly distinguishable from siblings like cooper_register_webhook, cooper_update_webhook, and cooper_delete_webhook.

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

Usage Guidelines5/5

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

Explicitly names the alternative ('events/subscribe for message.received is cheaper and needs no URL') and the condition that selects it ('if this client can receive a callback'). It also clarifies coexistence with POST /api/v1/webhooks, so an agent knows when this tool is and isn't the right choice.

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

All Cooper Email toolsInspect
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.

Resources