Cooper Email

Delete a sub-account

cooper_delete_workspace

DestructiveIdempotent

Use this when a parent should remove a sub-account, its API key, and its mail. Requires auth. Destructive. Inputs: workspace_id (required), delete_inboxes (optional boolean). Returns {id, deleted:true, inboxes_deleted}. When the workspace still has inboxes and delete_inboxes is not true, the call returns 409 workspace_not_empty and deletes nothing. delete_inboxes true returns 409 owner_required and deletes nothing when any inbox is in approval mode, until that owner confirms deletion. Otherwise it removes those inboxes, their messages, attachments, owners, and tasks, then the workspace API keys, OAuth tokens, webhooks, domains, and the child account. The child key then returns 401. Parent plan usage no longer counts that sub-account. Another parent's workspace returns 404 workspace_not_found. A sub-account key returns 403 permission_denied. An inbox-scoped key returns 403 permission_denied.

Input Schema

Name	Required	Description	Default
`workspace_id`	Yes	Workspace id (ws_…) created by this parent account
`delete_inboxes`	No	Required when the workspace still has inboxes. true deletes those inboxes. Omit it and a non-empty workspace returns 409 workspace_not_empty.

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.
`inboxes_deleted`	No	How many inboxes were deleted with it.

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 workspace.",
+  "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."
+    },
+    "inboxes_deleted": {
+      "description": "How many inboxes were deleted with it."
+    }
+  },
+  "type": "object"
+}

AddedOct 9, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare destructive and non-read-only, but the description goes well beyond: it enumerates the full deletion cascade (messages, attachments, owners, tasks, keys, tokens, webhooks, domains), the two 409 paths that delete nothing, and post-conditions (child key returns 401, parent usage no longer counts the sub-account). That is exactly the behavioral context an agent needs before an irreversible call.

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?

Front-loaded with the trigger, then inputs, then outcomes and error codes in a predictable order; nearly every sentence carries a distinct failure or side-effect. Minor waste in the trailing run-on and the repeated '403 permission_denied' for two different key types.

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 cascade delete, the description covers trigger, inputs, return shape reference, every error branch, and post-conditions; an output schema exists so return values need no further expansion. Nothing needed to call it safely is missing.

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 baseline is 3, but the description adds semantics the schema only summarizes: omitting delete_inboxes on a non-empty workspace yields 409 workspace_not_empty with no deletion, and true can still 409 owner_required in approval mode. It does not restate workspace_id format, which the schema covers.

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?

States a specific verb and resource ('remove a sub-account') plus the cascade scope ('its API key, and its mail'), which distinguishes it from cooper_delete_inbox and cooper_update_workspace without needing the schema.

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?

Explicitly frames the trigger ('Use this when a parent should remove a sub-account') and the conditions under which it refuses (inboxes present without delete_inboxes, approval-mode owner, wrong-parent 404, sub-account/inbox-scoped key 403). No sibling alternative is named, so it stops short of a 5.

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.