docs(seps): Mark SEP-2243 as Final

Author: kurtisvg

blog/archetypes/default.md

@@ -13,7 +13,6 @@ author:
   - ""
 
 tags: []
-
 # Optional per-post image for JSON-LD and OpenGraph (falls back to site
 # og-image.png). Place under static/posts/<slug>/ and reference relative to
 # static/.

docs/community/sep-guidelines.mdx

@@ -85,6 +85,7 @@ flowchart TD
 3. **Update the SEP number**: Once your PR is created, rename the file using the PR number (e.g., PR #1850 becomes `1850-your-feature-title.md`) and update the SEP header.
 
 4. **Find a Sponsor**: Tag a Core Maintainer or Maintainer from [the maintainer list](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/MAINTAINERS.md). Choose someone whose area relates to your proposal. Tips:
+
    - Tag 1-2 relevant maintainers, not everyone
    - Share your PR in the relevant Discord channel
    - If no response after 2 weeks, ask in `#general`

docs/community/seps/2243-http-standardization.mdx

@@ -389,14 +389,17 @@ HTTP parsers typically trim leading and trailing whitespace from header values.
 Clients MUST apply the following encoding rules in order:
 
 1. **Type conversion**: Convert the parameter value to its string representation:
+
    - `string`: Use the value as-is
    - `number`: Convert to decimal string representation (e.g., `42`, `3.14`)
    - `boolean`: Convert to lowercase `"true"` or `"false"`
 
 2. **Whitespace check**: If the string starts or ends with whitespace (space or tab):
+
    - Apply Base64 encoding (see below)
 
 3. **ASCII validation**: Check if the string contains only valid ASCII characters (0x20-0x7E):
+
    - If valid, proceed to step 4
    - If invalid (contains non-ASCII characters), apply Base64 encoding (see below)
 

docs/docs.json

@@ -412,7 +412,8 @@
               "seps/2085-governance-succession-and-amendment",
               "seps/2133-extensions",
               "seps/2148-contributor-ladder",
-              "seps/2149-working-group-charter-template"
+              "seps/2149-working-group-charter-template",
+              "seps/2243-http-standardization"
             ]
           },
           {
@@ -421,12 +422,6 @@
               "seps/2207-oidc-refresh-token-guidance",
               "seps/2260-Require-Server-requests-to-be-associated-with-Client-requests"
             ]
-          },
-          {
-            "group": "Draft",
-            "pages": [
-              "seps/2243-http-standardization"
-            ]
           }
         ]
       },

docs/docs/develop/build-client.mdx

