Skip to main content
Glama
Sign In

Cooper Email

by com.cooperemail
OverviewDiscussionsAdmin

List auto-forward destinations

cooper_list_forwarding
Read-onlyIdempotent

Use this to see the external addresses that receive a copy of every inbound email on one inbox. Read-only; requires auth and message_read. Input: inbox_id (required; inbox id, username, or email). Returns {object:"inbox_forwarding", destinations, unverified}. Each destination has id, email, status (pending or verified), verified_at, created_at, updated_at, expires_at, and client_id. The confirmation code is not included. unverified lists the pending rows again. An inbox-scoped key for another inbox returns HTTP 404 inbox_not_found. Pending addresses receive nothing until a human confirms the emailed code with POST /api/v1/inboxes/{id}/forwarding/confirm. There is no MCP tool for that 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>"
    },
    "name": "cooper_list_forwarding"
  }
}

Input Schema

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

Output Schema

NameRequiredDescriptionDefault
objectNoObject type name, such as list, message, or thread.
unverifiedNoDestinations still waiting for the emailed code. No confirmation code.
destinationsNoEvery destination. status is pending or verified. No confirmation code.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior5/5

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

Goes well past the readOnlyHint/idempotentHint annotations: names the required auth scope, the exact 404 inbox_not_found behavior when the key belongs to a different inbox, the fact that pending addresses receive nothing, and that the confirmation code is withheld. This is exactly the context annotations cannot carry.

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-loads purpose, then prerequisites, input, return shape and edge cases in a tight sequence with no filler. The enumerated return fields are somewhat redundant given an output schema exists, which keeps it from a 5.

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?

Covers everything an agent needs to call it and interpret the result: auth scope, accepted id formats, error case, status semantics, and the unverified duplicate list. The pending-confirmation caveat closes the one gap that could cause an agent to misreport forwarding as active.

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 description's parenthetical (inbox id, username, or email) repeats the schema's own wording without adding format or resolution rules. With one fully-documented parameter, 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?

States a specific verb and resource: see the external forwarding addresses for one inbox. It is clearly a read operation against forwarding state, which separates it from cooper_set_forwarding, cooper_remove_forwarding and cooper_request_forwarding among the siblings.

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?

Gives the operating context (read-only, requires auth and message_read) and warns that pending destinations do nothing until a human confirms via an HTTP endpoint that has no MCP tool, which prevents a false expectation that another sibling can complete the flow. It stops short of explicitly naming cooper_set_forwarding or cooper_remove_forwarding as the mutation counterparts.

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