Retrieve sent emails using cursor pagination. Pass before/after IDs and a limit to fetch specific batches of email records.
List sent emails with cursor pagination (GET /emails).
| Name | Required | Description | Default |
|---|---|---|---|
| after | No | Cursor: return items after this id. | |
| limit | No | Max items to return. | |
| before | No | Cursor: return items before this id. |
Changes observed during successful MCP inspections.
v1.0.2Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It signals a read-only GET operation and adds cursor pagination behavior, which is meaningful. It does not detail response format, but 'list' and the verb imply a collection response, leaving no hidden side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is a single front-loaded sentence with no filler. It conveys the resource, scope, pagination behavior, and HTTP method in ten words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with three fully documented optional parameters, the description sufficiently covers the core invocation context. It could be more complete by naming the sibling for received emails or noting the return shape, but the lack of output schema and annotations is partly compensated by the clarity of 'list sent emails'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter already has an explanatory description in the schema. The description adds only the 'cursor pagination' context, which supplements but does not materially extend the schema's parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('List sent emails') and includes the endpoint '(GET /emails)', which clearly distinguishes it from sibling tools like list_received_emails. An agent can identify exactly what the tool returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'sent emails' implies when to use this tool, but it does not explicitly name alternatives or conditions such as 'for received emails use list_received_emails'. Pagination guidance is present, but no when-not-to-use instructions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.