Skip to main content
Glama

Cherami

by to.cherami
OverviewDiscussionsAdmin

Find outgoing emails

list_sent
Read-onlyIdempotent

Search or list an inbox's sent mail; all supplied filters must match.

Input Schema

NameRequiredDescriptionDefault
fromNoExact From address, case-insensitive.
afterNoReceived or sent at or after this time: YYYY-MM-DDTHH:mm:ss, optional 1–3 fractional digits, then Z or ±HH:mm.
limitNo
orderNoDefaults to newest. relevance requires query.
queryNoWords or quoted phrases that must all appear in the subject or body. Case-insensitive keyword match, not semantic search; up to 16 terms or phrases.
beforeNoReceived or sent before this time: YYYY-MM-DDTHH:mm:ss, optional 1–3 fractional digits, then Z or ±HH:mm.
cursorNoContinue with next_cursor from the previous result, keeping the same filters. Stop when next_cursor is null.
subjectNoLiteral, case-insensitive substring of the subject.
inbox_idYes
recipientNoExact To, Cc or Bcc address, case-insensitive.
labels_allNoRequire every listed label. An empty array in any label filter adds no condition.
labels_anyNoRequire at least one listed label.
labels_noneNoExclude messages with any listed label.

Output Schema

NameRequiredDescriptionDefault
messagesYes
next_cursorYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changed
    • changedInput schema / properties / after / description
      Previous value: -"Inclusive receipt/submission time: YYYY-MM-DDTHH:mm:ss, optional 1–3 fractional digits, then Z or ±HH:mm."New value: +"Received or sent at or after this time: YYYY-MM-DDTHH:mm:ss, optional 1–3 fractional digits, then Z or ±HH:mm."
    • changedInput schema / properties / before / description
      Previous value: -"Exclusive receipt/submission time: YYYY-MM-DDTHH:mm:ss, optional 1–3 fractional digits, then Z or ±HH:mm."New value: +"Received or sent before this time: YYYY-MM-DDTHH:mm:ss, optional 1–3 fractional digits, then Z or ±HH:mm."
    • changedInput schema / properties / from / description
      Previous value: -"Exact email address in From, case-insensitive; not the SMTP envelope sender."New value: +"Exact From address, case-insensitive."
    • changedInput schema / properties / labels_all / description
      Previous value: -"Require every listed label. Filter groups combine with AND; empty arrays impose no condition."New value: +"Require every listed label. An empty array in any label filter adds no condition."
    • changedInput schema / properties / order / description
      Previous value: -"Defaults to newest. Relevance requires query; ties use newest first. Threads order by their latest activity."New value: +"Defaults to newest. relevance requires query."
    • changedInput schema / properties / query / description
      Previous value: -"Match all words or quoted phrases in subject/body. Case-insensitive keyword search, not semantic similarity; up to 16 terms/phrases."New value: +"Words or quoted phrases that must all appear in the subject or body. Case-insensitive keyword match, not semantic search; up to 16 terms or phrases."
    • changedInput schema / properties / recipient / description
      Previous value: -"Exact email address in To/Cc/Bcc where available, case-insensitive."New value: +"Exact To, Cc or Bcc address, case-insensitive."
    • changedInput schema / properties / subject / description
      Previous value: -"Literal case-insensitive substring of the subject."New value: +"Literal, case-insensitive substring of the subject."
  2. First observed

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is free. The description adds only the AND semantics of filter combination, which the schema also spells out per-parameter; it says nothing about default ordering, result caps, or pagination behavior beyond what the cursor field documents.

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?

A single front-loaded sentence with zero filler and the filter-matching rule immediately visible. It is terse to the point of omitting orientation hints, but nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, a rich cursor parameter, 85% description coverage, and annotations covering the safety profile, the definition is nearly self-sufficient. The only gap is routing guidance versus the many sibling list/get tools, which the description does not supply.

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 description coverage is 85% and each of the 13 parameters carries its own format/constraint text (e.g. 'relevance requires query', cursor continuation rules). The description contributes no parameter-level meaning beyond the schema, so baseline 3 applies.

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?

States a specific verb pair (search/list) and resource (an inbox's sent mail) with the inbox scope made explicit. The word 'sent' implicitly separates it from list_messages, but no sibling is named and the differentiation is left to inference.

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

Usage Guidelines3/5

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

'All supplied filters must match' gives a working contract for combining filters, but there is no guidance on when to pick this over list_messages, get_sent_message, or count_messages, and no when-not conditions. Usage is implied rather than stated.

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

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