Merge pull request modelcontextprotocol#1328 from jonathanhefner/fix-build

Fix CI

Author: jonathanhefner

docs/docs/learn/architecture.mdx

@@ -372,7 +372,6 @@ 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

@@ -225,7 +225,6 @@ Consider an AI application with three connected servers:
    ```
 
 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)

docs/legacy/concepts/architecture.mdx

@@ -105,7 +105,6 @@ Key classes include:
 The transport layer handles the actual communication between clients and servers. MCP supports multiple transport mechanisms:
 
 1. **Stdio transport**
-
    - Uses standard input/output for communication
    - Ideal for local processes
 
@@ -288,7 +287,6 @@ if __name__ == "__main__":
 ### Transport selection
 
 1. **Local communication**
-
    - Use stdio transport for local processes
    - Efficient for same-machine communication
    - Simple process management
@@ -300,14 +298,12 @@ if __name__ == "__main__":
 ### Message handling
 
 1. **Request processing**
-
    - Validate inputs thoroughly
    - Use type-safe schemas
    - Handle errors gracefully
    - Implement timeouts
 
 2. **Progress reporting**
-
    - Use progress tokens for long operations
    - Report progress incrementally
    - Include total progress when known
@@ -320,20 +316,17 @@ if __name__ == "__main__":
 ## Security considerations
 
 1. **Transport security**
-
    - Use TLS for remote connections
    - Validate connection origins
    - Implement authentication when needed
 
 2. **Message validation**
-
    - Validate all incoming messages
    - Sanitize inputs
    - Check message size limits
    - Verify JSON-RPC format
 
 3. **Resource protection**
-
    - Implement access controls
    - Validate resource paths
    - Monitor resource usage
@@ -348,14 +341,12 @@ if __name__ == "__main__":
 ## Debugging and monitoring
 
 1. **Logging**
-
    - Log protocol events
    - Track message flow
    - Monitor performance
    - Record errors
 
 2. **Diagnostics**
-
    - Implement health checks
    - Monitor connection state
    - Track resource usage

docs/legacy/concepts/sampling.mdx

@@ -77,7 +77,6 @@ The `messages` array contains the conversation history to send to the LLM. Each
 The `modelPreferences` object allows servers to specify their model selection preferences:
 
 - `hints`: Array of model name suggestions that clients can use to select an appropriate model:
-
   - `name`: String that can match full or partial model names (e.g. "claude-3", "sonnet")
   - Clients may map hints to equivalent models from different providers
   - Multiple hints are evaluated in preference order

docs/legacy/tools/debugging.mdx

@@ -16,13 +16,11 @@ This guide is for macOS. Guides for other platforms are coming soon.
 MCP provides several tools for debugging at different levels:
 
 1. **MCP Inspector**
-
    - Interactive debugging interface
    - Direct server testing
    - See the [Inspector guide](/legacy/tools/inspector) for details
 
 2. **Claude Desktop Developer Tools**
-
    - Integration testing
    - Log collection
    - Chrome DevTools integration
@@ -39,7 +37,6 @@ MCP provides several tools for debugging at different levels:
 The Claude.app interface provides basic server status information:
 
 1. Click the <img src="/images/claude-desktop-mcp-plug-icon.svg" style={{display: 'inline', margin: 0, height: '1.3em'}} /> icon to view:
-
    - Connected servers
    - Available prompts and resources
 
@@ -133,14 +130,12 @@ To override the default variables or provide your own, you can specify an `env`
 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
@@ -213,7 +208,6 @@ In client applications:
 ### Development cycle
 
 1. Initial Development
-
    - Use [Inspector](/legacy/tools/inspector) for basic testing
    - Implement core functionality
    - Add logging points
@@ -236,14 +230,12 @@ 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
@@ -260,7 +252,6 @@ To test changes efficiently:
 When debugging:
 
 1. **Sensitive Data**
-
    - Sanitize logs
    - Protect credentials
    - Mask personal information
@@ -275,14 +266,12 @@ When debugging:
 When encountering issues:
 
 1. **First Steps**
-
    - Check server logs
    - Test with [Inspector](/legacy/tools/inspector)
    - Review configuration
    - Verify environment
 
 2. **Support Channels**
-
    - GitHub issues
    - GitHub discussions
 

docs/legacy/tools/inspector.mdx

@@ -119,13 +119,11 @@ 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/quickstart/client.mdx

@@ -305,13 +305,11 @@ You can find the complete `client.py` file [here.](https://gist.github.com/zckly
 ## 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
@@ -366,13 +364,11 @@ 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
@@ -776,7 +772,6 @@ 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
@@ -1390,7 +1385,6 @@ 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

docs/specification/2024-11-05/architecture/index.mdx

@@ -83,22 +83,19 @@ MCP is built on several key design principles that inform its architecture and
 implementation:
 
 1. **Servers should be extremely easy to build**
-
    - Host applications handle complex orchestration responsibilities
    - Servers focus on specific, well-defined capabilities
    - Simple interfaces minimize implementation overhead
    - Clear separation enables maintainable code
 
 2. **Servers should be highly composable**
-
    - Each server provides focused functionality in isolation
    - Multiple servers can be combined seamlessly
    - Shared protocol enables interoperability
    - Modular design supports extensibility
 
 3. **Servers should not be able to read the whole conversation, nor "see into" other
    servers**
-
    - Servers receive only necessary contextual information
    - Full conversation history stays with the host
    - Each server connection maintains isolation

docs/specification/2024-11-05/basic/utilities/progress.mdx

@@ -56,7 +56,6 @@ The receiver **MAY** then send progress notifications containing:
 ## Behavior Requirements
 
 1. Progress notifications **MUST** only reference tokens that:
-
    - Were provided in an active request
    - Are associated with an in-progress operation
 

docs/specification/2024-11-05/client/roots.mdx

@@ -165,7 +165,6 @@ Example error:
 ## Security Considerations
 
 1. Clients **MUST**:
-
    - Only expose roots with appropriate permissions
    - Validate all root URIs to prevent path traversal
    - Implement proper access controls
@@ -179,7 +178,6 @@ Example error:
 ## Implementation Guidelines
 
 1. Clients **SHOULD**:
-
    - Prompt users for consent before exposing roots to servers
    - Provide clear user interfaces for root management
    - Validate root accessibility before exposing