align naming convention with actaul support in Claude and OpenAI models

Author: dsp-ant

docs/docs/learn/architecture.mdx

@@ -256,7 +256,7 @@ Now that the connection is established, the client can discover available tools
     "result": {
       "tools": [
         {
-          "name": "com.example.calculator/arithmetic",
+          "name": "calculator_arithmetic",
           "title": "Calculator",
           "description": "Perform mathematical calculations including basic arithmetic, trigonometric functions, and algebraic operations",
           "inputSchema": {
@@ -271,7 +271,7 @@ Now that the connection is established, the client can discover available tools
           }
         },
         {
-          "name": "com.example.weather/current",
+          "name": "weather_current",
           "title": "Weather Information",
           "description": "Get current weather information for any location worldwide",
           "inputSchema": {
@@ -307,7 +307,7 @@ The response contains a `tools` array that provides comprehensive metadata about
 
 Each tool object in the response includes several key fields:
 
-- **`name`**: A unique identifier for the tool within the server's namespace. This serves as the primary key for tool execution and should be URI-like for better namespacing (e.g., `com.example.calculator/arithmetic` rather than just `calculate`)
+- **`name`**: A unique identifier for the tool within the server's namespace. This serves as the primary key for tool execution and should follow a clear naming pattern (e.g., `calculator_arithmetic` rather than just `calculate`)
 - **`title`**: A human-readable display name for the tool that clients can show to users
 - **`description`**: Detailed explanation of what the tool does and when to use it
 - **`inputSchema`**: A JSON Schema that defines the expected input parameters, enabling type validation and providing clear documentation about required and optional parameters
@@ -332,7 +332,7 @@ The client can now execute a tool using the `tools/call` method. This demonstrat
 
 #### Understanding the Tool Execution Request
 
-The `tools/call` request follows a structured format that ensures type safety and clear communication between client and server. Note that we're using the proper tool name from the discovery response (`com.example.weather/current`) rather than a simplified name:
+The `tools/call` request follows a structured format that ensures type safety and clear communication between client and server. Note that we're using the proper tool name from the discovery response (`weather_current`) rather than a simplified name:
 
 <CodeGroup>
   ```json Request
@@ -341,7 +341,7 @@ The `tools/call` request follows a structured format that ensures type safety an
     "id": 3,
     "method": "tools/call",
     "params": {
-      "name": "com.example.weather/current",
+      "name": "weather_current",
       "arguments": {
         "location": "San Francisco",
         "units": "imperial"
@@ -369,7 +369,7 @@ The `tools/call` request follows a structured format that ensures type safety an
 
 The request structure includes several important components:
 
-1. **`name`**: Must match exactly the tool name from the discovery response (`com.example.weather/current`). This ensures the server can correctly identify which tool to execute.
+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: