Argorant

Test a mailbox sign-in

argorant_test_smtp_mailbox

Read-onlyIdempotent

Check that Argorant can sign in to a mailbox from any email provider, such as Zoho, Fastmail, Yahoo, iCloud, IONOS or a web host, before connecting it. Use it when the settings are uncertain; Google Workspace connects with argorant_connect_google_workspace instead. It tries sending and reading replies and says for each one whether it works, or what is wrong in plain words, such as a wrong password, a server that does not answer or a security setting that does not match. Nothing is saved and no email is sent. Many providers need an app password. Through Claude, never ask for a mailbox password; this returns connect_url, Argorant's own mailbox form, where the user enters it and the sign-in is tested. It is free. 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_test_smtp_mailbox"
  }
}

Input Schema

Name	Required	Description
`email`	No	The mailbox address that sends, for example anna@yourcompany.com. Required.
`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.
`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.
`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.3/5.0

Behavior4/5

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

Annotations already declare read-only, non-destructive, idempotent, open-world, so the bar is low, yet the description adds real substance: it tries sending and reading replies, reports per-check results in plain words, lists failure modes (wrong password, unresponsive server, security mismatch), and notes it is free. It also discloses the highly consequential credential flow — never ask for a mailbox password through Claude, the tool returns connect_url where the user enters it. However, 'Nothing is saved' sits awkwardly against the smtp_password schema text 'It is stored safely and never shown again' and against 'tries sending', which an agent may read as contradictory.

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 correctly: purpose, then routing, then behavior, then the credential warning, then pricing and docs. It is a single long paragraph with a few run-on spots ('or what is wrong in plain words, such as...'), but almost every sentence carries information an agent needs.

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 12-parameter tool it covers the essentials: what is tested, what the caller learns, that nothing is persisted or delivered, the auth handoff via connect_url, cost, and a docs link; the output schema carries return shape. What is missing is what to do after a successful test (proceed to argorant_connect_smtp_mailbox) and a resolution of the 'nothing is saved' versus 'stored safely' tension.

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 all 12 parameters are already documented with defaults, ports and security mapping; baseline is 3. The description adds only one param-level hint not already in the schema — that many providers need an app password — and otherwise speaks at workflow level rather than explaining parameters.

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: check that Argorant can sign in to a mailbox before connecting it, across named providers (Zoho, Fastmail, Yahoo, iCloud, IONOS, web host). It explicitly distinguishes itself from argorant_connect_google_workspace, so an agent can pick it over the sibling connect tools without opening a 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?

Gives an explicit when: 'Use it when the settings are uncertain.' Gives a when-not and a named alternative: Google Workspace goes to argorant_connect_google_workspace. Placement is also implied ('before connecting it'), which routes the agent to the connect step afterward.

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.