Cooper Email

Release phone number

cooper_release_phone_number

Destructive

Release the inbox phone number at the provider and on Cooper. Requires auth. Input: inbox_id and confirm true. The same account cannot provision that E.164 again for 30 days. With COOPER_SMS_BILLING=stripe, releasing a billable number lowers the subscription quantity and Stripe prorates it.

Input Schema

Name	Required	Description	Default
`confirm`	Yes	Must be true. Confirms the human agreed to give up this number.
`inbox_id`	Yes	Inbox id (inb_…) that owns the phone number. Get it from cooper_list_inboxes.

Output Schema

Name	Required	Description
`id`	No	Stable id of the returned object. Pass it to the matching get, update, or delete tool.
`e164`	No	The phone number in E.164.
`object`	No	Object type name, such as list, message, or thread.
`status`	No	active or released.
`billing`	No	Billing result for this number, such as {status}.
`inbox_id`	No	Inbox id (inb_…) this object belongs to. Null when it applies to every inbox.
`outbound`	No	Outbound SMS registration state. Sends fail with outbound_not_registered until it is ready.
`provider`	No	Carrier provider name.
`account_id`	No	Cooper account id (acct_…) that owns this object.
`created_at`	No	ISO-8601 time the object was created.
`number_type`	No	Number type, such as local.
`released_at`	No	ISO-8601 time the number was released, or null.
`capabilities`	No	What the number supports, such as sms and voice.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 3, 2026

addedInput schema / properties / confirm / description

Added value: +"Must be true. Confirms the human agreed to give up this number."

addedInput schema / properties / inbox_id / description

Added value: +"Inbox id (inb_…) that owns the phone number. Get it from cooper_list_inboxes."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "The released phone number.",
+  "properties": {
+    "account_id": {
+      "description": "Cooper account id (acct_…) that owns this object."
+    },
+    "billing": {
+      "description": "Billing result for this number, such as {status}."
+    },
+    "capabilities": {
+      "description": "What the number supports, such as sms and voice."
+    },
+    "created_at": {
+      "description": "ISO-8601 time the object was created."
+    },
+    "e164": {
+      "description": "The phone number in E.164."
+    },
+    "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."
+    },
+    "number_type": {
+      "description": "Number type, such as local."
+    },
+    "object": {
+      "description": "Object type name, such as list, message, or thread."
+    },
+    "outbound": {
+      "description": "Outbound SMS registration state. Sends fail with outbound_not_registered until it is ready."
+    },
+    "provider": {
+      "description": "Carrier provider name."
+    },
+    "released_at": {
+      "description": "ISO-8601 time the number was released, or null."
+    },
+    "status": {
+      "description": "active or released."
+    }
+  },
+  "type": "object"
+}

AddedOct 17, 2026

TDQS

A4/5.0

Behavior5/5

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

Annotations already flag destructiveHint=true and openWorldHint=true, and the description adds substantive context beyond that: the release happens at the external provider as well as in Cooper, the same account is blocked from re-provisioning that E.164 for 30 days, and with COOPER_SMS_BILLING=stripe the subscription quantity drops and Stripe prorates. Those are exactly the consequences an agent needs to warn a human about before confirming.

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?

The action is front-loaded in the first clause, followed by the precondition, the irreversible side effect, and the billing consequence in descending order of importance. No filler; each of the four sentences carries a distinct fact an agent would otherwise have to discover the hard way.

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?

For a destructive, open-world mutation with an output schema, the definition covers auth, the confirmation gate, the external-provider effect, the cooldown, and billing impact — everything needed to call it safely. It stops short of saying what happens to existing SMS threads or messages tied to the released number, which is the one remaining gap for an agent deciding whether to proceed.

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 both properties already carry descriptions, including the "Must be true" constraint on confirm and the inb_… format plus a pointer to cooper_list_inboxes for inbox_id. The description's "Input: inbox_id and confirm true" merely restates the schema, adding no 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.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource — "Release the inbox phone number" — and adds scope by naming both ends of the operation ("at the provider and on Cooper"). It is clearly distinct from cooper_provision_phone_number and cooper_get_phone_number by verb alone, but it never explicitly contrasts itself with those siblings, so the differentiation is implicit rather than spelled out.

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

Usage Guidelines3/5

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

Usage is implied rather than stated: the required "confirm true" and the 30-day re-provisioning penalty signal that this is a last-resort, irreversible action, and "Requires auth" is a precondition. However, no alternative is named — an agent is not told whether to deactivate the inbox (cooper_update_inbox / cooper_delete_inbox) instead when it only wants to stop using the number.

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.