@@ -319,11 +319,13 @@ You can find the complete `client.py` file [here](https://github.com/modelcontex
 ## Common Customization Points
 
 1. **Tool Handling**
+
    - Modify `process_query()` to handle specific tool types
    - Add custom error handling for tool calls
    - Implement tool-specific response formatting
 
 2. **Response Processing**
+
    - Customize how tool results are formatted
    - Add response filtering or transformation
    - Implement custom logging
@@ -378,16 +380,19 @@ When you submit a query:
 ## Best practices
 
 1. **Error Handling**
+
    - Always wrap tool calls in try-catch blocks
    - Provide meaningful error messages
    - Gracefully handle connection issues
 
 2. **Resource Management**
+
    - Use `AsyncExitStack` for proper cleanup
    - Close connections when done
    - Handle server disconnections
 
 3. **Security**
+
    - Store API keys securely in `.env`
    - Validate server responses
    - Be cautious with tool permissions
@@ -794,6 +799,7 @@ When you submit a query:
 ## Best practices
 
 1. **Error Handling**
+
    - Use TypeScript's type system for better error detection
    - Wrap tool calls in try-catch blocks
    - Provide meaningful error messages
@@ -1408,12 +1414,14 @@ When you submit a query:
 ## Best practices
 
 1. **Error Handling**
+
    - Leverage Kotlin's type system to model errors explicitly
    - Wrap external tool and API calls in `try-catch` blocks when exceptions are possible
    - Provide clear and meaningful error messages
    - Handle network timeouts and connection issues gracefully
 
 2. **Security**
+
    - Store API keys and secrets securely in `local.properties`, environment variables, or secret managers
    - Validate all external responses to avoid unexpected or unsafe data usage
    - Be cautious with permissions and trust boundaries when using tools
@@ -2021,16 +2029,19 @@ When you submit a query:
 ## Best practices
 
 1. **Error Handling**
+
    - Wrap tool calls in `begin`...`rescue` blocks
    - Provide meaningful error messages
    - Gracefully handle connection issues
 
 2. **Resource Management**
+
    - Always close the transport when done
    - Use `begin`...`ensure` for proper cleanup
    - Handle server disconnections
 
 3. **Security**
+
    - Store API keys securely in `.env`
    - Validate server responses
    - Be cautious with tool permissions

docs/docs/learn/architecture.mdx

@@ -373,6 +373,7 @@ The request structure includes several important components:
 1. **`name`**: Must match exactly the tool name from the discovery response (`weather_current`). This ensures the server can correctly identify which tool to execute.
 
 2. **`arguments`**: Contains the input parameters as defined by the tool's `inputSchema`. In this example:
+
    - `location`: "San Francisco" (required parameter)
    - `units`: "imperial" (optional parameter, defaults to "metric" if not specified)
 

docs/docs/learn/server-concepts.mdx

@@ -260,6 +260,7 @@ Consider a personalized AI travel planner application, with three connected serv
    ```
 
 2. **User selects resources to include:**
+
    - `calendar://my-calendar/June-2024` (from Calendar Server)
    - `travel://preferences/europe` (from Travel Server)
    - `travel://past-trips/Spain-2023` (from Travel Server)
@@ -269,10 +270,12 @@ Consider a personalized AI travel planner application, with three connected serv
    The AI first reads all selected resources to gather context - identifying available dates from the calendar, learning preferred airlines and hotel types from travel preferences, and discovering previously enjoyed locations from past trips.
 
    Using this context, the AI then executes a series of Tools:
+
    - `searchFlights()` - Queries airlines for NYC to Barcelona flights
    - `checkWeather()` - Retrieves climate forecasts for travel dates
 
    The AI then uses this information to create the booking and following steps, requesting approval from the user where necessary:
+
    - `bookHotel()` - Finds hotels within the specified budget
    - `createCalendarEvent()` - Adds the trip to the user's calendar
    - `sendEmail()` - Sends confirmation with trip details

docs/docs/tools/debugging.mdx

@@ -150,12 +150,14 @@ To override the default variables or provide your own, you can specify an
 Common initialization problems:
 
 1. **Path Issues**
+
    - Incorrect server executable path
    - Missing required files
    - Permission problems
    - Try using an absolute path for `command`
 
 2. **Configuration Errors**
+
    - Invalid JSON syntax
    - Missing required fields
    - Type mismatches
@@ -262,6 +264,7 @@ Use the Network panel to inspect:
 ### Development cycle
 
 1. Initial Development
+
    - Use [Inspector](/docs/tools/inspector) for basic testing
    - Implement core functionality
    - Add logging points
@@ -286,12 +289,14 @@ To test changes efficiently:
 ### Logging strategy
 
 1. **Structured Logging**
+
    - Use consistent formats
    - Include context
    - Add timestamps
    - Track request IDs
 
 2. **Error Handling**
+
    - Log stack traces
    - Include error context
    - Track error patterns
@@ -308,6 +313,7 @@ To test changes efficiently:
 When debugging:
 
 1. **Sensitive Data**
+
    - Sanitize logs
    - Protect credentials
    - Mask personal information
@@ -325,12 +331,14 @@ For a full treatment of MCP attack vectors and mitigations, see
 When encountering issues:
 
 1. **First Steps**
+
    - Check server logs
    - Test with [Inspector](/docs/tools/inspector)
    - Review configuration
    - Verify environment
 
 2. **Support Channels**
+
    - [GitHub issues](https://github.com/modelcontextprotocol/modelcontextprotocol/issues)
    - [GitHub discussions](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions)
 

docs/docs/tools/inspector.mdx

@@ -119,11 +119,13 @@ The Inspector provides several features for interacting with your MCP server:
 ### Development workflow
 
 1. Start Development
+
    - Launch Inspector with your server
    - Verify basic connectivity
    - Check capability negotiation
 
 2. Iterative testing
+
    - Make server changes
    - Rebuild the server
    - Reconnect the Inspector

docs/docs/tutorials/security/security_best_practices.mdx

@@ -537,6 +537,7 @@ the following attack vectors are possible:
 1. The client connects to **Server A** and receives a session ID.
 1. The attacker obtains an existing session ID and sends a malicious
    event to **Server B** with said session ID.
+
    - When a server supports
      [redelivery/resumable streams](/specification/latest/basic/transports#resumability-and-redelivery),
      deliberately terminating the request before receiving the response