Argorant

Order the quoted inboxes

argorant_order_inboxes

Destructive

Order exactly one quote from argorant_quote_inboxes. Use it only after the user saw the full quote and said yes; for a new price call argorant_quote_inboxes again, never to get around a limit or a refusal. Show the user the full quote (every domain with its first-year and renewal price, the mailboxes, due today, the recurring total, the currency rule, what is included and how it is paid) and order only after their explicit yes. Set confirmed=true only with that yes. Through Claude or ChatGPT, this always returns checkout_url, a payment link the user opens and pays themselves, a saved card is never charged, and only the workspace owner gets that link. Through an API key or another app, when the quote said the saved card is usable, it charges that card right away for the amount due today, within the limits the workspace set, so tell the user which card and how much before they say yes. Otherwise it returns checkout_url, and you tell the user the reason in saved_card.reason. pay_with=link always returns a payment link. You never enter card details or open, complete or pay a payment page. Nothing is bought before the payment went through, and setup starts after it; argorant_inbox_order_status shows each step. Sending the same call again returns the same order and never charges twice. More in the docs at https://docs.argorant.com/docs/agents/tools#new-inboxes

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": {
      "quote_id": "<quote_id>",
      "confirmed": "<confirmed>",
      "sender_names": "<sender_names>"
    },
    "name": "argorant_order_inboxes"
  }
}

Input Schema

Name	Required	Description	Default
`tags`	No	Tags every mailbox of the order gets, also the ones set up later.
`website`	No	Optional site that visitors of the new domains are sent to.
`pay_with`	No	auto uses the saved card when the quote said so, otherwise a payment link. link always returns a payment link.	auto
`quote_id`	Yes	The quote_id from the quote shown to the user.
`confirmed`	Yes	true only after the user's explicit yes to the quote shown
`sender_names`	Yes	The people the mailboxes send as, from 1 up to one per domain, as [{first_name, last_name}]. Each must be a real first and last name in Latin letters, because it becomes 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?

Far beyond the annotations: it discloses idempotency ('same call again returns the same order and never charges twice'), the two payment paths (checkout_url the user pays themselves vs. immediate saved-card charge via API key), who receives the link, and that nothing is bought before payment with setup starting afterward. The only gap is qualifying the destructiveHint/openWorldHint implications such as cancellation or refund windows, so it stops just short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core action and its precondition are front-loaded, but the text is a single dense block that repeats itself ('show the user the full quote' and 'only after their explicit yes' appear twice). The channel-by-channel payment explanation could be tightened without losing meaning.

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, open-world mutating tool with six parameters and an output schema, the description covers the confirmation gate, both payment outcomes, idempotency, and the follow-up tool (argorant_inbox_order_status) for progress. An agent has everything it needs to call this correctly and to explain the result to the user.

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% and the schema descriptions for confirmed, pay_with, quote_id, tags, website and sender_names already carry the semantics; the description largely restates pay_with=link and the confirmed gate. It does reinforce the gating intent of confirmed ('only with that yes'), but adds little parameter meaning the schema does not already provide, so the baseline 3 applies.

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 ('Order exactly one quote from argorant_quote_inboxes') and immediately bounds the scope to a single quote, which separates it from argorant_quote_inboxes and the status/mutation siblings. An agent can identify the action without opening the 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 explicit preconditions ('only after the user saw the full quote and said yes'), names the alternative for a different situation ('for a new price call argorant_quote_inboxes again'), and adds an exclusion ('never to get around a limit or a refusal'). It also enumerates what must be shown before ordering, which is unusable guidance to infer.

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.