Skip to main content
Glama

Change the outreach setup

update_outreach_setup
Destructive

The sending inbox's settings and the pitch sequences (Settings → Sending inbox, Sequences). action:

  • signature(inboxId, signature): An inbox's signature (empty clears it).

  • daily_limit(inboxId, dailyLimit): An inbox's sends per day, 1 to 30. A raise restarts the warm-up climb.

  • warm_up(inboxId, on): An inbox's warm-up on or off. Off sends the whole daily limit from today, which hurts a new inbox's deliverability.

  • send_window(startHour?, endHour?, timezone?, weekdaysOnly?, dailyLimit?): When mail goes out: hours, timezone, weekdays only, the default daily limit.

  • opt_out(on?, lines?): The opt-out line under every email: on, and its lines (null puts Sightkick's back).

  • postal_address(address): The postal address under every email (empty clears it).

  • disconnect_inbox(inboxId): Take an inbox off (get_settings inbox): it stops sending and hearing replies, its queued sends are cancelled, its threads keep their history. A managed inbox taken off is cancelled with its domain. Connecting one again is the owner's sign-in.

  • create_managed_inbox(domain, firstName, lastName, username?, platform?, redirectUrl?): Order the managed inbox: the domain and one mailbox in the sender's name (username before the @, the first name when left out; GOOGLE or MICROSOFT; redirectUrl where the domain forwards, the site when left out). It connects itself in minutes, warm-up on. One inbox per brand: refused while another is being set up or an earlier one still listens. A new managed inbox needs the old one disconnected first, and charges the domain fee again to the plan's card. The same order asked again returns it, nothing charged.

  • save_sequence(sequenceId?, name?, pitch?, followUps?): Create a sequence (no sequenceId: inactive) or edit one: name, pitch (subject, body), followUps (enabled, days, body). What's left out stays.

  • duplicate_sequence(sequenceId): An inactive copy.

  • activate_sequence(sequenceId): Make it the one active sequence (ends a split test in its favour).

  • split_test(sequenceId): Run it beside the active one: new pitches alternate.

  • end_split_test(sequenceId): Take it out of the split test.

  • archive_sequence(sequenceId): Archive an inactive sequence with its numbers.

  • unarchive_sequence(sequenceId): Bring an archived sequence back, inactive.

  • remove_sequence(sequenceId): Delete a sequence never used (a used one is archived instead). Can't be undone.

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": {
      "action": "<action>"
    },
    "name": "update_outreach_setup"
  }
}

Input Schema

NameRequiredDescriptionDefault
onNo
nameNo
linesNo
pitchNo
actionYes
domainNo
addressNo
endHourNo
inboxIdNo
lastNameNo
platformNo
timezoneNo
usernameNo
firstNameNo
followUpsNo
signatureNo
startHourNo
dailyLimitNo
sequenceIdNoA sequence's id (get_outreach sequences), null for the Default
redirectUrlNo
weekdaysOnlyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / action / enum
      Previous value: -[
      -  "signature",
      -  "daily_limit",
      -  "warm_up",
      -  "send_window",
      -  "opt_out",
      -  "postal_address",
      -  "mailbox_link",
      -  "disconnect_inbox",
      -  "managed_domains",
      -  "check_domain",
      -  "create_managed_inbox",
      -  "save_sequence",
      -  "duplicate_sequence",
      -  "activate_sequence",
      -  "split_test",
      -  "end_split_test",
      -  "archive_sequence",
      -  "unarchive_sequence",
      -  "remove_sequence"
      -]New value: +[
      +  "signature",
      +  "daily_limit",
      +  "warm_up",
      +  "send_window",
      +  "opt_out",
      +  "postal_address",
      +  "disconnect_inbox",
      +  "create_managed_inbox",
      +  "save_sequence",
      +  "duplicate_sequence",
      +  "activate_sequence",
      +  "split_test",
      +  "end_split_test",
      +  "archive_sequence",
      +  "unarchive_sequence",
      +  "remove_sequence"
      +]
  2. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true, and the description goes well past them: 'Can't be undone' on remove_sequence, 'charges the domain fee again to the plan's card', queued sends cancelled and thread history retained on disconnect, and the deliverability warning that turning warm-up off burns the full daily limit. These are exactly the consequences an agent needs before invoking a destructive mutation, and they are not recoverable from the schema.

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?

Given 16 actions, the length is defensible and most lines earn their place, but the telegraphic style strains grammar ('An inbox's signature (empty clears it)') and the leading sentence is front-loaded with a parenthetical UI path instead of a verb. A short lead-in sentence naming the tool's job and the action-as-discriminator pattern would have improved scanability without adding bulk.

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?

For a 21-parameter destructive action router with no output schema, the definition covers preconditions, side effects, billing consequences, and idempotency for the risky actions. What it omits are return values (not required here) and the failure semantics of the quieter settings actions, such as what invalid hour ranges produce. Close to complete for the complexity involved.

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?

With only 5% schema description coverage across 21 parameters, the description carries nearly the whole burden and does so via an action(param, param) signature notation that maps parameters to the discriminate action. It adds meaning the schema cannot: dailyLimit bounds of 1 to 30 only for daily_limit, username defaults to the first name, platform values, redirectUrl defaulting to the site, and lines=null restoring the default opt-out. Minor gaps remain (no guidance on which fields save_sequence ignores versus preserves beyond 'what's left out stays'), but this is strong compensation.

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 opening line identifies the resource set (sending inbox settings and pitch sequences) and the 16-item action list makes the scope concrete. It is clear this mutates outreach configuration rather than reading it, and it names the readers to consult (get_settings, get_outreach). It loses a point because the first sentence is a noun fragment with no verb, so the actual 'what does this do' statement must be inferred from the action list.

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?

Per-action preconditions are explicit where they matter: create_managed_inbox is refused while another is being set up, requires the old inbox disconnected first, and is idempotent on repeat. It also points to get_outreach sequences and get_settings inbox for the ids the caller must supply. It does not, however, state broadly when to reach for this tool versus siblings like update_outreach or get_outreach, so the top-level routing is left implicit.

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.