Sendmux Email Inbox API + Sending

Official

Overview Schema Source Related Servers Discussions Admin

Create Attachment Upload

qubrics_sending_create_attachment_upload

Create a short-lived upload URL for outbound email attachments; upload the file bytes outside model context, then pass the returned attachment ID to send the message.

Instructions

Use this when a remote or shell-capable agent needs a short-lived upload URL for an outbound Sending API attachment. Provide filename, content_type, and exact size_bytes, PUT the file bytes outside model context with the returned headers, then pass the returned attachment_id to sending_send_email.

Input Schema

Name	Required	Description
`sha256`	No	Optional SHA-256 hex digest for the upload bytes.
`filename`	Yes	Filename to associate with the uploaded attachment.
`size_bytes`	Yes	Exact byte size that will be uploaded.
`content_type`	No	MIME type expected for the upload.
`Idempotency-Key`	No	Optional client-generated key to make the request idempotent for 24 hours. Replays under the same key return the cached response; a reused key with a different body returns 409 idempotency_conflict.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.0.17Nov 7, 2026

TDQS

A4/5.0

Behavior4/5

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

Beyond the annotations, it discloses the two-phase contract: the tool returns a URL plus headers, the bytes are PUT outside model context, and the resulting attachment_id must be carried into sending_send_email. It does not state how long the URL stays valid or what happens if size_bytes or content_type disagree with the actual upload, which are the main failure modes for a short-lived URL.

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?

Two sentences, front-loaded with the usage condition, then the ordered call sequence. Every clause carries operational information with no restatement of the title or name.

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?

For a signed-URL minting tool with an output schema, the description covers the input contract, the out-of-band upload step, and the handoff to sending_send_email. Missing only expiry and mismatch-handling detail, which are secondary given the output schema exists.

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 100%, so all five parameters are already documented, and the description only echoes the filename/content_type/size_bytes triple with an emphasis on 'exact' size. It adds no guidance on the optional sha256 or Idempotency-Key fields, so the baseline 3 is appropriate.

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 and resource: it mints a short-lived upload URL for an outbound Sending API attachment, which clearly separates it from the mailbox-side attachment tools. It is slightly weaker against its closest sibling, qubrics_sending_upload_attachment, since it never says which of the two an agent should reach for.

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 opening clause 'Use this when a remote or shell-capable agent needs a short-lived upload URL' gives a concrete triggering condition, and the closing clause routes the agent forward to sending_send_email. It omits any exclusion or comparison against the direct-upload siblings, so the agent must still infer when this two-step flow is preferable.

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

Deploy Server