Skip to main content
Glama

domani

by run.domani

List Email Messages

list_email_messages

List messages in a system folder or virtual view. Defaults to Inbox. Supports pagination, direction and search filters. API: GET /api/emails/{address}/messages.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoFilter by recipient address (case-insensitive, partial match)
fromNoFilter by sender address (case-insensitive, partial match)
slugYesMailbox slug
spamNoFilter by spam flag. Pass false to hide spam-flagged inbound; omit to include all.
viewNoVirtual view. Mutually exclusive with folder
limitNoMax messages to return (default 20, max 100)
cursorNoPagination cursor from previous response
domainYesMailbox domain
folderNoSystem folder. Mutually exclusive with view. Defaults to inbox
subjectNoFilter by subject (case-insensitive, partial match)
directionNoFilter by direction: 'in' for received, 'out' for sent

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed2 schema fields changed
    • addedInput schema / properties / folder
      Added value: +{
+  "description": "System folder. Mutually exclusive with view. Defaults to inbox",
+  "enum": [
+    "inbox",
+    "archive",
+    "sent",
+    "spam",
+    "trash"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / view
      Added value: +{
+  "description": "Virtual view. Mutually exclusive with folder",
+  "enum": [
+    "starred",
+    "all"
+  ],
+  "type": "string"
+}
  2. Changed1 schema field changed
    • addedInput schema / properties / spam
      Added value: +{
+  "description": "Filter by spam flag. Pass false to hide spam-flagged inbound; omit to include all.",
+  "type": "boolean"
+}
  3. First observed

TDQS

A3.9/5.0
Behavior3/5

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

With no annotations provided, the description carries the burden of behavioral disclosure. It mentions the GET API endpoint and default Inbox, which implies a read-only operation, but does not explicitly state read-only behavior, auth requirements, or response details. It adds some context but lacks full transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, front-loaded with the primary purpose, and contains no unnecessary words. It is efficient and well-structured.

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

Completeness3/5

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

Given 11 parameters and no output schema, the description covers the default folder and high-level filter capabilities but omits details about response structure, pagination cursor usage, and parameter exclusions (e.g., view/folder mutual exclusivity, which is left to the schema). It is adequate but not comprehensive.

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 100%, so the baseline is 3. The description mentions pagination, direction, and search filters, which align with schema parameters, but adds no new meaning beyond what the property descriptions already provide.

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?

The description clearly identifies the tool as listing email messages within a system folder or virtual view, with a default to Inbox. This distinguishes it from sibling tools like list_mailboxes (which lists mailboxes) and get_message (which retrieves a single message).

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?

The description imparts clear context: it is for listing messages in a folder/view with pagination and filters. It does not explicitly mention when not to use it or suggest alternatives like get_message for single messages, but the scope is unambiguous.

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

All domani toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.5/5.0
Disambiguation3/5

While most tools have distinct purposes, several clusters overlap significantly (e.g., check_email, check_email_deliverability, get_email_deliverability, get_domain_email_status; buy_domain, buy_aftermarket, acquire_domain). The descriptions are detailed and help differentiate, but the sheer number of tools makes it challenging for an agent to select the correct one without careful reading.

Naming Consistency3/5

The dominant pattern is verb_noun with underscores (e.g., create_mailbox, list_domains), but there are notable inconsistencies: destructive actions mix delete/remove/cancel/revoke/unsell, and a few names deviate entirely (search, dns_check, domain_status). The pattern is recognizable but not uniformly applied.

Tool Count1/5

With 122 tools, this vastly exceeds the 50+ threshold for extreme mismatch. Even for a comprehensive domain and email platform, the tool count is overwhelming and will likely hinder agent performance through excessive choice and context bloat.

Completeness4/5

The server covers a wide range of domains, DNS, email, marketplace, negotiations, transfers, webhooks, tokens, and billing. Minor gaps exist, such as no update operation for mail rules, no direct domain deletion, and limited mailbox configuration beyond forwarding and credentials, but most lifecycle workflows are supported.

Resources