Sendmux Email Inbox API + Sending

Official

Overview Schema Source Related Servers Discussions Admin

Upload Attachment

sending_upload_attachment

Prepare an attachment upload for sending emails via the Sendmux API, specifying filename, MIME type, idempotency key, or inline base64 for tiny files.

Instructions

Use this before sending a Sending API attachment. For real files use sending_create_attachment_upload and PUT the file outside model context. Inline content_base64 is a last resort for tiny agent-authored files only and is capped at 32 KiB decoded.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`filename`	Yes	Filename to use when sending the uploaded attachment.
`content_type`	No	MIME type to store with the upload, for example application/pdf.	application/octet-stream
`content_base64`	No	Last-resort inline base64 for tiny agent-authored files only. Decoded content must be at most 32 KiB; use a presigned upload for real files.
`idempotency_key`	No	Optional Idempotency-Key for safely retrying the upload.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv1.0.8Sep 15, 2026

changedInput schema / properties / content_base64 / description

Previous value: -"Last-resort inline base64 for tiny agent-authored files only. Decoded content must be at most 32 KiB; use file_path for real local files."New value: +"Last-resort inline base64 for tiny agent-authored files only. Decoded content must be at most 32 KiB; use a presigned upload for real files."

removedInput schema / properties / file_path

Removed value: -{
-  "anyOf": [
-    {
-      "type": "string"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "description": "Local file path for stdio MCP only. The path must be inside a client-declared MCP root; hosted MCP rejects it."
-}

addedOutput schema / $schema

Added value: +"https://json-schema.org/draft/2020-12/schema"

removedOutput schema / additionalProperties
```
Removed value: -true
```

addedOutput schema / oneOf

Added value: +[
+  {
+    "additionalProperties": false,
+    "properties": {
+      "data": {
+        "additionalProperties": false,
+        "properties": {
+          "attachment_id": {
+            "description": "Temporary attachment ID to use in email attachments[].",
+            "example": "att_tz4a98xxat96iws9zmbrgj3a",
+            "pattern": "^att_[a-z0-9]{24}$",
+            "type": "string"
+          },
+          "content_type": {
+            "description": "Stored attachment MIME type",
+            "example": "application/pdf",
+            "type": "string"
+          },
+          "expires_at": {
+            "description": "ISO timestamp when this temporary attachment reference expires.",
+            "example": "2026-07-07T08:15:00.000Z",
+            "format": "date-time",
+            "type": "string"
+          },
+          "filename": {
+            "description": "Stored attachment filename",
+            "example": "analysis.pdf",
+            "type": "string"
+          },
+          "size_bytes": {
+            "description": "Stored attachment byte size",
+            "example": 20480,
+            "type": "integer"
+          }
+        },
+        "required": [
+          "attachment_id",
+          "filename",
+          "content_type",
+          "size_bytes",
+          "expires_at"
+        ],
+        "type": "object"
+      },
+      "meta": {
+        "additionalProperties": false,
+        "properties": {
+          "request_id": {
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "ok": {
+        "const": true
+      }
+    },
+    "required": [
+      "ok",
+      "data"
+    ],
+    "type": "object"
+  },
+  {
+    "additionalProperties": false,
+    "properties": {
+      "error": {
+        "additionalProperties": false,
+        "properties": {
+          "code": {
+            "type": "string"
+          },
+          "doc_url": {
+            "type": "string"
+          },
+          "errors": {
+            "items": {
+              "additionalProperties": false,
+              "properties": {
+                "code": {
+                  "type": "string"
+                },
+                "field": {
+                  "type": "string"
+                },
+                "message": {
+                  "type": "string"
+                }
+              },
+              "required": [
+                "field",
+                "code",
+                "message"
+              ],
+              "type": "object"
+            },
+            "type": "array"
+          },
+          "message": {
+            "type": "string"
+          },
+          "param": {
+            "type": "string"
+          },
+          "retryable": {
+            "type": "boolean"
+          }
+        },
+        "required": [
+          "code",
+          "message"
+        ],
+        "type": "object"
+      },
+      "meta": {
+        "additionalProperties": false,
+        "properties": {
+          "request_id": {
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "ok": {
+        "const": false
+      }
+    },
+    "required": [
+      "ok",
+      "error"
+    ],
+    "type": "object"
+  }
+]

First observedv1.0.0Jul 13, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already signal mutation and non-idempotency. The description adds meaningful constraints: the 32 KiB decoded cap, the 'last resort' status of inline base64, and the directive to keep real files outside model context. It does not fully explain what happens when content_base64 is null or what resource is created, but the output schema may cover return details.

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?

Three sentences with no filler; the critical usage constraint is front-loaded and the alternative is named explicitly. The first sentence could be more action-oriented, but the structure is efficient and every sentence contributes.

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?

The output schema likely covers return values, so the description needn't detail them. However, the relationship between this tool and sending_create_attachment_upload is only partially specified: it is unclear whether calling this tool alone with content_base64 null produces a usable attachment or whether an additional staging step is required. For a 4-parameter tool, this is adequate but leaves a workflow gap.

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 tool description mainly restates what content_base64's schema description already says (32 KiB cap, last resort, presigned upload for real files), and it adds no new meaning for filename, content_type, or idempotency_key beyond the schema.

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?

The description clearly positions the tool as a pre-send step for Sending API attachments and distinguishes it from sending_create_attachment_upload, but it never directly states the operation's core effect (e.g., 'uploads/registers an attachment'). The title and name compensate partially, so this is clear but not maximally explicit.

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?

The description provides explicit when-to-use guidance: use before sending a Sending API attachment. It also tells the agent to use sending_create_attachment_upload and PUT the file outside model context for real files, and restricts inline content_base64 to a last resort for tiny agent-authored files. This is strong routing among siblings.

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