Argorant

Connect a mailbox from any provider

argorant_connect_smtp_mailbox

Idempotent

Connect a mailbox from any email provider, such as Zoho, Fastmail, Yahoo, iCloud, IONOS or a web host, so campaigns can send from it and its replies arrive in Argorant. Give one mailbox, or up to 25 in mailboxes. Use it for providers other than Google and Microsoft; Google Workspace connects with argorant_connect_google_workspace and Microsoft 365 on the Mailboxes page. Argorant first signs in to send and to read replies, and connects only the mailboxes where both work; the others come back with the reason in plain words. Connecting the same address again replaces its saved settings, which is how a mailbox is reconnected after a password change. The password is stored safely and never shown again, and many providers need an app password. A free trial connects up to 2 mailboxes. Through Claude, never ask for a mailbox password; this returns connect_url, Argorant's own mailbox form, where the user enters it. Connecting is free and sends no email. More in the docs at https://docs.argorant.com/docs/agents/tools#mailboxes

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "argorant_connect_smtp_mailbox"
  }
}

Input Schema

Name	Required	Description
`email`	No	The mailbox address that sends, for example anna@yourcompany.com. Required. Leave it empty when you give mailboxes.
`preset`	No	The email provider, if it is on the list. It fills in the server names, ports and security for you. Use other and fill in the servers when the provider is not listed.
`imap_host`	No	Incoming server name for reading replies, as your provider lists it. Not needed with a preset.
`imap_port`	No	Incoming server port, usually 993. Leave empty for 993.
`mailboxes`	No	Up to 25 mailboxes to connect in one go, each with its own settings. Leave the single mailbox fields empty then.
`smtp_host`	No	Outgoing server name for sending, as your provider lists it. Not needed with a preset.
`smtp_port`	No	Outgoing server port. Use 587. If you give 465, Argorant tries 587 and saves 587 when it works. Not needed with a preset.
`daily_limit`	No	Most campaign emails this mailbox sends a day. Leave empty for 25.
`sender_name`	No	The sender name people see, for example Anna Weber. Optional.
`imap_password`	No	Password for reading replies. Leave empty to use the one for sending.
`imap_security`	No	Incoming connection security. ssl for port 993, starttls for port 143. Leave empty to pick it from the port.
`imap_username`	No	Sign-in name for reading replies. Leave empty to use the one for sending.
`smtp_password`	No	The mailbox password, or an app password when the provider asks for one. Required. It is stored safely and never shown again.
`smtp_security`	No	Outgoing connection security, starttls on port 587. Leave empty to pick it from the port.
`smtp_username`	No	Sign-in name for sending. Leave empty when it is the email address.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only declare the mutation/open-world/idempotent profile; the description supplies the substance behind them — Argorant signs in to both send and read, saves only mailboxes where both work, and returns plain-language failure reasons for the rest. It also discloses that the password is stored and never shown, that many providers need an app password, that reconnecting overwrites saved settings, and that no email is sent and the operation is free.

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?

Front-loaded with purpose and provider scope, then constraints, then the password-handling rule — a sensible order for a 15-parameter tool. It is long but nearly every sentence carries a distinct, decision-relevant fact; the docs URL and a couple of soft asides are the only slack.

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 batch-capable mutation tool with an output schema, this covers what the schema cannot: verification behavior, partial-failure reporting, replacement semantics, trial limits, and the connect_url handoff. An agent has enough to decide, gather inputs, and interpret the result without further guidance.

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; the description goes beyond it by explaining the preset-versus-manual relationship (a preset fills servers, ports, and security) and the single-field-versus-`mailboxes` list mode. Most importantly it redirects password handling through the returned connect_url rather than having the agent collect `smtp_password`, though this sits slightly at odds with the schema marking that field required, and the description never resolves which wins.

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 opens with a specific verb and resource ("Connect a mailbox from any email provider") and enumerates concrete providers (Zoho, Fastmail, Yahoo, iCloud, IONOS, web host). It explicitly carves out Google Workspace and Microsoft 365, naming the sibling argorant_connect_google_workspace, so an agent can route without opening any schema.

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?

It states when to use this tool (any non-Google/non-Microsoft provider), names the alternative for Google Workspace, and gives the cardinality choice (one mailbox or up to 25 in `mailboxes`). It adds hard constraints an agent needs before calling: free trial connects at most 2 mailboxes, and connecting an existing address replaces its settings, which is the sanctioned reconnect path after a password change.

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

All Argorant tools Inspect

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.