Merge branch 'main' into feat/user-agent

Author: LucaButBoring

docs/clients.mdx

@@ -89,7 +89,7 @@ This page provides an overview of applications that support the Model Context Pr
 | [WhatsMCP][WhatsMCP]                             | ❌          | ❌        | ✅      | ❌                     | ❌         | ❌    | ❓            |
 | [Windsurf Editor][Windsurf]                      | ❌          | ❌        | ✅      | ✅                     | ❌         | ❌    | ❓            |
 | [Witsy][Witsy]                                   | ❌          | ❌        | ✅      | ❓                     | ❌         | ❌    | ❓            |
-| [Zed][Zed]                                       | ❌          | ✅        | ❌      | ❌                     | ❌         | ❌    | ❓            |
+| [Zed][Zed]                                       | ❌          | ✅        | ✅      | ❌                     | ❌         | ❌    | ❓            |
 | [Zencoder][Zencoder]                             | ❌          | ❌        | ✅      | ❌                     | ❌         | ❌    | ❓            |
 
 

docs/community/sep-guidelines.mdx

@@ -31,7 +31,7 @@ Consider proposing a SEP if your change involves any of the following:
 There are three kinds of SEP:
 
 1. **Standards Track** SEP describes a new feature or implementation for the Model Context Protocol. It may also describe an interoperability standard that will be supported outside the core protocol specification.
-2. **Informational** SEP describes a Model Context Protocol design issue, or provides general guidelines or information to the MCP community, but does not propose a new feature. Informational SEPs do not necessarily represent a MCP community consensus or recommendation.
+2. **Informational** SEP describes a Model Context Protocol design issue, or provides general guidelines or information to the MCP community, but does not propose a new feature. Informational SEPs do not necessarily represent an MCP community consensus or recommendation.
 3. **Process** SEP describes a process surrounding MCP, or proposes a change to (or an event in) a process. Process SEPs are like Standards Track SEPs but apply to areas other than the MCP protocol itself.
 
 ## Submitting a SEP

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
@@ -1543,7 +1537,7 @@ static (string command, string[] arguments) GetCommandAndArguments(string[] args
 }
 ```
 
-This creates a MCP client that will connect to a server that is provided as a command line argument. It then lists the available tools from the connected server.
+This creates an MCP client that will connect to a server that is provided as a command line argument. It then lists the available tools from the connected server.
 
 ### Query processing logic
 

docs/quickstart/server.mdx

@@ -1076,7 +1076,7 @@ Save the file, and restart **Claude for Desktop**.
 
 ## Testing your server with Java client
 
-### Create a MCP Client manually
+### Create an MCP Client manually
 
 Use the `McpClient` to connect to the server:
 
@@ -1127,7 +1127,7 @@ For more information, see the [MCP Client Boot Starters](https://docs.spring.io/
 
 ## More Java MCP Server examples
 
-The [starter-webflux-server](https://github.com/spring-projects/spring-ai-examples/tree/main/model-context-protocol/weather/starter-webflux-server) demonstrates how to create a MCP server using SSE transport.
+The [starter-webflux-server](https://github.com/spring-projects/spring-ai-examples/tree/main/model-context-protocol/weather/starter-webflux-server) demonstrates how to create an MCP server using SSE transport.
 It showcases how to define and register MCP Tools, Resources, and Prompts, using the Spring Boot's auto-configuration capabilities.
 
 </Tab>