Skip to main content
Glama
Sign In

inboxmcp

by io.github.zhlei07
OverviewDiscussionsAdmin

List this connection's completed emails

list_consumer_receipts
Read-onlyIdempotent

Review the email events this AI connection has already completed with complete_email_batch.

    Requires email:read. Returns only this connection's receipts, newest completion first: event and
    message IDs, mailbox, completion time and sender/subject metadata, with total_completed and
    next_offset for paging. Deferred or pending events are not receipts and no email body is returned.
    Returns not_configured when this connection has no built-in progress. Changes no state, never shows
    another AI connection's progress and does not verify notifications. Find pending work with
    claim_email_batch, not with this history.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_consumer_receipts"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum receipts to return, from 1 to 100; default 50.
offsetNoReceipts to skip, from 0; pass next_offset from the previous page. Default 0.
mailbox_idNoOptional mailbox ID from list_mailboxes within this connection's monitor. Omit for all of its mailboxes.
completed_afterNoOptional ISO 8601 timestamp with timezone, such as a previous last_completed_at; returns receipts completed at or after it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds substantial context beyond them: the email:read permission requirement, the not_configured failure mode when no built-in progress exists, connection-scoped isolation, that no email body is returned, and that notifications are not verified.

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 the core purpose, then permission, return shape, and exclusions in a tight sequence. Slightly dense with several clauses packed into the final sentence, but every sentence carries distinct information and no filler.

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?

With no output schema, the description compensates by naming the returned fields (event/message IDs, mailbox, completion time, sender/subject metadata, totals, paging cursor). Combined with permission, failure-mode, and scoping notes, an agent has everything needed to call and interpret it.

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 description coverage is 100%, so the baseline is 3, but the description adds real meaning: newest-completion-first ordering, the total_completed/next_offset paging contract, and mailbox scoping tied to this connection's monitor. It does not restate the limit bounds, which the schema already covers.

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+resource with scope: reviewing email events this AI connection has already completed with complete_email_batch, returning only this connection's receipts. It distinguishes itself from the sibling claim_email_batch and from pending/deferred events explicitly.

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 explicit routing: 'Find pending work with claim_email_batch, not with this history.' It also states what is excluded (deferred/pending events are not receipts) and the read-only historical nature of the tool, leaving nothing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All inboxmcp 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