Cooper Email

Commit durable events

cooper_commit_events

Idempotent

Use this after you have processed a page from cooper_poll_events. Requires auth and message_read. Inputs: client_id (the consumer id or client_id) and cursor (the commit_cursor you received, an evc1 cursor). Returns the consumer. cursor on the response is the committed position. An older cursor is a no-op and the current position is returned. A value that is not an evc1 cursor is HTTP 400 invalid_cursor. Another account's consumer is HTTP 404 consumer_not_found.

Input Schema

Name	Required	Description	Default
`cursor`	Yes	evc1 cursor to commit. An older cursor does not move the position backwards.
`client_id`	Yes	Consumer id (evcon_…) or the client_id used when the consumer was created.

Output Schema

Name	Required	Description
`id`	No	Event consumer id.
`types`	No	Event types this consumer reads.
`cursor`	No	Committed position of the consumer.
`object`	No	Object type name, such as list, message, or thread.
`inbox_id`	No	Inbox id (inb_…) this object belongs to. Null when it applies to every inbox.
`client_id`	No	Caller idempotency key stored with the object, or null.
`created_at`	No	ISO-8601 time the object was created.
`updated_at`	No	ISO-8601 time the object last changed.
`last_polled_at`	No	ISO-8601 time of the last poll, or null.
`last_committed_at`	No	ISO-8601 time of the last commit, or null.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 3, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "The consumer at its committed position.",
+  "properties": {
+    "client_id": {
+      "description": "Caller idempotency key stored with the object, or null."
+    },
+    "created_at": {
+      "description": "ISO-8601 time the object was created."
+    },
+    "cursor": {
+      "description": "Committed position of the consumer."
+    },
+    "id": {
+      "description": "Event consumer id."
+    },
+    "inbox_id": {
+      "description": "Inbox id (inb_…) this object belongs to. Null when it applies to every inbox."
+    },
+    "last_committed_at": {
+      "description": "ISO-8601 time of the last commit, or null."
+    },
+    "last_polled_at": {
+      "description": "ISO-8601 time of the last poll, or null."
+    },
+    "object": {
+      "description": "Object type name, such as list, message, or thread."
+    },
+    "types": {
+      "description": "Event types this consumer reads."
+    },
+    "updated_at": {
+      "description": "ISO-8601 time the object last changed."
+    }
+  },
+  "type": "object"
+}

AddedOct 22, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations by stating auth/message_read requirements, the monotonic no-op semantics for older cursors, and two specific failure modes (HTTP 400 invalid_cursor, HTTP 404 consumer_not_found). This is exactly the operational context annotations cannot convey.

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 and auth, then inputs, then return and error semantics. Efficient, though the error-code sentences make it slightly dense and run-on; still every clause carries 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?

Auth scope, input origin, return shape (consumer, committed cursor position), no-op behavior and two error cases are all covered; with an output schema present, the return explanation is a bonus rather than a necessity. Nothing an agent needs to call this correctly 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 already 100%, so the baseline is 3, but the description adds real meaning: it clarifies client_id is the consumer id or original client_id, and that cursor is the evc1 cursor received from polling. That traceability of where the value comes from is value beyond the schema.

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 ('commit' the cursor for the events consumer) and anchors it to a sibling ('after you have processed a page from cooper_poll_events'). An agent can immediately distinguish this from the poll tool and understand the pairing.

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

Usage Guidelines5/5

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

Gives an explicit triggering condition: use after processing a page from cooper_poll_events. It also documents the no-op case for an older cursor, so the agent knows when calling is harmless versus necessary.

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.