Skip to content

Commit 82fb2c4

Browse files
LucaButBoringLucaButBoring
committed
SEP-2663: Remove tasks from core spec; adjust MRTR
1 parent a05d7f9 commit 82fb2c4

11 files changed

Lines changed: 61 additions & 3757 deletions

File tree

‎docs/seps/2663-tasks-extension.mdx‎

Lines changed: 10 additions & 10 deletions
Some generated files are not rendered by default. Learn more about customizing how changed files appear on GitHub.

‎docs/specification/draft/basic/lifecycle.mdx‎

Lines changed: 14 additions & 35 deletions
Original file line numberDiff line numberDiff line change
@@ -70,16 +70,6 @@ The client **MUST** initiate this phase by sending an `initialize` request conta
7070
"elicitation": {
7171
"form": {},
7272
"url": {}
73-
},
74-
"tasks": {
75-
"requests": {
76-
"elicitation": {
77-
"create": {}
78-
},
79-
"sampling": {
80-
"createMessage": {}
81-
}
82-
}
8373
}
8474
},
8575
"clientInfo": {
@@ -119,15 +109,6 @@ The server **MUST** respond with its own capabilities and information:
119109
},
120110
"tools": {
121111
"listChanged": true
122-
},
123-
"tasks": {
124-
"list": {},
125-
"cancel": {},
126-
"requests": {
127-
"tools": {
128-
"call": {}
129-
}
130-
}
131112
}
132113
},
133114
"serverInfo": {
@@ -193,22 +174,20 @@ available during the connection.
193174

194175
Key capabilities include:
195176

196-
| Category | Capability | Description |
197-
| -------- | -------------- | ---------------------------------------------------------------------------------------- |
198-
| Client | `roots` | Ability to provide filesystem [roots](/specification/draft/client/roots) |
199-
| Client | `sampling` | Support for LLM [sampling](/specification/draft/client/sampling) requests |
200-
| Client | `elicitation` | Support for server [elicitation](/specification/draft/client/elicitation) requests |
201-
| Client | `tasks` | Support for [task-augmented](/specification/draft/basic/utilities/tasks) client requests |
202-
| Client | `extensions` | Support for optional [extensions](/docs/extensions/overview) beyond the core protocol |
203-
| Client | `experimental` | Describes support for non-standard experimental features |
204-
| Server | `prompts` | Offers [prompt templates](/specification/draft/server/prompts) |
205-
| Server | `resources` | Provides readable [resources](/specification/draft/server/resources) |
206-
| Server | `tools` | Exposes callable [tools](/specification/draft/server/tools) |
207-
| Server | `logging` | Emits structured [log messages](/specification/draft/server/utilities/logging) |
208-
| Server | `completions` | Supports argument [autocompletion](/specification/draft/server/utilities/completion) |
209-
| Server | `tasks` | Support for [task-augmented](/specification/draft/basic/utilities/tasks) server requests |
210-
| Server | `extensions` | Support for optional [extensions](/docs/extensions/overview) beyond the core protocol |
211-
| Server | `experimental` | Describes support for non-standard experimental features |
177+
| Category | Capability | Description |
178+
| -------- | -------------- | ------------------------------------------------------------------------------------- |
179+
| Client | `roots` | Ability to provide filesystem [roots](/specification/draft/client/roots) |
180+
| Client | `sampling` | Support for LLM [sampling](/specification/draft/client/sampling) requests |
181+
| Client | `elicitation` | Support for server [elicitation](/specification/draft/client/elicitation) requests |
182+
| Client | `extensions` | Support for optional [extensions](/docs/extensions/overview) beyond the core protocol |
183+
| Client | `experimental` | Describes support for non-standard experimental features |
184+
| Server | `prompts` | Offers [prompt templates](/specification/draft/server/prompts) |
185+
| Server | `resources` | Provides readable [resources](/specification/draft/server/resources) |
186+
| Server | `tools` | Exposes callable [tools](/specification/draft/server/tools) |
187+
| Server | `logging` | Emits structured [log messages](/specification/draft/server/utilities/logging) |
188+
| Server | `completions` | Supports argument [autocompletion](/specification/draft/server/utilities/completion) |
189+
| Server | `extensions` | Support for optional [extensions](/docs/extensions/overview) beyond the core protocol |
190+
| Server | `experimental` | Describes support for non-standard experimental features |
212191

213192
Capability objects can describe sub-capabilities like:
214193

‎docs/specification/draft/basic/utilities/cancellation.mdx‎

Lines changed: 0 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -33,7 +33,6 @@ notification containing:
3333
- Were previously issued in the same direction
3434
- Are believed to still be in-progress
3535
1. The `initialize` request **MUST NOT** be cancelled by clients
36-
1. For [task-augmented requests](./tasks), the `tasks/cancel` request **MUST** be used instead of the `notifications/cancelled` notification. Tasks have their own dedicated cancellation mechanism that returns the final task state.
3736
1. Receivers of cancellation notifications **SHOULD**:
3837
- Stop processing the cancelled request
3938
- Free associated resources

‎docs/specification/draft/basic/utilities/mrtr.mdx‎

Lines changed: 13 additions & 22 deletions
Original file line numberDiff line numberDiff line change
@@ -174,12 +174,11 @@ indicating that additional input is needed before the request can be completed.
174174

175175
Servers **MAY** send `InputRequiredResult` responses on the following client requests:
176176

177-
| Client Request | Supports InputRequiredResult |
178-
| ------------------------------------------------------------------------------------ | ---------------------------- |
179-
| [`prompts/get`](/specification/draft/server/prompts#getting-a-prompt) | Yes |
180-
| [`resources/read`](/specification/draft/server/resources#reading-resources) | Yes |
181-
| [`tools/call`](/specification/draft/server/tools#calling-tools) | Yes |
182-
| [`tasks/result`](/specification/draft/basic/utilities/tasks#retrieving-task-results) | Yes |
177+
| Client Request | Supports InputRequiredResult |
178+
| --------------------------------------------------------------------------- | ---------------------------- |
179+
| [`prompts/get`](/specification/draft/server/prompts#getting-a-prompt) | Yes |
180+
| [`resources/read`](/specification/draft/server/resources#reading-resources) | Yes |
181+
| [`tools/call`](/specification/draft/server/tools#calling-tools) | Yes |
183182

184183
Servers **MUST NOT** send `InputRequiredResult` responses on any other client requests.
185184

@@ -250,7 +249,7 @@ what is directly present in the retry request.
250249

251250
### Tasks Workflow
252251

253-
For long-running operations that require server-side state, the persistent workflow leverages [Tasks](/specification/draft/basic/utilities/tasks). The `input_required` task status indicates that additional information is needed.
252+
For long-running operations that require server-side state, the persistent workflow leverages [Tasks](/seps/2663-tasks-extension). The `input_required` task status indicates that additional information is needed.
254253

255254
```mermaid
256255
sequenceDiagram
@@ -266,35 +265,27 @@ sequenceDiagram
266265
C->>S: tasks/get (id: 2, taskId)
267266
S-->>C: Result (id: 2, status: input_required)
268267
269-
C->>S: tasks/result (id: 3, taskId)
270-
S-->>C: InputRequiredResult (id: 3, ElicitRequest)
271-
272268
C->>U: Prompts user for input
273269
U-->>C: Provides responses
274270
275-
C->>S: tasks/input_response (id: 4, taskId, ElicitResult)
276-
S-->>C: Result (id: 4, acknowledged)
271+
C->>S: tasks/update (id: 3, taskId, ElicitResult)
272+
S-->>C: Result (id: 3, acknowledged)
277273
278274
note over C,S: Processing resumes, Client polls
279-
C->>S: tasks/get (id: 5, taskId)
280-
S-->>C: Result (id: 5, status: completed)
281-
282-
C->>S: tasks/result (id: 6, taskId)
283-
S-->>C: Result (id: 6, final content)
275+
C->>S: tasks/get (id: 4, taskId)
276+
S-->>C: Result (id: 4, status: completed, final content)
284277
```
285278

286279
#### Server Requirements (Tasks)
287280

288281
1. Servers **MAY** respond to `tasks/get` by indicating that the task is in status `input_required`.
289-
1. Servers **MUST** include an `inputRequests` field in the `tasks/result` response when the task is in status `input_required`.
282+
1. Servers **MUST** include an `inputRequests` field in the `tasks/get` response when the task is in status `input_required`.
290283
1. `inputRequests` keys are server assigned identifiers and **MUST** be unique within the scope of a `Task`.
291-
292-
1. Servers **MAY** include a `requestState` field in the `tasks/result` response when the task is in status `input_required`.
284+
1. Servers **MAY** include a `requestState` field in the `tasks/get` response when the task is in status `input_required`.
293285

294286
#### Client Requirements (Tasks)
295287

296-
1. When `tasks/get` shows status `input_required`, clients **MUST** call `tasks/result` to get the `inputRequests` and optional `requestState`.
297-
1. Clients **SHOULD** construct the results of those requests and call [`tasks/input_response`](/specification/draft/basic/utilities/tasks#providing-input-for-tasks) with the `inputResponses` & `requestState` (if present).
288+
1. When `tasks/get` shows status `input_required`, clients **SHOULD** construct the results of those requests and call [`tasks/update`](seps/2663-tasks-extension#task-input-requests) with the `inputResponses` & `requestState` (if present).
298289
1. Clients **MAY** choose not to fulfill the input requests, in which case they **MAY** cancel the task.
299290

300291
### Error Handling

‎docs/specification/draft/basic/utilities/progress.mdx‎

Lines changed: 0 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -66,10 +66,6 @@ The receiver **MAY** then send progress notifications containing:
6666
- Send notifications at whatever frequency they deem appropriate
6767
- Omit the total value if unknown
6868

69-
3. For [task-augmented requests](./tasks), the `progressToken` provided in the original request **MUST** continue to be used for progress notifications throughout the task's lifetime, even after the `CreateTaskResult` has been returned. The progress token remains valid and associated with the task until the task reaches a terminal status.
70-
- Progress notifications for tasks **MUST** use the same `progressToken` that was provided in the initial task-augmented request
71-
- Progress notifications for tasks **MUST** stop after the task reaches a terminal status (`completed`, `failed`, or `cancelled`)
72-
7369
```mermaid
7470
sequenceDiagram
7571
participant Sender

0 commit comments

Comments
 (0)