SEP-2322: Explicitly support extending ResultType

Author: LucaButBoring

docs/seps/2322-MRTR.mdx

@@ -79,6 +79,7 @@ can use to determine how to parse and handle the `result` object.
 
 - A `resultType` of `"complete"` indicates the request completed successfully and the result contains the final content.
 - A `resultType` of `"input_required"` indicates the request is incomplete and more information is needed to process the request. The result contains an `InputRequiredResult` object with additional information needed.
+- A `resultType` of any value unrecognized by the client **MUST** be considered invalid. This field is open to extension.
 - For backward compatibility with servers implementing earlier protocol versions, which do not include `resultType`, clients **MUST** treat an absent `resultType` as `"complete"`.
 
 #### Error Responses

docs/seps/2663-tasks-extension.mdx

@@ -162,7 +162,7 @@ export interface Notification {
  * input_required - the request requires additional input and the result contains an {@link InputRequiredResult} object with instructions for the client to provide additional input before retrying the original request.
  * @category Common Types
  */
-export type ResultType = "complete" | "input_required";
+export type ResultType = "complete" | "input_required" | string;
 
 /**
  * Common result fields.

docs/specification/draft/basic/index.mdx

@@ -320,7 +320,7 @@ export interface InputResponseRequestParams extends RequestParams {
 }
 ```
 
-Since this change creates a polymorphic response for method calls like 'tools/call', we are introducing a new field to `Result` which indicate the `ResultType`. The client should parse this field to determine the type of the Result contained in the message. If this field is not provided the Client should assume a `ResultType` of "complete" for backwards compatibility. The schema change will look like this:
+Since this change creates a polymorphic response for method calls like 'tools/call', we are introducing a new field to `Result` which indicate the `ResultType`. The client should parse this field to determine the type of the Result contained in the message, treating unrecognized values as invalid protocol responses. The `ResultType` is open for extensions to introduce additional values. If this field is not provided the Client should assume a `ResultType` of "complete" for backwards compatibility. The schema change will look like this:
 
 ```typescript
 /**
@@ -337,7 +337,8 @@ export interface Result {
 
 export type ResultType =
   | "complete" // the request completed successfully and the result contains the final content.
-  | "input_required"; // the request is incomplete and the result contains an {@link InputRequiredResult} object
+  | "input_required" // the request is incomplete and the result contains an {@link InputRequiredResult} object
+  | string; // open to extensions
 ```
 
 We anticipate this field will be useful for future extensibility, as it allows us to introduce new types of results and can also apply to `tasks` as well.

docs/specification/draft/schema.mdx

@@ -122,7 +122,7 @@ A request that is eligible for task-augmentation may return one of two distinct
 
 ```typescript
 // "task" is introduced by this extension.
-type ResultType = "complete" | "input_required" | "task";
+type ResultType = "complete" | "input_required" | "task" | string;
 ```
 
 Servers **MUST** set `resultType` to `"task"` when returning a `CreateTaskResult` so that clients can distinguish it from a standard result. Servers **MUST NOT** set `resultType` to `"task"` on result types other than `CreateTaskResult`.