Skip to content

Commit c0ae203

Browse files
LucaButBoringLucaButBoring
committed
chore: rename Task Jumpscares to Unsolicited Tasks
1 parent b085ce4 commit c0ae203

4 files changed

Lines changed: 11 additions & 15 deletions

File tree

‎docs/docs.json‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -413,7 +413,7 @@
413413
{
414414
"group": "Draft",
415415
"pages": [
416-
"seps/2229-task-jumpscares"
416+
"seps/2229-unsolicited-tasks"
417417
]
418418
}
419419
]

docs/seps/2229-task-jumpscares.mdx renamed to docs/seps/2229-unsolicited-tasks.mdx

Lines changed: 6 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11
---
2-
title: "SEP-2229: Task Jumpscares"
3-
sidebarTitle: "SEP-2229: Task Jumpscares"
4-
description: "Task Jumpscares"
2+
title: "SEP-2229: Unsolicited Tasks"
3+
sidebarTitle: "SEP-2229: Unsolicited Tasks"
4+
description: "Unsolicited Tasks"
55
---
66

77
<div className="flex items-center gap-2 mb-4">
@@ -16,7 +16,7 @@ description: "Task Jumpscares"
1616
| Field | Value |
1717
| ------------- | ------------------------------------------------------------------------------- |
1818
| **SEP** | 2229 |
19-
| **Title** | Task Jumpscares |
19+
| **Title** | Unsolicited Tasks |
2020
| **Status** | Draft |
2121
| **Type** | Standards Track |
2222
| **Created** | 2026-02-09 |
@@ -48,7 +48,7 @@ In practical terms, these flaws imply that an MCP server cannot make a clean bre
4848

4949
Furthermore, the requirement that task support be declared ahead of time makes task execution predictable, but also prematurely removes the possibility of only dispatching a task when there is real work to be done, along the lines of the .NET [ValueTask](https://learn.microsoft.com/en-us/dotNet/api/system.threading.tasks.valuetask?view=net-10.0). Allowing the requestor to dictate whether or not a task will be created eliminates the possibility of caching results or sending early return values, instead requiring the creation of a task on every request if tasks are supported by the requestor at all.
5050

51-
To both improve the adoption of tasks and to reduce their upfront messaging overhead, this proposal simplifies their execution model by allowing peers to "jumpscare" each other with tasks.
51+
To both improve the adoption of tasks and to reduce their upfront messaging overhead, this proposal simplifies their execution model by allowing peers to raise unsolicited tasks to each other.
5252

5353
## Specification
5454

@@ -100,7 +100,7 @@ The following statement will be removed:
100100
101101
## Rationale
102102

103-
### Jumpscares vs. Immediate Results
103+
### Unsolicited Tasks vs. Immediate Results
104104

105105
An [alternative proposal](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1905) handles the immediate result case individually, and with slightly different preconditions: _If_ tasks are supported, _and_ the client supports immediate task results, _then_ servers may return a regular result in response to a task-augmented request. That version of immediate results looked like a better option at the time, as it implied no breaking changes on top of the initial tasks specification.
106106

@@ -118,8 +118,6 @@ This addition is intended to avoid speculative `tasks/get` requests from request
118118

119119
## Backward Compatibility
120120

121-
### Jumpscares
122-
123121
The headline breaking changes of this proposal are:
124122

125123
1. Allowing a receiver to return a regular result even if the requestor explicitly asked for a task.

‎docs/seps/index.mdx‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -21,7 +21,7 @@ Specification Enhancement Proposals (SEPs) are the primary mechanism for proposi
2121
| SEP | Title | Status | Type | Created |
2222
| ------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------- | ------------------------------------------------- | ---------------- | ---------- |
2323
| [SEP-2260](/seps/2260-Require-Server-requests-to-be-associated-with-Client-requests) | Require Server requests to be associated with a Client request. | <Badge color="blue" shape="pill">Accepted</Badge> | Standards Track | 2026-02-16 |
24-
| [SEP-2229](/seps/2229-task-jumpscares) | Task Jumpscares | <Badge color="gray" shape="pill">Draft</Badge> | Standards Track | 2026-02-09 |
24+
| [SEP-2229](/seps/2229-unsolicited-tasks) | Unsolicited Tasks | <Badge color="gray" shape="pill">Draft</Badge> | Standards Track | 2026-02-09 |
2525
| [SEP-2133](/seps/2133-extensions) | Extensions | <Badge color="green" shape="pill">Final</Badge> | Standards Track | 2025-01-21 |
2626
| [SEP-2085](/seps/2085-governance-succession-and-amendment) | Governance Succession and Amendment Procedures | <Badge color="green" shape="pill">Final</Badge> | Process | 2025-12-05 |
2727
| [SEP-1865](/seps/1865-mcp-apps-interactive-user-interfaces-for-mcp) | MCP Apps - Interactive User Interfaces for MCP | <Badge color="green" shape="pill">Final</Badge> | Extensions Track | 2025-11-21 |

seps/2229-task-jumpscares.md renamed to seps/2229-unsolicited-tasks.md

Lines changed: 3 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
# SEP-2229: Task Jumpscares
1+
# SEP-2229: Unsolicited Tasks
22

33
- **Status**: Draft
44
- **Type**: Standards Track
@@ -29,7 +29,7 @@ In practical terms, these flaws imply that an MCP server cannot make a clean bre
2929

3030
Furthermore, the requirement that task support be declared ahead of time makes task execution predictable, but also prematurely removes the possibility of only dispatching a task when there is real work to be done, along the lines of the .NET [ValueTask](https://learn.microsoft.com/en-us/dotNet/api/system.threading.tasks.valuetask?view=net-10.0). Allowing the requestor to dictate whether or not a task will be created eliminates the possibility of caching results or sending early return values, instead requiring the creation of a task on every request if tasks are supported by the requestor at all.
3131

32-
To both improve the adoption of tasks and to reduce their upfront messaging overhead, this proposal simplifies their execution model by allowing peers to "jumpscare" each other with tasks.
32+
To both improve the adoption of tasks and to reduce their upfront messaging overhead, this proposal simplifies their execution model by allowing peers to raise unsolicited tasks to each other.
3333

3434
## Specification
3535

@@ -81,7 +81,7 @@ The following statement will be removed:
8181
8282
## Rationale
8383

84-
### Jumpscares vs. Immediate Results
84+
### Unsolicited Tasks vs. Immediate Results
8585

8686
An [alternative proposal](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1905) handles the immediate result case individually, and with slightly different preconditions: _If_ tasks are supported, _and_ the client supports immediate task results, _then_ servers may return a regular result in response to a task-augmented request. That version of immediate results looked like a better option at the time, as it implied no breaking changes on top of the initial tasks specification.
8787

@@ -99,8 +99,6 @@ This addition is intended to avoid speculative `tasks/get` requests from request
9999

100100
## Backward Compatibility
101101

102-
### Jumpscares
103-
104102
The headline breaking changes of this proposal are:
105103

106104
1. Allowing a receiver to return a regular result even if the requestor explicitly asked for a task.

0 commit comments

Comments
 (0)