Argorant

Change settings for many mailboxes

argorant_update_inboxes

Destructive

Change the daily limit, warm-up or on and off state of many mailboxes in one call, chosen by domain, tag, status, address or all_connected=true; status=["any"] takes every mailbox. Use it for bulk changes; for one mailbox or a display name use argorant_update_inbox. preview is true by default, so the first call only counts how many mailboxes match and would change, by domain and status. Tell the user the number, then call again with preview=false. Switching more than one mailbox off also needs confirmed=true, because their sending stops and people queued on them wait for another mailbox. daily_limit is cold emails a day per mailbox, 1 to 10,000; new mailboxes usually send about 5 a day, and more on new domains can hurt delivery. Warm-up follows within a few hours. Nothing is sent. More in the docs at https://docs.argorant.com/docs/agents/tools#analytics-mailbox-settings-blocklist

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "settings": "<settings>"
    },
    "name": "argorant_update_inboxes"
  }
}

Input Schema

Name	Required	Description
`tags`	No	Mailboxes that carry all of these tags.
`emails`	No	Addresses, when only a few. For many, use domains or tags.
`status`	No	sendable, warming, not_connected, needs_attention, paused, or any.
`domains`	No	Every mailbox on these domains.
`preview`	No	True (default) only counts what would change. Set false to change.
`settings`	Yes	Only the settings to change, from daily_limit, warmup, warmup_per_day and active, for example {"daily_limit": 8}
`confirmed`	No	Needed to switch off more than one mailbox, after the user said yes.
`workspace`	No	For team accounts only: ours (default) or a workspace number.
`all_connected`	No	true takes every signed-in mailbox of the workspace.

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 already flag destructiveHint=true, and the description earns its keep beyond that: it discloses that preview defaults to true and only counts, that turning off more than one mailbox requires confirmed=true because sending stops and queued people wait, and that warm-up lands within a few hours. It also states 'Nothing is sent,' which correctly frames the blast radius of a settings mutation.

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?

The safety-critical constraint (preview default) is front-loaded ahead of the operator guidance, and every sentence carries information. It is one dense run-on paragraph, though, with selector syntax, warning text, and the docs link all stacked together; a break between mechanics and safety would scan faster.

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 destructive nine-parameter bulk mutation with a nested settings object, the description covers the confirmation contract, the preview contract, selector precedence, value ranges, and side effects. With an output schema present and full schema coverage, nothing an agent needs in order to call this safely is missing.

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 schema baseline is 3; the description goes further by explaining that status=["any"] takes every mailbox, that daily_limit means cold emails per day per mailbox within 1 to 10,000, and that new mailboxes typically send about 5 a day and higher volumes on new domains hurt deliverability. The workspace parameter is left entirely to the schema, which keeps it short of a 5.

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?

Names a specific verb (change), resource (many mailboxes), and the three setting families (daily limit, warm-up, on/off state), plus the selector axes (domain, tag, status, address, all_connected). It also explicitly contrasts itself with the sibling argorant_update_inbox, so an agent can route correctly without opening either 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?

Explicitly states when to use this tool ('for bulk changes') versus the alternative ('for one mailbox or a display name use argorant_update_inbox'). It also prescribes the two-step workflow (preview first, report the count to the user, then re-call with preview=false) and the confirmed=true precondition, leaving no routing or sequencing decision to inference.

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.