Cooper Email

Delete durable event consumer

cooper_delete_event_consumer

DestructiveIdempotent

Use this to remove a durable event consumer and its cursor. Requires auth and message_read. Input: client_id (consumer id evcon_… or the client_id). Returns {id, client_id, deleted:true}. Another account's consumer, or a consumer pinned to a different inbox than an inbox-scoped key, is HTTP 404 consumer_not_found.

Input Schema

Name	Required	Description	Default
`client_id`	Yes	Consumer id (evcon_…) or the client_id used when the consumer was created.

Output Schema

Name	Required	Description
`id`	No	Stable id of the returned object. Pass it to the matching get, update, or delete tool.
`deleted`	No	True when the object was deleted.
`client_id`	No	Caller idempotency key stored with the object, or null.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 3, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "Deletion result for the consumer.",
+  "properties": {
+    "client_id": {
+      "description": "Caller idempotency key stored with the object, or null."
+    },
+    "deleted": {
+      "description": "True when the object was deleted."
+    },
+    "id": {
+      "description": "Stable id of the returned object. Pass it to the matching get, update, or delete tool."
+    }
+  },
+  "type": "object"
+}

AddedOct 22, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already flag destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description still adds real behavioral detail: the cursor is destroyed along with the consumer, auth plus message_read is required, and the 404 consumer_not_found conditions are spelled out.

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

Conciseness5/5

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

Three tight sentences: what it does, what it requires, and what happens on error. The destination is front-loaded and nothing is padded.

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?

Auth scope, destructive effects, and failure modes are all present, and an output schema exists so return values need not be spelled out. For a one-parameter destructive tool, this is close to complete.

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?

Schema coverage is 100%, so the baseline is 3, but the description reinforces that client_id accepts either the evcon_… consumer id or the original client_id. That restates the schema rather than extending it, so the score stays just above baseline.

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 begins with a specific verb and resource: 'remove a durable event consumer and its cursor.' That is enough to distinguish it from near-siblings such as cooper_delete_event_subscription, though it never explicitly contrasts the two.

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?

The phrase 'Use this to remove...' sets the operating context, and the description rules out two conditions that would fail: another account's consumer, and a consumer pinned to a different inbox than an inbox-scoped key. It stops short of pointing the agent to cooper_list_event_consumers for discovery or naming an alternative tool.

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.