Make notifications include full task info

Author: LucaButBoring

docs/specification/draft/basic/utilities/tasks.mdx

@@ -220,7 +220,7 @@ To retrieve the result of a completed task, requestors send a `tasks/result` req
 
 ### Task Creation Notification
 
-When a receiver creates a task, it **MUST** send a `notifications/tasks/created` notification to inform the requestor that the task has been created and polling can begin.
+When a receiver creates a task, it **MAY** send a `notifications/tasks/created` notification to inform the requestor that the task has been created and polling can begin. This notification includes the full task state.
 
 **Notification:**
 
@@ -229,6 +229,12 @@ When a receiver creates a task, it **MUST** send a `notifications/tasks/created`
   "jsonrpc": "2.0",
   "method": "notifications/tasks/created",
   "params": {
+    "taskId": "786512e2-9e0d-44bd-8f29-789f320fe840",
+    "status": "working",
+    "statusMessage": "The operation is now in progress.",
+    "createdAt": "2025-11-25T10:30:00Z",
+    "ttl": 60000,
+    "pollInterval": 5000,
     "_meta": {
       "modelcontextprotocol.io/related-task": {
         "taskId": "786512e2-9e0d-44bd-8f29-789f320fe840"
@@ -238,15 +244,13 @@ When a receiver creates a task, it **MUST** send a `notifications/tasks/created`
 }
 ```
 
-The task ID is conveyed through the `modelcontextprotocol.io/related-task` metadata key. The notification parameters are otherwise empty.
+The notification includes the full `Task` object with all task metadata fields, allowing requestors to immediately access the task state without making an additional `tasks/get` request.
 
-This notification resolves the race condition where a requestor might attempt to poll for a task before the receiver has finished creating it. By sending this notification immediately after task creation, the receiver signals that the task is ready to be queried via `tasks/get`.
-
-Receivers that do not support tasks (and thus ignore task metadata in requests) will not send this notification, allowing requestors to fall back to waiting for the original request response.
+Requestors **MUST NOT** rely on receiving this notification. Requestors **SHOULD** be prepared to begin polling via `tasks/get` immediately after receiving the `CreateTaskResult` response, regardless of whether this notification is received.
 
 ### Task Status Notification
 
-When a task's status changes, receivers **MAY** send a `notifications/tasks/status` notification to inform the requestor of the change.
+When a task's status changes, receivers **MAY** send a `notifications/tasks/status` notification to inform the requestor of the change. This notification includes the full task state.
 
 **Notification:**
 
@@ -255,7 +259,11 @@ When a task's status changes, receivers **MAY** send a `notifications/tasks/stat
   "jsonrpc": "2.0",
   "method": "notifications/tasks/status",
   "params": {
+    "taskId": "786512e2-9e0d-44bd-8f29-789f320fe840",
     "status": "completed",
+    "createdAt": "2025-11-25T10:30:00Z",
+    "ttl": 60000,
+    "pollInterval": 5000,
     "_meta": {
       "modelcontextprotocol.io/related-task": {
         "taskId": "786512e2-9e0d-44bd-8f29-789f320fe840"
@@ -265,12 +273,7 @@ When a task's status changes, receivers **MAY** send a `notifications/tasks/stat
 }
 ```
 
-The notification includes:
-
-- `status`: The new task status
-- `error` (optional): Error message if the status is `failed`
-
-The task ID is conveyed through the `modelcontextprotocol.io/related-task` metadata key.
+The notification includes the full `Task` object with all task metadata fields, including the updated `status`, `statusMessage` (if present), and `error` (if the status is `failed`). This allows requestors to access the complete task state without making an additional `tasks/get` request.
 
 Requestors **MUST NOT** rely on receiving these notifications, as they are optional. Receivers are not required to send status notifications and may choose to only send them for certain status transitions. Requestors **SHOULD** continue to poll via `tasks/get` to ensure they receive status updates.
 
@@ -430,6 +433,13 @@ stateDiagram-v2
 1. For example, an elicitation that a task-augmented tool call depends on **MUST** share the same related task ID with that tool call's task.
 1. For the `tasks/get`, `tasks/list`, `tasks/result`, and `tasks/cancel` operations, the `taskId` parameter in the request **MUST** be used as the source of truth for identifying the target task. Requestors **SHOULD NOT** include `modelcontextprotocol.io/related-task` metadata in these requests, and receivers **MUST** ignore such metadata if present in favor of the RPC method parameter.
 
+### Task Notifications
+
+1. Receivers **MAY** send a `notifications/tasks/created` notification after creating a task to inform the requestor that the task is ready for polling.
+1. Receivers **MAY** send `notifications/tasks/status` notifications when a task's status changes.
+1. Requestors **MUST NOT** rely on receiving either notification type, as they are both optional.
+1. When sent, these notifications **MUST** include the `modelcontextprotocol.io/related-task` metadata as described in "Associating Task-Related Messages".
+
 ### Task Progress Notifications
 
 Task-augmented requests support progress notifications as defined in the progress notification specification. The `progressToken` provided in the initial request remains valid throughout the task's lifetime.
@@ -458,9 +468,9 @@ sequenceDiagram
     participant C as Client (Requestor)
     participant S as Server (Receiver)
     Note over C,S: 1. Task Creation
-    C->>S: Request with task metadata (taskId, ttl)
+    C->>S: Request with task metadata (ttl)
     S->>C: CreateTaskResult (taskId, status: working, ttl, pollInterval)
-    S--)C: notifications/tasks/created
+    S--)C: notifications/tasks/created (full Task)
     Note over C,S: 2. Task Polling
     C->>S: tasks/get (taskId)
     S->>C: working
@@ -490,9 +500,9 @@ sequenceDiagram
     LLM->>C: Request operation
 
     Note over C,S: Client augments with task metadata
-    C->>S: tools/call (task-123, ttl: 3600000)
+    C->>S: tools/call (ttl: 3600000)
     S->>C: CreateTaskResult (task-123, status: working)
-    S--)C: notifications/tasks/created
+    S--)C: notifications/tasks/created (task-123, full Task)
 
     Note over LLM,C: Client continues processing other requests<br/>while task executes in background
     LLM->>C: Request other operation
@@ -547,9 +557,9 @@ sequenceDiagram
     Note over S: Server decides to initiate request
 
     Note over S,C: Server requests client operation (task-augmented)
-    S->>C: sampling/createMessage (request-789, ttl: 3600000)
+    S->>C: sampling/createMessage (ttl: 3600000)
     C->>S: CreateTaskResult (request-789, status: working)
-    C--)S: notifications/tasks/created
+    C--)S: notifications/tasks/created (request-789, full Task)
 
     Note over S: Server continues processing<br/>while waiting for result
 
@@ -590,9 +600,9 @@ sequenceDiagram
     participant S as Server (Receiver)
 
     Note over C,S: 1. Task Creation
-    C->>S: tools/call (request ID: 42, task-123)
+    C->>S: tools/call (request ID: 42, ttl: 60000)
     S->>C: CreateTaskResult (task-123, status: working)
-    S--)C: notifications/tasks/created
+    S--)C: notifications/tasks/created (task-123, full Task)
 
     Note over C,S: 2. Task Processing
     C->>S: tasks/get (task-123)