Skip to main content
Glama
Sign In

Cooper Email

by com.cooperemail
OverviewDiscussionsAdmin

Remove auto-forward destination

cooper_remove_forwarding
DestructiveIdempotent

Use this to stop copying inbound mail to one external address. Requires auth and inbox_update. Inputs: inbox_id (required), destination_id (required; ifd_ id or the email). Returns {id, email, deleted:true}. An unknown destination is HTTP 404 forwarding_destination_not_found. Another account's inbox is HTTP 404 inbox_not_found. Does not return a confirmation code.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "inbox_id": "<inbox_id>",
      "destination_id": "<destination_id>"
    },
    "name": "cooper_remove_forwarding"
  }
}

Input Schema

NameRequiredDescriptionDefault
inbox_idYesInbox id (inb_…), username, or full email address owned by this key
destination_idYesDestination id (ifd_…) or the external email address to remove.

Output Schema

NameRequiredDescriptionDefault
idNoStable id of the returned object. Pass it to the matching get, update, or delete tool.
emailNoThe external address that was removed.
deletedNoTrue when the object was deleted.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already flag destructive=true and idempotent=true, and the description adds genuinely new behavioral context: required auth scope, the exact success payload, two distinct 404 error codes with their meanings, and the negative fact that no confirmation code is returned. That error taxonomy is the kind of detail an agent cannot get from the structured fields.

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?

The purpose is front-loaded in the first clause, followed by prerequisites, parameters, return shape, and error cases in a compact telegraphic style. No sentence is filler, though the staccato "Inputs:"/"Returns" shorthand is terse enough to read as notes rather than prose.

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 two-parameter destructive mutation, the description covers auth requirements, input forms, success payload, and both failure modes. An output schema exists, yet the extra error-code detail still adds value rather than redundancy, leaving nothing an agent needs 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 both parameters are already documented with their accepted id/email forms. The description restates that destination_id may be an ifd_ id or an email, which duplicates rather than extends the schema. Baseline 3 applies when the schema carries the semantic load.

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 opens with a specific verb+resource: "stop copying inbound mail to one external address." That clearly separates it from additive siblings like cooper_set_forwarding or cooper_request_forwarding. It never names those siblings explicitly, so the differentiation is implied rather than stated.

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 gives a clear condition for use (removing an existing auto-forward destination) and states the prerequisite scopes (auth and inbox_update). It does not say what to do when no forwarding exists or point to cooper_list_forwarding as the way to discover a destination_id, so exclusions are left to inference.

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