Relax task augmentation with capabilities to "SHOULD", fix "task metadata" language

Author: LucaButBoring

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

@@ -94,11 +94,11 @@ Clients declare if they support tasks, and if so, which client-side requests can
 
 ### Capability Negotiation
 
-During the initialization phase, both parties exchange their `tasks` capabilities to establish which operations support task-based execution. Requestors **MUST** only augment requests with task metadata if the corresponding capability has been declared by the receiver.
+During the initialization phase, both parties exchange their `tasks` capabilities to establish which operations support task-based execution. Requestors **SHOULD** only augment requests with a task if the corresponding capability has been declared by the receiver.
 
-For example, if a server's capabilities include `tasks.requests.tools.call: {}`, then clients may augment `tools/call` requests with task metadata. If a client's capabilities include `tasks.requests.sampling.createMessage: {}`, then servers may augment `sampling/createMessage` requests with task metadata.
+For example, if a server's capabilities include `tasks.requests.tools.call: {}`, then clients may augment `tools/call` requests with a task. If a client's capabilities include `tasks.requests.sampling.createMessage: {}`, then servers may augment `sampling/createMessage` requests with a task.
 
-If `capabilities.tasks` is not defined, the peer **MUST NOT** attempt to create tasks during requests.
+If `capabilities.tasks` is not defined, the peer **SHOULD NOT** attempt to create tasks during requests.
 
 The set of capabilities in `capabilities.tasks.requests` is exhaustive. If a request type is not present, it does not support task-augmentation.
 
@@ -125,7 +125,7 @@ This is to be interpreted as a fine-grained layer in addition to capabilities, f
 Task-augmented requests follow a two-phase response pattern that differs from normal requests:
 
 - **Normal requests**: The server processes the request and returns the actual operation result directly.
-- **Task-augmented requests**: The server accepts the request and immediately returns a `CreateTaskResult` containing task metadata. The actual operation result becomes available later through `tasks/result` after the task completes.
+- **Task-augmented requests**: The server accepts the request and immediately returns a `CreateTaskResult` containing task data. The actual operation result becomes available later through `tasks/result` after the task completes.
 
 To create a task, requestors send a request with the `task` field included in the request params. Requestors **MAY** include a `ttl` value indicating the desired task lifetime duration (in milliseconds) since its creation.
 
@@ -167,7 +167,7 @@ To create a task, requestors send a request with the `task` field included in th
 }
 ```
 
-When a receiver accepts a task-augmented request, it returns a [`CreateTaskResult`](/specification/draft/schema#createtaskresult) containing task metadata. The response does not include the actual operation result. The actual result (e.g., tool result for `tools/call`) becomes available only through `tasks/result` after the task completes.
+When a receiver accepts a task-augmented request, it returns a [`CreateTaskResult`](/specification/draft/schema#createtaskresult) containing task data. The response does not include the actual operation result. The actual result (e.g., tool result for `tools/call`) becomes available only through `tasks/result` after the task completes.
 
 <Note>
 
@@ -219,7 +219,7 @@ Requestors **SHOULD** continue polling until the task reaches a terminal status
 
 ### Retrieving Task Results
 
-After a task completes the operation result is retrieved via [`tasks/result`](/specification/draft/schema#tasks%2Fresult). This is distinct from the initial `CreateTaskResult` response, which contains only task metadata. The result structure matches the original request type (e.g., `CallToolResult` for `tools/call`).
+After a task completes the operation result is retrieved via [`tasks/result`](/specification/draft/schema#tasks%2Fresult). This is distinct from the initial `CreateTaskResult` response, which contains only task data. The result structure matches the original request type (e.g., `CallToolResult` for `tools/call`).
 
 To retrieve the result of a completed task, requestors can send a `tasks/result` request:
 
@@ -279,7 +279,7 @@ When a task status changes, receivers **MAY** send a [`notifications/tasks/statu
 }
 ```
 
-The notification includes the full [`Task`](/specification/draft/schema#task) object with all task metadata fields, including the updated `status` and `statusMessage` (if present). This allows requestors to access the complete task state without making an additional `tasks/get` request.
+The notification includes the full [`Task`](/specification/draft/schema#task) object, including the updated `status` and `statusMessage` (if present). This allows requestors to access the complete task state without making an additional `tasks/get` request.
 
 Requestors **MUST NOT** rely on receiving this notifications, as it is 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.
 
@@ -481,7 +481,7 @@ sequenceDiagram
     participant C as Client (Requestor)
     participant S as Server (Receiver)
     Note over C,S: 1. Task Creation
-    C->>S: Request with task metadata (ttl)
+    C->>S: Request with task field (ttl)
     S->>C: CreateTaskResult (taskId, status: working, ttl, pollInterval)
     Note over C,S: 2. Task Polling
     C->>S: tasks/get (taskId)
@@ -511,7 +511,7 @@ sequenceDiagram
     Note over LLM,C: LLM initiates request
     LLM->>C: Request operation
 
-    Note over C,S: Client augments with task metadata
+    Note over C,S: Client augments with task
     C->>S: tools/call (ttl: 3600000)
     S->>C: CreateTaskResult (task-123, status: working)
 
@@ -635,7 +635,7 @@ sequenceDiagram
 
 ### Task
 
-A task represents the execution state of a request. The task metadata includes:
+A task represents the execution state of a request. The task state includes:
 
 - `taskId`: Unique identifier for the task
 - `status`: Current state of the task execution
@@ -750,7 +750,7 @@ Receivers **SHOULD** provide informative error messages to describe the cause of
 
 <Note>
 
-Receivers are not required to retain task metadata indefinitely. It is compliant behavior for a receiver to return an error stating the task cannot be found if it has purged an expired task.
+Receivers are not required to retain tasks indefinitely. It is compliant behavior for a receiver to return an error stating the task cannot be found if it has purged an expired task.
 
 </Note>