Skip to main content
Glama

Groundbase

sending_settings

Read or set account-level limits on outbound campaign volume. action='get' returns { daily_email_send_cap, sent_today, remaining_today, timezone }; action='set' writes daily_email_send_cap. The cap is the maximum campaign EMAILS this account may send per calendar day in the account's own timezone. It is per ACCOUNT, not per campaign — eight campaigns sending "only 20 each" is still 160 emails from one domain, and reputation attaches to the domain. Use it to warm a new sending domain: start around 20/day and raise it weekly. SMS campaigns are never counted. When the cap is reached, remaining recipients stay QUEUED and send on following days — nothing fails, nothing is skipped, and drip step spacing still runs from each recipient's actual send time. null means uncapped; 0 means send no email today. PER DOMAIN: pass domain to cap one sending domain on its own budget. Reputation attaches to the domain, so with two domains in play a single account-wide number throttles the pair jointly and cannot stop the whole day's allowance landing on one of them — which is how a warming domain gets burned. BOTH APPLY: the account-wide cap is a total across every domain, and a domain's own cap sits inside it — an email sends only if it fits under both. A domain with no cap of its own is held by the account-wide cap alone, so single-domain accounts need not set any. action='get' returns domain_caps, each with its own sent_today and remaining_today. Use resend_manage(action='domains') to see which domains are verified.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionYes'get' to read, 'set' to write.
domainNoFor action='set'. Bare hostname, e.g. 'example.com'. Caps only mail sent from that domain, inside the account-wide cap. Omit to set the account-wide cap, which totals every domain and is the only cap on a domain without its own.
daily_email_send_capNoFor action='set'. Non-negative integer, or null to remove the cap entirely.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations present, the description carries the full burden and does so thoroughly. It explains queueing behavior when the cap is reached, the account-wide vs. domain-specific interaction, null vs. 0 semantics, timezone handling, and that SMS campaigns are never counted — far more than annotations would provide.

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 description is long but every sentence contributes substantive operational detail. Some redundancy exists around account-wide versus domain caps, but the density of concept is high enough that the length is justified.

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?

Given no output schema, the description fully documents return values, parameter behavior, edge cases, and how to coordinate with the sibling tool resend_manage. Nothing an agent needs to call this tool correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is already 100%, the description adds significant behavioral context for each parameter: what action='get' returns, what domain means in terms of budget isolation, and what null versus 0 does. This goes well beyond the schema's short parameter descriptions.

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 clearly states a specific verb ('Read or set') and resource ('account-level limits on outbound campaign volume'), and defines exactly what each action does. It distinguishes itself from related tools like email_send by focusing on account/domain sending caps rather than sending individual emails.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use the tool (warming a new sending domain) and how to check verified domains via resend_manage. It doesn't explicitly list alternatives to avoid, but the use-case guidance and cross-reference to resend_manage are strong enough to orient an agent.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources