Skip to main content
Glama
Sign In

Cooper Email

by com.cooperemail
OverviewDiscussionsAdmin

Delete an inbox

cooper_delete_inbox
DestructiveIdempotent

Use this when an inbox should be removed so its slot is free on the plan and on a workspace inbox quota. Requires auth. Deletes that inbox and its messages. Inputs: inbox_id (required; inbox id, username, or email). Returns {id, deleted:true}. An approval inbox returns HTTP 202 and stays until a verified owner confirms the emailed link. Recreating that username on the same account stays in approval mode. Only the account that owns the inbox can delete it. Another account's inbox returns inbox_not_found. The saved owner mail does not include the confirm token, and an API key cannot submit that link.

Input Schema

NameRequiredDescriptionDefault
inbox_idYesInbox id (inb_…), username, or full email address owned by this key

Output Schema

NameRequiredDescriptionDefault
idNoStable id of the returned object. Pass it to the matching get, update, or delete tool.
statusNoCurrent state of the object. The tool description lists the possible values.
deletedNoTrue when the object was deleted.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "Deletion result. An approval inbox returns a pending confirmation instead.",
+  "properties": {
+    "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."
+    },
+    "status": {
+      "description": "Current state of the object. The tool description lists the possible values."
+    }
+  },
+  "type": "object"
+}
  2. Added

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the annotations (destructive, idempotent, open-world), it discloses cascade behavior (messages are deleted too), an approval-mode 202 path that leaves the inbox present until a verified owner confirms an emailed link, the persistence of approval mode on username recreation, ownership scoping, and the inbox_not_found error for another account's inbox. It also warns that an API key cannot submit the confirmation link, which is real operational context an agent cannot infer.

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?

It is front-loaded with the use case and effect, then layers in caveats. A few sentences run long and split the ownership/approval narrative across several clauses, but nearly every sentence carries non-redundant information.

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 destructive single-parameter tool with an output schema, the description covers the cascade, ownership constraint, the approval-mode edge case, the error surface, and the auth limitation. An agent has everything needed to call it correctly and interpret the non-200 path.

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% and the single parameter's schema already documents the inb_ prefix, username, and full email address forms. The description's 'inbox_id (required; inbox id, username, or email)' largely restates that, so the baseline of 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?

The description uses a specific verb and resource ('Deletes that inbox and its messages') and its effect (freeing the slot on the plan and workspace inbox quota) makes it trivially distinguishable from siblings like update_inbox, delete_thread, or delete_workspace.

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 states a clear when-to-use condition: removal so the slot is freed on the plan and workspace quota. It does not explicitly name update_inbox as the alternative when the inbox should be kept and modified, so the routing guidance is good but not exhaustive.

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