Update progress.md

Author: jspahrsummers

docs/specification/basic/utilities/progress.md

@@ -10,11 +10,10 @@ The Model Context Protocol (MCP) supports optional progress tracking for long-ru
 
 ## Progress Flow
 
-When a party wants to receive progress updates for a request, it includes a `progressToken` in the request metadata. Progress tokens can be any string or number value chosen by the sender, but MUST be unique across all active requests. The receiver can then send progress notifications containing:
+When a party wants to _receive_ progress updates for a request, it includes a `progressToken` in the request metadata.
 
-- The original progress token
-- Current progress value
-- Optional total value
+* Progress tokens **MUST** be a string or integer value
+* Progress tokens can be chosen by the sender using any means, but **MUST** be unique across all active requests.
 
 ```json
 {
@@ -29,7 +28,11 @@ When a party wants to receive progress updates for a request, it includes a `pro
 }
 ```
 
-The receiver MAY then send progress notifications:
+The receiver **MAY** then send progress notifications containing:
+
+- The original progress token
+- The current progress value so far
+- An optional "total" value
 
 ```json
 {
@@ -43,24 +46,20 @@ The receiver MAY then send progress notifications:
 }
 ```
 
-## Behavior Requirements
+* The `progress` value **MUST** increase with each notification, even if the total is unknown.
+* The `progress` and the `total` values **MAY** be floating point.
 
-Both clients and servers MUST follow these requirements when handling progress:
+## Behavior Requirements
 
-1. Progress notifications MUST only reference tokens that:
+1. Progress notifications **MUST** only reference tokens that:
    - Were provided in an active request
    - Are associated with an in-progress operation
 
-2. Receivers of progress requests MAY:
+2. Receivers of progress requests **MAY**:
    - Choose not to send any progress notifications
    - Send notifications at whatever frequency they deem appropriate
    - Omit the total value if unknown
 
-3. Senders SHOULD be prepared to:
-   - Handle missing progress notifications
-   - Receive notifications out of order
-   - Handle notifications after completion
-
 ```mermaid
 sequenceDiagram
     participant Sender
@@ -71,9 +70,9 @@ sequenceDiagram
 
     Note over Sender,Receiver: Progress updates
     loop Progress Updates
-        Receiver-->>Sender: Progress notification (50/100)
-        Receiver-->>Sender: Progress notification (75/100)
-        Receiver-->>Sender: Progress notification (100/100)
+        Receiver-->>Sender: Progress notification (0.2/1.0)
+        Receiver-->>Sender: Progress notification (0.6/1.0)
+        Receiver-->>Sender: Progress notification (1.0/1.0)
     end
 
     Note over Sender,Receiver: Operation complete
@@ -82,17 +81,6 @@ sequenceDiagram
 
 ## Implementation Notes
 
-- Receivers SHOULD use meaningful progress increments
-- Senders SHOULD track active progress tokens
-- Both parties SHOULD implement rate limiting
-- Progress tracking SHOULD stop on completion
-
-## Error Handling
-
-Invalid progress notifications SHOULD be ignored without error responses:
-
-- Unknown progress tokens
-- Out of order notifications
-- Malformed notifications
-
-This maintains the "fire and forget" nature of notifications while allowing for race conditions in asynchronous communication.
+- Senders and receivers **SHOULD** track active progress tokens
+- Both parties **SHOULD** implement rate limiting to prevent flooding
+- Progress notifications **MUST** stop after completion