Skip to main content
Glama

resume_broadcast

Continue a paused campaign now. It mails only the addresses still pending — the audience was frozen when the campaign started and everyone already reached is marked — so calling this twice cannot double-send. Only works on a paused campaign; anything else answers 409 invalid_state. pause_reason says why it paused. A background worker resumes quota, interrupted and suspension pauses on its own, so this only saves waiting. A warm-up pause cannot be resumed before its resume_after (409 invalid_state naming the time) and resumes on its own then; a retry answers the same, because the allowance is protecting the domain. While the workspace has no postal address or is suspended the call answers 422 no_postal_address or workspace_suspended: those need a person, and the campaign continues on its own once they are fixed. An A/B test paused mid-sample resumes the sample; one paused after the decision resumes the winner. Returns the campaign object, as get_broadcast does; progress.pending is how many addresses are still to send. The calling API key's guardrails apply: a key that holds its sends for approval (requires_approval) or has allowed_recipients gets 403 forbidden, because a campaign cannot be held for approval or kept to an allowlist. A retry answers the same; the campaign is sent by a person from the dashboard, or with a key without those guardrails. A key with a daily_send_limit is charged once for each campaign it puts on its way: sending or scheduling a draft counts its recipients, and starting a scheduled campaign now, moving it earlier, resuming it or deciding its winner counts what it still has to send, unless this key already paid for that campaign. When that does not fit what is left of the limit today the call answers 429 daily_limit and nothing changes; a retry the same day answers the same.

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": {
      "id": "<id>"
    },
    "name": "resume_broadcast"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesThe campaign's id from create_broadcast or list_broadcasts (a UUID), not its name

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / id / description
      Added value: +"The campaign's id from create_broadcast or list_broadcasts (a UUID), not its name"
  2. Added

TDQS

A4.5/5.0
Behavior5/5

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

Adds substantial non-obvious behavior beyond annotations: idempotent mailing behavior ('calling this twice cannot double-send'), automatic resume scenarios, 409/422/403/429 failure modes, and rate-limit charging semantics. This is far beyond what readOnlyHint false and destructiveHint false convey.

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 description is dense and arguably complete, but it is a long single block that repeats the same error/retry behavior multiple times ('A retry answers the same' appears twice) and mixes edge cases. It front-loads the core purpose but would benefit from bullets or sectioning, so it falls short of excellent conciseness.

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?

With no output schema, the description still tells the agent what is returned and how to interpret progress.pending. It covers all relevant error conditions, side effects, guardrails, and rate-limit interactions, so an agent calling this tool can predict outcomes without additional documentation.

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?

The input schema already describes the only parameter fully (source of id, UUID, not name), at 100% coverage. The description does not add parameter-specific meaning, and the baseline for fully covered schema parameters is 3.

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?

Opens with 'Continue a paused campaign now' — a specific verb plus resource. It then narrows scope by stating it only works on a paused campaign and clarifies A/B test behavior, distinguishing it from send_broadcast and pick_broadcast_winner without needing 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?

The description explicitly states when to use the tool ('Only works on a paused campaign'), when not to ('something else answers 409 invalid_state'), and when it is unnecessary ('background worker resumes... so this only saves waiting'). It also explains guardrail cases (requires_approval, allowed_recipients, daily_send_limit) that route calls away or predict failure.

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.