Streaming Skill Invocation: MCP Support for Long-Running Tasks
I. Limitations of Synchronous Invocation
In the standard MCP invocation model, after an Agent initiates an Action, it blocks waiting for the Skill to return a complete ActionResult. This synchronous request-response pattern works well in most scenarios. Operations such as querying orders, sending emails, and calculating prices typically complete within milliseconds to seconds.
However, many real AI tasks are inherently long-running. A video generation Skill may take several minutes to complete. A data training Skill may take several hours. A cross-system data synchronization Skill may take several days. In these scenarios, the limitations of synchronous invocation become very apparent.
The first limitation is timeout. Agents and gateways have timeout limits, typically set to tens of seconds. Long-running Skills will almost certainly trigger timeouts, causing invocation failure. The second limitation is user experience. Users do not want to stare at a blank screen waiting for minutes. They want to see progress, understand the current status, and even terminate tasks early. The third limitation is resource efficiency. Synchronous invocations occupy connections and thread resources for long periods, making scaling difficult.
MCP needs to extend its support for long-running tasks. This chapter will explore the design of streaming Skill invocation, including asynchronous mode, progress notifications, intermediate result delivery, and early termination mechanisms.
II. Asynchronous vs Streaming: Two Extension Modes
Before discussing specific designs, two different extension modes need to be distinguished: asynchronous invocation and streaming invocation.
Asynchronous invocation solves the problem of long waiting times. After the Agent initiates an Action, it immediately receives a task identifier without needing to wait for task completion. The Agent can later query task status and results using this identifier. This mode is suitable for batch processing tasks that do not require real-time user interaction.
Streaming invocation solves the problem of intermediate result visibility. After the Agent initiates an Action, the Skill continuously pushes events through a persistent connection, including progress updates, partial results, and log output. This mode is suitable for tasks where users can benefit from intermediate results or where real-time progress monitoring is needed.
The two modes can coexist or be combined. A long-running task can be executed asynchronously while also supporting streaming progress updates.
III. Design of Asynchronous Invocation in MCP
The current version of MCP has limited support for asynchronous invocation, but it can be achieved through extensions.
When an Agent calls a long-running Skill, it can set a flag asynchronous = true in the Action. After receiving this Action, the gateway does not set an execution timeout for the Skill but immediately returns an accepted response containing a task_id.
During execution, the Skill can periodically update the task status. The Agent queries status through a dedicated get_task_status Action. This Action takes task_id as input and returns the current status (pending, running, completed, failed) along with any completed partial results.
After the task completes, the Agent can retrieve the complete result through a get_task_result Action. The result can be cached for a period of time for multiple queries.
Peta provides built-in support for asynchronous invocation. When a Skill declares support for asynchronous mode, the Peta gateway automatically manages task queues and state storage. Skill developers only need to implement a start method and a status query method, without managing task persistence themselves.
IV. Design of Streaming Invocation in MCP
Streaming invocation is more complex than asynchronous invocation because it requires maintaining a continuous event stream.
MCP’s transport layer is currently primarily based on HTTP JSON-RPC. To achieve streaming, there are two technical paths: Server-Sent Events and WebSocket.
Server-Sent Events are one-way, from server to client, suitable for pushing progress updates. Implementation is simple, based on standard HTTP, and widely supported. The disadvantage is that it cannot send messages from client to server, making it less convenient for scenarios requiring early termination.
WebSocket is two-way, supporting mutual message exchange between client and server. Implementation is more complex but more powerful. It is suitable for tasks requiring mid-stream interaction, such as the user sending a cancellation instruction during task execution.
Peta supports both streaming transport methods. For read-only progress pushing, Server-Sent Events are recommended. For complex tasks requiring two-way interaction, WebSocket is recommended.
The protocol extension for streaming invocation is as follows. The Agent sets streaming = true in the Action and provides a streaming endpoint or WebSocket connection identifier. The gateway routes this Action to the Skill and passes the streaming channel information to the Skill. During execution, the Skill continuously sends events through this channel.
Event types can include the following. progress indicates task progress, containing a percentage and description text. log indicates task log, for debugging and auditing. partial_result indicates partial results, which can be provided to the Agent before task completion. heartbeat indicates the task is still running, preventing the connection from being意外 closed. complete indicates task completion, containing the final result. error indicates task failure, containing error information.
V. Design Patterns for Long-Running Skills
For long-running Skills, developers need to follow specific design patterns.
Pattern one: Return immediately, execute in background
After receiving an invocation request, the Skill immediately starts a background thread or asynchronous task, then quickly returns an accepted response. The background task executes independently, unaffected by HTTP connection timeouts. This pattern is suitable for tasks that can be fully processed asynchronously.
Pattern two: State persistence
Long-running tasks may encounter process restarts or node failures during execution. Skills should persist task state to reliable storage so that execution can continue after recovery. Peta provides a task state storage service that Skills can use directly.
Pattern three: Cancelable
Users or Agents may wish to cancel a task during its execution. Skills should implement cancellation logic, gracefully stopping the task upon receiving a cancellation signal, cleaning up resources, and updating status to cancelled.
Pattern four: Partial result delivery
For some tasks, partial results may be more valuable than final results. For example, a data scanning Skill can deliver partial results after scanning each data block, allowing the Agent to process these results early without waiting for full completion.
Pattern five: Heartbeat keepalive
Get Zhangshuang’s stories in your inbox
Join Medium for free to get updates from this writer.
Long-running connections may be closed by intermediate devices due to network idle. Skills should periodically send heartbeat events to keep the connection alive.
VI. Agent Handling of Streaming Invocation
When handling streaming invocation, Agents need corresponding capabilities.
The Agent should check whether a Skill supports streaming mode before invocation. The Skill specification should declare a streaming_supported flag and the types of events it supports. The Agent uses this information to decide whether to use streaming mode.
The Agent needs to be able to handle streaming event streams. This means the Agent’s reasoning loop cannot block waiting for the complete result. Instead, the Agent should react in real time as events are received.
For example, when receiving a progress event, the Agent can display progress information to the user. When receiving a partial result, the Agent can immediately use these results to continue subsequent tasks without waiting for full completion. When receiving an error event, the Agent can decide whether to retry, degrade, or abandon the task.
Peta’s Agent SDK provides an abstraction for streaming event handlers. Developers only need to implement a few callback functions. The SDK automatically manages the establishment of streaming connections and parsing of events.
VII. Gateway Streaming Proxy
The Peta gateway plays a proxy role in streaming invocation. It is responsible for forwarding streaming events between the Agent and the Skill, performing necessary conversion and enhancement.
After receiving a streaming Action, the gateway establishes a streaming connection to the Skill and maintains an event buffer. When the Skill sends events, the gateway forwards them to the Agent. If the Agent is temporarily offline or processing slowly, the gateway can cache events and send them later.
The gateway also records streaming events to the audit log. This is very important for compliance auditing, because partial results may contain sensitive data. Auditors can trace what intermediate information was transmitted during streaming invocations.
The gateway also supports policy control for streaming events. For example, policies can be configured to limit the size of partial results, preventing the Agent from receiving excessively large intermediate data. Policies can also be configured to filter certain sensitive events, blocking them from being delivered to the Agent.
VIII. Typical Scenario Examples
Scenario one: Video generation Skill
A user asks an Agent to generate a one-minute video. The Agent calls a video_generation Skill with streaming mode enabled. After the Skill starts processing, it sends a progress event every few seconds, showing current progress and estimated remaining time. The Agent displays this progress to the user. When ten seconds have been generated, the Skill sends a partial_result containing a preview of the first few seconds of video. The user can see the effect and decide whether to continue. If the user is not satisfied, they can terminate the task early. After task completion, the Skill sends a complete event containing the full video URL.
Scenario two: Big data analysis Skill
A data analyst asks an Agent to scan the past year’s logs to find anomaly patterns. The Agent calls a log_analysis Skill in asynchronous mode. The Skill returns a task_id, which the Agent stores in working memory. The analyst can leave and return later to query results. The Agent periodically calls get_task_status to check whether the task is complete. After the task completes, the Agent retrieves the result and notifies the analyst.
Scenario three: Cross-system data synchronization Skill
An enterprise needs to synchronize customer data from its CRM system to a data warehouse. The Agent calls a sync_customers Skill with streaming mode enabled. The Skill synchronizes customer records one by one, sending a progress event and a partial_result containing the number of customers synchronized so far after every hundred records. The Agent can monitor synchronization progress in real time. If a large number of errors are detected during synchronization, the Agent can decide to terminate the task early.
IX. Performance and Reliability Considerations for Streaming Invocation
Streaming invocation introduces new performance and reliability issues.
The first issue is connection management. Each streaming invocation occupies a long-lived connection. When the number of concurrent streaming invocations is large, connection resources can become a bottleneck. The solution is to use connection pooling and set idle timeouts for automatically closing connections.
The second issue is backpressure control. If the Skill generates events faster than the Agent can consume them, events will accumulate, potentially leading to memory exhaustion. The solution is to implement flow control mechanisms. When the Agent processes slowly, the Skill should reduce its event sending rate.
The third issue is reconnection after disconnection. Network instability may cause streaming connections to break. Agents should support reconnection, re-establishing the connection after disconnection and continuing to receive events from the point of interruption. Peta supports resumable transfer through event sequence numbers.
The fourth issue is audit log expansion. Streaming invocation generates a large number of events, each of which may be recorded in the audit log. This can cause the audit log to grow rapidly. The solution is to configure sampling strategies, recording only key events, or aggregating events for batch recording.
X. Summary: Streaming Invocation Expands MCP’s Capability Boundaries
The core conclusions of this chapter can be summarized as follows.
First, the standard synchronous request-response pattern cannot meet the needs of long-running tasks. Timeout, user experience, and resource efficiency are issues that must be addressed.
Second, asynchronous invocation solves the long waiting problem, while streaming invocation solves the intermediate result visibility problem. The two modes can coexist and be combined.
Third, MCP asynchronous invocation can be implemented through accepted responses plus task status queries. Peta provides built-in task management support.
Fourth, MCP streaming invocation can be implemented through Server-Sent Events or WebSocket. Event types include progress, log, partial_result, heartbeat, complete, and error.
Fifth, design patterns for long-running Skills include immediate return with background execution, state persistence, cancelability, partial result delivery, and heartbeat keepalive.
Sixth, Agents need to support streaming event processing, and gateways need to provide streaming proxy and event recording.
Seventh, streaming invocation faces challenges such as connection management, backpressure control, reconnection after disconnection, and audit log expansion, requiring corresponding solutions.
Streaming invocation expands MCP’s capability boundaries, enabling MCP to support everything from millisecond-level real-time queries to batch processing tasks lasting days. This is an important step for MCP to evolve from a lightweight protocol to enterprise-grade infrastructure.
In the next chapter, we will discuss the declarative language design and visual orchestration of MCP policies.
