Skip to main content
Glama

SuperSend

by io.github.Ktryberceo
OverviewDiscussionsAdmin

Get Inbox Checkout Link

get_inbox_checkout_link
Read-onlyIdempotent

Plan sending domains and inboxes, and get a checkout link for the user to review and pay. Nothing is charged by this tool. Domains can be new (checked that they can be bought; fails with the reason if not, so pick other names) or ones the organization already has: bought through SuperSend, or connected with connect_domain (no domain charge, only the inboxes; returned with owned: true). Returns the link plus estimated cost (about $13/year per new domain, $5/month per inbox; azure is $49/month per domain for exactly 50 inboxes, for high volume). SuperSend connects bought inboxes for every provider (google, outlook, azure or smtp) and starts their warmup itself. A connected domain registered elsewhere is the exception: after payment the user sets its nameservers at the registrar (run verify_domain a few minutes after paying to get them), and its inboxes are created once they are live. Use 2-3 inboxes per domain, at most 5 (azure: list no inboxes, or a few to set the sender names; SuperSend fills the domain to 50) and domains that look like the user's brand (e.g. tryacme.com, getacme.com), never the main company domain. New inboxes appear within 24-48 hours; check with get_setup_status.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
domainsYesDomains to buy or already owned, each with the inbox provider
team_idNoTeam for the inboxes (default: the user's default team)
mailboxesNoInboxes to create on those domains (azure domains: optional, names only)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / domains / description
      Previous value: -"New domains to buy, each with the inbox provider"New value: +"Domains to buy or already owned, each with the inbox provider"
    • changedInput schema / properties / domains / items / properties / domain / description
      Previous value: -"New domain to buy, e.g. tryacme.com (.com, .net or .org)"New value: +"New domain to buy (.com, .net or .org), or one the organization already has, e.g. tryacme.com"
  2. Changed6 schema fields changed
    • changedInput schema / properties / domains / items / properties / provider / description
      Previous value: -"Inbox provider for this domain"New value: +"Inbox provider for this domain (azure = 50 inboxes for $49/month)"
    • changedInput schema / properties / domains / items / properties / provider / enum
      Previous value: -[
-  "smtp",
-  "outlook",
-  "google"
-]New value: +[
+  "smtp",
+  "outlook",
+  "google",
+  "azure"
+]
    • addedInput schema / properties / mailboxes / default
      Added value: +[]
    • changedInput schema / properties / mailboxes / description
      Previous value: -"Inboxes to create on those domains"New value: +"Inboxes to create on those domains (azure domains: optional, names only)"
    • removedInput schema / properties / mailboxes / minItems
      Removed value: -1
    • changedInput schema / required
      Previous value: -[
-  "domains",
-  "mailboxes"
-]New value: +[
+  "domains"
+]
  3. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds real behavioral value beyond that: 'Nothing is charged by this tool', pricing estimates, that SuperSend starts warmup itself, and that inboxes appear within 24-48 hours. Minor gap: no explicit statement about permissions/team scope beyond the team_id default.

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 the key 'nothing is charged' reassurance, and nearly every sentence carries actionable detail. It is dense and parenthetical-heavy, with pricing and edge cases packed into long run-on sentences, which slightly hurts scannability.

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?

No output schema exists, and the description covers the return value (the link plus estimated cost) as well as downstream timing and follow-up steps. For a planning/checkout tool of this complexity, an agent has everything needed to call it correctly.

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 description coverage is 100%, so the schema already documents domain, provider, team_id, and mailbox fields; the baseline is 3. The description nevertheless adds operational meaning the schema lacks — 2-3 inboxes per domain and at most 5 (azure: list no inboxes), azure = 50 inboxes for $49/month, and brand-style domain naming — which materially shapes correct invocation.

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: plan sending domains/inboxes and produce a checkout link for the user to review and pay. It explicitly frames the tool as non-charging and distinguishes itself from related siblings (connect_domain, verify_domain, get_setup_status). An agent can tell what this does and how it differs from setup/status 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 explicit when-to-use context and edge cases: new vs. already-owned domains, domains bought through SuperSend vs. connected elsewhere, the registrar nameserver follow-up, and the instruction to verify later with verify_domain / get_setup_status. It also prescribes domain naming and inbox-count heuristics, leaving little to inference.

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

All SuperSend toolsInspect
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.

Resources