Skip to main content
Glama

agent-cold-email

by io.github.YS-projectcalc
OverviewDiscussionsAdmin

configure_byo_domain

Destructive

Register or advance a BYO domain/mailbox intake. action = register (needs domain + domainRelationship: fresh_standalone|subdomain_of_primary|is_primary — runs pre-flight scan + abuse gate + reputation ladder, returns starting byoStatus) | poll_dns (needs id — re-checks DNS delegation, advances pending_dns -> active, or -> abandoned after 7 idle days) | acknowledge_consent (needs id + acknowledged:true — required before a primary domain can proceed past pending_consent; documents informed consent, does not remove exposure) | request_managed_mailboxes (needs id + count — platform-provisioned mailboxes on an ALREADY-ACTIVE domain; every response carries a billing projection { provisionedAfter, projectedMonthlyCents, formula }; quoteOnly:true previews without provisioning) | connect_mailbox (needs id + email + transport — declares an EXISTING OAuth/SMTP+IMAP connection, bypassing provisioning; transport is smtp | gmail_api | ms_graph, each with its own credential fields).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoRequired for poll_dns/acknowledge_consent/request_managed_mailboxes/connect_mailbox — the domainId from register.
countNoRequired for request_managed_mailboxes — how many platform-provisioned mailboxes to attach.
emailNoRequired for connect_mailbox — the existing mailbox address.
actionYes
domainNoRequired for register.
quoteOnlyNoOptional for request_managed_mailboxes — true previews the new mailbox count + projected monthly price WITHOUT provisioning (SPEC §18 quote-before-add).
transportNoRequired for connect_mailbox — { kind: 'smtp', host, port, secure, user, pass } | { kind: 'gmail_api', clientId, clientSecret, refreshToken } | { kind: 'ms_graph', mode: 'delegated'|'app_only', tenantId, clientId, clientSecret, refreshToken? }.
personaSlugNoOptional for request_managed_mailboxes — defaults to a slug of the domain.
acknowledgedNoRequired (must be true) for acknowledge_consent — SPEC.md §20.4's separate, unbundled risk acknowledgment.
domainRelationshipNoRequired for register: fresh_standalone | subdomain_of_primary | is_primary.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / quoteOnly
      Added value: +{
+  "description": "Optional for request_managed_mailboxes — true previews the new mailbox count + projected monthly price WITHOUT provisioning (SPEC §18 quote-before-add).",
+  "type": "boolean"
+}
  2. Added

TDQS

A4/5.0
Behavior4/5

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

Annotations only indicate destructiveHint=true and a title. The description meaningfully adds context: pre-flight scan + abuse gate + reputation ladder on register, DNS re-checks and 7-day idle timeout on poll_dns, consent documentation that doesn't remove exposure, billing projection details, and bypassing provisioning. This goes well beyond the single annotation, though it could state rate limits or idempotency.

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 a single dense sentence with pipe-delimited action blocks. It's front-loaded with the tool's overall purpose and then enumerates each action's needs, but it's quite long and slightly convoluted with parentheses and semicolons.

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?

Given a complex multi-action tool with 10 params, 90% schema coverage, no output schema, and only a destructive hint annotation, the description covers a lot of ground: action semantics, prerequisites, state transitions, billing, and consent nuances. It's largely complete, though it could explicitly note that register returns a starting byoStatus and the overall domain lifecycle progression.

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 already 90% and quite verbose, so baseline is 3, but the description adds per-action conditions (e.g., which params are needed for each action, transport credential field variation) that tie parameters to actions in a way the schema's individual param descriptions do not.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific multi-action intake tool for BYO domains/mailboxes and enumerates all five actions with their semantics. It's clear what the tool does, though it doesn't explicitly contrast with the sibling get_byo_domains which handles the read side.

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?

Effectively outlines prerequisites: register needs domain+relationship, poll_dns needs id, acknowledge_consent needs id+acknowledged, request_managed_mailboxes needs an ALREADY-ACTIVE domain, connect_mailbox bypasses provisioning. It provides clear when-to-use per action but doesn't state when NOT to use it or point to alternatives like get_byo_domains for read-only status.

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

All agent-cold-email 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