Skip to main content
Glama
Sign In
Email Sending MCP

Email Sending MCP

by resend
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Update Inbox Agent

update-inbox-agent

Update a Resend inbox AI agent's instructions, tone, and allowed actions. Omitted fields keep current values; actions replace the full set, so include all to keep enabled.

Instructions

Update the AI agent settings of a Resend inbox: the instructions the agent follows, the tone it writes in, and/or the actions it is allowed to take on the inbox's threads. At least one of the three is required. A field left out keeps its current value, and "actions" replaces the whole set when passed, so include every action that should stay enabled. Use get-inbox-agent to read the current settings first.

Input Schema

NameRequiredDescriptionDefault
toneNoTone the agent writes in, one of concise_professional, concise_casual, expanded_professional, expanded_casual. Pass null to clear it.
actionsNoActions the agent is allowed to take, replacing the current set. Pass every action that should stay enabled; pass an empty array to disable them all. Duplicates are removed.
inboxIdYesInbox ID, or the inbox email address (e.g. "support@example.com"). Not the Resend receiving address.
instructionsNoInstructions the agent follows when handling the inbox's threads. Pass null to clear them. Max 4000 characters.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv2.27.1
    • addedInput schema / properties / actions
      Added value: +{
+  "description": "Actions the agent is allowed to take, replacing the current set. Pass every action that should stay enabled; pass an empty array to disable them all. Duplicates are removed.",
+  "items": {
+    "enum": [
+      "draft_reply",
+      "forward_thread",
+      "add_labels",
+      "assign_thread",
+      "mark_as_spam",
+      "archive",
+      "move_to_trash"
+    ],
+    "type": "string"
+  },
+  "type": "array"
+}
    • removedInput schema / properties / enabledActions
      Removed value: -{
-  "description": "Actions the agent is allowed to take, replacing the current set. Pass every action that should stay enabled; pass an empty array to disable them all. Duplicates are removed.",
-  "items": {
-    "enum": [
-      "draft_reply",
-      "forward_thread",
-      "add_labels",
-      "assign_thread",
-      "mark_as_spam",
-      "archive_thread",
-      "delete_thread"
-    ],
-    "type": "string"
-  },
-  "type": "array"
-}
    • changedInput schema / properties / inboxId / description
      Previous value: -"Inbox ID"New value: +"Inbox ID, or the inbox email address (e.g. \"support@example.com\"). Not the Resend receiving address."
    • changedInput schema / properties / tone / anyOf
      Previous value: -[
-  {
-    "maxLength": 64,
-    "minLength": 1,
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "enum": [
+      "concise_professional",
+      "concise_casual",
+      "expanded_professional",
+      "expanded_casual"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • changedInput schema / properties / tone / description
      Previous value: -"Tone the agent writes in (e.g. \"friendly and concise\"). Pass null to clear it. Max 64 characters."New value: +"Tone the agent writes in, one of concise_professional, concise_casual, expanded_professional, expanded_casual. Pass null to clear it."
  2. Addedv2.26.1

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=false, openWorldHint=false, destructiveHint=false. The description adds genuinely new behavior: unspecified fields retain current values, and "actions" is a full-replacement set requiring the caller to re-list everything that should stay enabled, plus the at-least-one rule that the schema does not encode (required only lists inboxId). This is exactly the merge-vs-replace nuance an agent needs.

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?

Front-loads the purpose, then the required-field constraint, then the critical replacement warning, then the pointer to get-inbox-agent. Every sentence earns its place with no redundancy against the schema.

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?

For a mutation tool with full annotations and 100% schema coverage and no output schema, the description covers everything needed to call it correctly: what it mutates, the partial-update contract, the set-replacement hazard, and the recommended read-first workflow.

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 coverage is 100%, so the baseline is 3 and the schema already documents tone, actions, inboxId, and instructions in detail. The description adds value beyond the schema by explaining partial-update semantics and the at-least-one-required constraint, which the schema's required array does not capture.

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 and resource ("Update the AI agent settings of a Resend inbox") and then enumerates the exact three settings it touches: instructions, tone, and actions. This distinguishes it clearly from sibling tools like update-inbox (general inbox) and get-inbox-agent (read counterpart).

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?

Explicitly routes the agent: "Use get-inbox-agent to read the current settings first" names the companion read tool, and "At least one of the three is required" defines the precondition for a valid call. The replacement semantics for actions effectively tell the caller when and how to pass that field.

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

Deploy Server

Other Tools