Skip to main content
Glama

AIsa Agent Mail

by one.aisa
OverviewDiscussionsAdmin

Manage List Entries

post_agentmail_list_entry
Destructive

Retrieve or create entries in the specified list based on direction and type. Supports listing entries with pagination and adding new email addresses or domains with an optional reason.

Published reference price: $0.012 USD per successful request. Account-specific pricing and final settlement may differ.

Input Schema

NameRequiredDescriptionDefault
bodyNo
typeYesType of list entry.
directionYesDirection of list entry.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • addedInput schema / additionalProperties
      Added value: +false
    • removedInput schema / allOf
      Removed value: -[
-  {
-    "if": {
-      "anyOf": [
-        {
-          "properties": {
-            "entry": {
-              "not": {
-                "type": "null"
-              }
-            }
-          },
-          "required": [
-            "entry"
-          ]
-        },
-        {
-          "properties": {
-            "reason": {
-              "not": {
-                "type": "null"
-              }
-            }
-          },
-          "required": [
-            "reason"
-          ]
-        }
-      ]
-    },
-    "then": {
-      "properties": {
-        "entry": {
-          "not": {
-            "type": "null"
-          }
-        }
-      },
-      "required": [
-        "entry"
-      ]
-    }
-  }
-]
    • addedInput schema / properties / body
      Added value: +{
+  "properties": {
+    "entry": {
+      "description": "Email address or domain to add.",
+      "type": "string"
+    },
+    "reason": {
+      "description": "Reason for adding the entry.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "entry"
+  ],
+  "title": "CreateListEntryRequest",
+  "type": "object"
+}
    • removedInput schema / properties / entry
      Removed value: -{
-  "description": "Email address or domain to add.",
-  "type": "string"
-}
    • removedInput schema / properties / reason
      Removed value: -{
-  "description": "Reason for adding the entry.",
-  "type": "string"
-}
  2. Changed1 schema field changed
    • addedInput schema / allOf
      Added value: +[
+  {
+    "if": {
+      "anyOf": [
+        {
+          "properties": {
+            "entry": {
+              "not": {
+                "type": "null"
+              }
+            }
+          },
+          "required": [
+            "entry"
+          ]
+        },
+        {
+          "properties": {
+            "reason": {
+              "not": {
+                "type": "null"
+              }
+            }
+          },
+          "required": [
+            "reason"
+          ]
+        }
+      ]
+    },
+    "then": {
+      "properties": {
+        "entry": {
+          "not": {
+            "type": "null"
+          }
+        }
+      },
+      "required": [
+        "entry"
+      ]
+    }
+  }
+]
  3. Changed2 schema fields changed
    • removedInput schema / properties / Authorization
      Removed value: -{
-  "description": "Bearer authentication",
-  "type": "string"
-}
    • changedInput schema / required
      Previous value: -[
-  "direction",
-  "type",
-  "Authorization"
-]New value: +[
+  "direction",
+  "type"
+]
  4. Changed2 schema fields changed
    • addedInput schema / properties / Authorization
      Added value: +{
+  "description": "Bearer authentication",
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "direction",
-  "type"
-]New value: +[
+  "direction",
+  "type",
+  "Authorization"
+]
  5. Changed2 schema fields changed
    • removedInput schema / properties / Authorization
      Removed value: -{
-  "description": "Bearer authentication",
-  "type": "string"
-}
    • changedInput schema / required
      Previous value: -[
-  "direction",
-  "type",
-  "Authorization"
-]New value: +[
+  "direction",
+  "type"
+]
  6. First observed

TDQS

C2.8/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered structurally. The description adds useful context that entry creation accepts an email address or domain plus an optional reason, but omits what happens on duplicates or how this differs from the sibling create tool.

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

Conciseness3/5

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

The core sentence is front-loaded and brief, but the phrasing 'based on direction and type' is vague and the appended pricing boilerplate consumes attention without aiding tool selection.

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?

An output schema exists, so return values need no explanation, and annotations carry the mutation/destructive profile. Still, for a dual-mode POST with a nested body and two enums, the description leaves gaps about which operation is triggered when and how the call relates to sibling list-entry tools.

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 coverage is 67%, with enum values (allow/block, send/receive/reply) documented in the schema itself. The description adds modest value by clarifying that the entry can be an email address or domain and that the reason is optional, matching the nested body schema without adding new semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names specific verbs (retrieve, create) and a resource (list entries), and mentions the direction/type qualifiers. However, it never clarifies how this POST-based dual-purpose tool differs from its dedicated siblings get_agentmail_list_entries and post_agentmail_inbox_list_entry, leaving the agent unsure which to pick.

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

Usage Guidelines2/5

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

It states the tool can list with pagination or add an entry with an optional reason, but gives no when-to-use guidance, no prerequisites, and no pointer to the GET/DELETE siblings that cover the read/remove sides of the same resource. The 'based on direction and type' phrase is suggestive but not actionable usage guidance.

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

All AIsa Agent Mail 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