Skip to main content
Glama

Set Live Activity Stream

set_live_activity_stream

Create or update a managed Live Activity stream by stable stream_key.

This is the preferred Live Activity MCP workflow. Do not use legacy start/update/end ids. The stream_key is the handle.

REMOTE DELIVERY BUDGET: Each non-noop operation can send a remote ActivityKit push. iOS applies device-dependent push-to-start and update budgets and may throttle delivery even after APNs accepts the request. Use one stable stream_key for each real-world activity and send updates when its user-visible state meaningfully changes. Event-driven transitions may be seconds apart—for example, successive steps in a short deployment—and should be sent promptly; do not delay them to satisfy a fixed minimum interval. Short bursts of genuine progress are expected. Avoid sustained polling, heartbeat updates, per-second timer ticks, unchanged values, and high-frequency churn that does not communicate a meaningful transition. Coalesce only redundant or excessively granular changes. Do not retry a successful call to force display: success means APNs accepted the push, not that the device displayed it.

First call starts the Live Activity. Later calls with the same stream_key, same content_state.type, and same target channels update it. Repeating the same payload returns operation "noop". Changing the type or target channels rotates to a new underlying Live Activity.

Keep content_state.type and target channels stable to avoid consuming another push-to-start operation. For countdowns, send timer fields once and let the device render elapsed time locally instead of sending frequent updates.

Supported content_state.type values: segmented_progress, progress, metrics, stats, alert, timer, value.

Icons work with stats, metrics, progress, segmented_progress, alert, timer, and value. Use Apple SF Symbol names for icons. Badges work with alert, progress, segmented_progress, and value. A top-level action adds the Live Activity tap/action button and can open an HTTP/HTTPS URL, run an iPhone Shortcut with shortcuts://run-shortcut?name=..., or trigger a backend webhook. A top-level secondary_action adds a second button for alert, progress, segmented_progress, and value Live Activities.

Examples: { "value": { "title": "Current revenue", "subtitle": "Today", "type": "value", "value": "$1,240", "color": "cyan", "icon": "dollarsign.circle", "badge": { "title": "Live", "color": "green" } }, "segmented_progress": { "title": "Deploying API", "subtitle": "Step 2 of 4", "type": "segmented_progress", "current_step": 2, "number_of_steps": 4 }, "progress": { "title": "Uploading build", "subtitle": "42% complete", "type": "progress", "percentage": 42 }, "metrics": { "title": "Server load", "subtitle": "Current usage", "type": "metrics", "metrics": [ { "label": "CPU", "value": 27, "unit": "%" } ] }, "stats": { "title": "Sales", "subtitle": "Last 15 minutes", "type": "stats", "metrics": [ { "label": "Revenue", "value": 12.8, "unit": "k" }, { "label": "Orders", "value": 37 }, { "label": "Avg Order", "value": "$346" } ] }, "alert": { "title": "Alert", "message": "Incident response started. Primary API is degraded across regions.", "type": "alert", "color": "magenta", "icon": { "symbol": "exclamationmark.circle", "color": "yellow" }, "badge": { "title": "Escalated", "color": "gray" } }, "timer": { "title": "Benchmark Run", "subtitle": "sampling performance", "type": "timer", "duration_seconds": 300, "color": "cyan", "counts_down": true } }

Action examples: { "open_url": { "title": "Open Runbook", "type": "open_url", "url": "https://example.com/runbook" }, "shortcut": { "title": "Chat with Jarvis", "type": "open_url", "url": "shortcuts://run-shortcut?name=Jarvis" }, "webhook": { "title": "Acknowledge", "type": "webhook", "url": "https://example.com/hooks/ack", "method": "POST", "body": { "incident_id": "inc_123" } } }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tagsNoOptional account tags used to organize Live Activity history.
alertNoOptional APNs alert payload shown when the Live Activity starts or updates.
actionNoOptional action button/tap target. Use { title, type: "open_url", url } with an HTTP/HTTPS URL or shortcuts://run-shortcut?name=... to open a URL or run an iPhone Shortcut. Use { title, type: "webhook", url, method, body } to call an HTTPS webhook. Webhook method can be GET or POST.
metadataNoOptional app-only details with string, number, or boolean values. Omit to preserve; send {} to clear. Never sent to ActivityKit.
stream_keyYesStable Live Activity stream key. Use the same key to update the same stream. Do not create new keys for routine updates: every new stream requires another remote start and uses the device's limited iOS push-to-start budget. Use only letters, numbers, underscores, and hyphens.
content_stateYesLive Activity content state. Set type to one of: segmented_progress, progress, metrics, stats, alert, timer, value. Use segmented_progress for step-based work, progress for continuous completion, metrics or stats for multiple values, value for one prominent string or number, alert for important status, and timer for countdown or elapsed time. Icons work with all types: use icon as an SF Symbol string or { symbol, color }, plus optional icon_color and icon_style. Badges work with alert, progress, segmented_progress, and value: use badge { title, color }. Other optional presentation fields include subtitle, color, auto_dismiss_seconds, and auto_dismiss_minutes.
secondary_actionNoOptional secondary action button for alert, progress, and segmented_progress Live Activities. Uses the same object shape as action.
target_channel_slugsNoOptional channel slugs to target. Omit to target the account-wide default delivery scope.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes far beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false). It discloses APNs remote delivery budgets, device-dependent push-to-start throttling, noop-on-identical-payload behavior, rotation to a new Live Activity when type/channels change, and the crucial caveat that success means APNs accepted the push, not that the device displayed it.

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?

Front-loaded with purpose, then budget semantics, then lifecycle mechanics, then type enumeration and examples. Well organized, but the seven content-type and three action JSON examples are lengthy and partially duplicate what the schema already documents, which dilutes the density somewhat.

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?

For a complex, high-blast-radius mutation tool with nested objects, this covers lifecycle, budget behavior, payload stability, action surfaces, and type compatibility. An output schema exists, so return values need not be described, and nothing an agent needs to call it correctly is missing.

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 100%, so the baseline is 3, but the description adds real meaning: which content_state.type maps to which use case, icon/badge compatibility per type, action vs secondary_action shapes and their supported Live Activity types, and why stream_key must stay stable. The inline examples also clarify the nested content_state structure beyond the terse schema property 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?

Opens with a specific verb+resource+key: 'Create or update a managed Live Activity stream by stable stream_key.' It immediately distinguishes itself from the legacy start/update/end id workflow, so an agent can tell which path to take without opening a schema.

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?

Rich when-to-use and when-not guidance: send updates on meaningful user-visible state changes, avoid sustained polling/heartbeats/per-second ticks, coalesce redundant changes, and don't retry a successful call. It does not, however, route the agent to the obvious siblings pause_live_activity_stream / resume_live_activity_stream / end_live_activity_stream for those lifecycle transitions.

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