Chain dependent Discord calls into one request

Scenario: a community manager says "announce the office-hours session in #announcements, create a scheduled event for it, then give the host the event-host role." Three calls, each dependent on the last, exactly pipeline-shaped.

Pipelines are bounded: a maximum of 20 steps, and they cannot recurse, an mcp_pipeline step inside a pipeline returns PIPELINE_RECURSION and aborts. For long-running batch operations where each unit must fail independently, use the dedicated bulk tool for that resource instead.

Build the pipeline payload#

Each step declares id (for interpolation), tool, and args. String values inside args may reference {{step_id.path}}. Here the announcement's message_id flows into the event's description:

{
  "name": "mcp_pipeline",
  "arguments": {
    "steps": [
      {
        "id": "announce",
        "tool": "messages_send",
        "args": { "channel_id": "222233334444555566", "content": "Office hours start in 30 minutes!" }
      },
      {
        "id": "event",
        "tool": "events_create",
        "args": {
          "guild_id": "111122223333444455",
          "name": "Office hours",
          "scheduled_start_time": "2030-01-01T17:00:00Z",
          "scheduled_end_time": "2030-01-01T18:00:00Z",
          "entity_type": 3,
          "privacy_level": 2,
          "description": "Linked to announcement {{announce.message_id}}"
        }
      },
      {
        "id": "grant",
        "tool": "members_add_role",
        "args": { "guild_id": "111122223333444455", "user_id": "777788889999000011", "role_id": "555566667777888899" }
      }
    ]
  }
}

The response returns steps[] with per-step status, a variables interpolation namespace, total_duration_ms, and aborted.

Error handling#

• Default abort-on-error. When a step errors, the pipeline sets aborted: true and stops immediately. Subsequent steps aren't dispatched and don't appear in steps, the array simply ends at the failing step.
• Continue past errors. Set continue_on_error: true on a step to keep going, use sparingly since later steps must then tolerate missing interpolation values.
• Recursion guard. A step whose tool is mcp_pipeline is rejected up front with PIPELINE_RECURSION, before any step runs.
• Limit. Pipelines cap at 20 steps, split larger workloads across multiple pipelines or use the dedicated bulk tool for that resource.

Stopping is not rollback: any Discord side effect from an earlier successful step remains and must be compensated explicitly if your workflow requires reversal.

Why pipeline beats N separate calls#

Related tools#

mcp_pipeline full step schema including save_as and if. Building blocks used here: messages_send, events_create, members_add_role.

Next steps#

For parallelizable identical operations instead of a strict sequence, see stop a raid. For the executor internals behind interpolation and abort semantics, see how it works. Back to the overview.