fix(SEP-2322): Fix typos and format

Author: LucaButBoring

docs/specification/draft/basic/index.mdx

@@ -79,8 +79,8 @@ 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.
-- Extensions MAY add additional `ResultType` values. The set of supported `ResultTypes` MUST be created from the set defined in the core protocol and include any additional values of supported extensions that are advertised via capabilities.
--A `resultType` of any value unrecognized by the client **MUST** be considered invalid.
+- Extensions **MAY** add additional `ResultType` values. The set of supported `ResultType` values **MUST** be created from the set defined in the core protocol and include any additional values of supported extensions that are advertised via capabilities.
+- A `resultType` of any value unrecognized by the client **MUST** be considered invalid.
 - For backward compatibility with servers implementing earlier protocol versions, which do not include `resultType`, clients **MUST** treat an absent `resultType` as `"complete"`.
 
 #### Error Responses

seps/2322-MRTR.md

@@ -320,11 +320,11 @@ 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. If this field is not provided the Client should assume a `ResultType` of "complete" for backwards compatibility. 
+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.
 
-Extensions MAY add additional `ResultType` values. The set of supported `ResultTypes` MUST be created from the set defined in the core protocol and include any additional values of supported extensions that are advertised via capabilities.
+Extensions **MAY** add additional `ResultType` values. The set of supported `ResultType` values **MUST** be created from the set defined in the core protocol and include any additional values of supported extensions that are advertised via capabilities.
 
-The Client SHOULD treat unrecognized values as invalid protocol responses. 
+The Client **SHOULD** treat unrecognized values as invalid protocol responses.
 
 The schema change will look like this: