# Multichat MCP Server ## Project Overview This project is part of a larger effort to refactor a FiveM resource, aiming for a more robust and maintainable codebase. We are leveraging the Model Context Protocol (MCP) to extend the resource's capabilities by integrating with external services and APIs. The `multichat-mcp` server specifically focuses on enabling communication with multiple unichat-based MCP servers simultaneously. This allows us to query different language models and combine their responses, potentially leading to more comprehensive and nuanced results. It acts as a standard MCP server, exposing a `multichat` tool that the host (Roo/Cline) can use. The `multichat-mcp` server then manages the client connections to the other unichat servers. ## Current Issue We were facing an issue with making cross-server MCP calls. The initial goal was to use the `multichat-mcp` server to directly call the `unichat` tool on other MCP servers, specifically `Lacayo 1` and `openrouter-chat`. However, these calls were consistently returning a "Method not found" error (-32601). Direct calls to the `unichat` tools on `Lacayo 1` and `openrouter-chat` using the `use_mcp_tool` command *do* work correctly. This initially suggested the problem was within `multichat-mcp`'s cross-server communication. However, after extensive troubleshooting and research, we discovered that MCP does *not* support direct server-to-server communication. The host (Roo/Cline) is responsible for coordinating all communication between servers. ## Troubleshooting Steps and Approaches Tried We have taken the following steps to diagnose and resolve the "Method not found" error, exploring various approaches: 1. **Verified MCP Server Configurations:** We carefully reviewed the `cline_mcp_settings.json` file to ensure that all servers (`multichat`, `Lacayo 1`, and `openrouter-chat`) are correctly configured, with the correct commands, arguments, and environment variables. 2. **Checked JSON-RPC Request Formats:** We consulted the MCP documentation and examples to ensure that the JSON-RPC requests sent by `multichat-mcp` were correctly formatted, including the `method`, `params`, and `id` fields. 3. **Tested Direct Calls:** We confirmed that direct calls to the `unichat` tools on `Lacayo 1` and `openrouter-chat` using `use_mcp_tool` work as expected. This isolated the issue to the cross-server communication attempts within `multichat-mcp`. 4. **Consulted Documentation via Perplexity:** We used the Perplexity MCP server extensively to search for relevant MCP documentation, examples, and troubleshooting tips. We specifically searched for: * "Model Context Protocol (MCP) cross-server communication best practices. How to make requests between MCP servers, server discovery, and client connection management. Focus on official documentation and examples." * "Model Context Protocol (MCP) client connection handling and authentication. How to properly establish and verify connections between clients and servers in MCP. Focus on official documentation and TypeScript SDK examples." * "MCP (Model Context Protocol) exact method names for tool execution. Looking for real-world examples of tool/call usage, JSON-RPC method names, and successful client-server interactions in the TypeScript SDK. Focus on GitHub issues and discussions about method naming." * "Model Context Protocol (MCP) implementations on GitHub, focusing on server-to-server communication and cross-server request handling. Look for TypeScript/JavaScript examples from the last year. Include request routing and message passing patterns." These searches helped us understand the core principles of MCP, the correct method names (`tools/list` and `tools/call`), and the client-host-server architecture. We learned that direct server-to-server communication is *not* supported. 5. **Modified Server Code (Multiple Iterations):** We iteratively modified the `multichat-mcp` server code (`src/index.ts` and `src/server.ts`) to try different approaches, including: * **Incorrect Approaches (Discarded):** * Attempting direct server-to-server calls using raw JSON-RPC requests and stdio manipulation. This was based on a misunderstanding of the MCP architecture. * Creating multiple `Client` instances within a loop, each attempting to connect to a different server. This is incorrect as each client should connect to a single server. * Trying to use a custom `mcp_instructions` response type to instruct the host to make calls. MCP does not support custom message types for cross-server communication. * Using incorrect method names like `tool/call` (singular) instead of `tools/call` (plural). * Attempting to use `rpc.discover` and `mcp.tools.list` which are not standard MCP methods. * Trying to use a `tool/route` notification, which is not a standard MCP method. * **Correct Approach (Current Implementation):** * Creating a single `Client` instance *per target server* (Lacayo 1, openrouter-chat) and storing them in a `Map`. * Using the `StdioClientTransport` to spawn the `unichat-ts-mcp-server` as a subprocess. This is necessary because `multichat-mcp` needs to act as a *client* to the unichat servers. * Using the `client.listTools()` method to verify the connection and discover available tools. * Using the `client.request()` method with the correct `tools/call` method name and parameters, following the standard JSON-RPC 2.0 format. * Using the `client.connect()` and handling the transport correctly. * Properly initializing the client with capabilities. * Using Zod schema validation to ensure the request and response formats are correct. * Ensuring the necessary dependencies are installed (`package.json`) and the code is correctly built (`tsconfig.json` and `npm run build`). ## Current Status The `multichat-mcp` server is currently still returning "Method not found" errors. We are still debugging the issue, but we have made significant progress in understanding the correct MCP architecture and implementation patterns. We are now using the correct client-server communication model, but there may still be subtle issues with our request formatting or server configuration. **Files Involved:** * `src/server.ts`: The main server implementation. * `src/index.ts`: The server entry point. * `package.json`: Dependencies and build scripts. * `tsconfig.json`: TypeScript configuration. * `../../../../../../Users/kurror/AppData/Roaming/Code/User/globalStorage/rooveterinaryinc.roo-cline/settings/cline_mcp_settings.json`: MCP server configuration file. ## Installation **Prerequisites:** * Node.js and npm installed on your system. **Steps:** 1. Navigate to the MCP servers directory: ```bash cd C:\\Users\\kurror\\AppData\\Roaming\\Roo-Code\\MCP ``` 2. Clone or create the `multichat-mcp` directory. 3. Place the server files (`package.json`, `tsconfig.json`, `src/index.ts`, `src/server.ts`) inside the `multichat-mcp` directory. 4. Install the dependencies: ```bash npm install ``` 5. Build the TypeScript code: ```bash npm run build ``` ## Configuration To enable the `multichat-mcp` server, you need to add its configuration to the `cline_mcp_settings.json` file, located at `C:\\Users\\kurror\\AppData\\Roaming\\Code\\User\\globalStorage\\rooveterinaryinc.roo-cline\\settings\\cline_mcp_settings.json`. Add the following entry to the `mcpServers` object: ```json { "mcpServers": { "multichat": { "command": "node", "args": [ "C:\\Users\\kurror\\AppData\\Roaming\\Roo-Code\\MCP\\multichat-mcp\\build\\index.js" ], "env": {} } } } ``` ## Usage (Testing) You can test the `multichat-mcp` server using the `use_mcp_tool` command in your Cline environment. **`multichat` tool:** To send messages to multiple unichat servers and save their responses, use the following format: ``` multichat multichat { "messages": [ { "role": "system", "content": "You are a helpful assistant." }, { "role": "user", "content": "What is your opinion about async programming?" } ], "servers": ["Lacayo 1", "openrouter-chat"], "outputDir": "test_output" } ``` * `messages`: An array of messages to send to each server. The format follows the standard unichat message format (array of objects with `role` and `content`). * `servers`: An array of the names of the unichat servers to call (e.g., `"Lacayo 1"`, `"openrouter-chat"`). * `outputDir`: The directory name (within the MCP server's working directory) where the responses will be saved. **Important:** The responses are *not* currently being saved correctly due to the "Method not found" error. **`read_response` tool:** To read a saved response file (once the server is functioning correctly), use: ``` multichat read_response { "outputDir": "test_output", "server": "Lacayo 1" } ``` * `outputDir`: The directory where responses are saved. * `server`: The name of the server whose response you want to read. **Important Notes for Testing:** * Ensure that the `Lacayo 1` and `openrouter-chat` servers are running and correctly configured in `cline_mcp_settings.json`. * After making code changes to `multichat-mcp`, you *must* run `npm run build` in the `multichat-mcp` directory to compile the TypeScript code. * The MCP host (Roo/Cline) automatically restarts servers when the configuration file changes, but it may be necessary to manually restart if you encounter issues. ## Using Perplexity and Unichat * **Perplexity:** You can use the Perplexity MCP server to research and gather information related to MCP, FiveM development, and any other technical topics. This can be helpful for finding documentation, examples, and solutions to problems. * **Unichat Servers:** The `Lacayo 1` and `openrouter-chat` servers provide access to language models through the `unichat` tool. You can use these servers for general coding assistance, debugging, and generating code snippets. You can test them directly using `use_mcp_tool` to ensure they are functioning correctly. ## Updated Usage and Troubleshooting (Corrected) The original documentation and troubleshooting steps described an incorrect approach for cross-server communication. This section provides the corrected usage instructions and addresses the timeout issues we encountered. ### Dependencies - `@modelcontextprotocol/sdk`: Provides the core functionality for building MCP servers and clients. - `zod`: Used for schema validation and type safety. - `fs/promises`, `path`, `url`, `crypto`: Node.js built-in modules for file system operations, path manipulation, URL parsing, and cryptographic functions. ### `multichat` tool (Corrected Usage) The `multichat` tool is designed to send the *same* message to multiple unichat servers and collect their responses. It does *not* facilitate direct server-to-server communication. The correct way to use it is as follows: **Important:** The `multichat` server and the `unichat` servers it communicates with must be running in *separate* terminal windows. 1. **Start the unichat servers:** Open separate terminal windows for each unichat server you want to use (e.g., "Lacayo 1", "openrouter-chat"). In each terminal, navigate to the unichat server directory and run: ```powershell cd C:\Users\kurror\AppData\Roaming\Roo-Code\MCP\unichat-ts-mcp-server $env:UNICHAT_MODEL="gpt-4o" # Or your desired model $env:UNICHAT_API_KEY="your_api_key" # Replace with your actual API key node ./build/index.js ``` 2. **Start the multichat server:** In a *separate* terminal window, navigate to the `multichat-mcp` directory and run: ```powershell cd C:\Users\kurror\AppData\Roaming\Roo-Code\MCP\multichat-mcp node ./build/index.js ``` 3. **Send the request:** In a *third* terminal window, navigate to the `multichat-mcp` directory and create a `request.json` file with the request content. Then, send the request using PowerShell: ```powershell cd C:\Users\kurror\AppData\Roaming\Roo-Code\MCP\multichat-mcp $request = @{ jsonrpc = "2.0" id = 1 method = "tools/call" params = @{ name = "multichat" arguments = @{ messages = @( @{role = "system"; content = "You are a helpful assistant."}, @{role = "user"; content = "Hello, world!"} ) servers = @("Lacayo 1", "openrouter-chat") outputDir = "my-test-output" } } } | ConvertTo-Json -Depth 10 $request | Out-File -FilePath "request.json" -Encoding utf8 Get-Content "request.json" | node ./build/index.js ``` This will create a directory `responses/my-test-output` within the `multichat-mcp` directory, containing the responses from each server (e.g., `Lacayo 1.json`, `openrouter-chat.json`) and a `_session.json` file to track the session. If a server fails to respond, an error file (e.g., `Lacayo 1_error.json`) will be created instead. ### `read_response` tool (Corrected Usage) The `read_response` tool reads a saved response file generated by a previous `multichat` call. **Example Request (within Roo):** ``` multichat read_response { "outputDir": "my-test-output", "server": "Lacayo 1" } ``` **Important:** The `outputDir` is relative to the `multichat-mcp/responses` directory. The tool expects to find a subdirectory within `responses` that matches the `outputDir` value. Inside that subdirectory, it looks for either a `.json` file (for successful responses) or a `_error.json` file (for errors). ### Troubleshooting (Updated) * **Timeouts:** The primary cause of timeouts was the incorrect assumption that `multichat` could directly call other servers. The corrected usage, with all servers running in separate terminals, addresses this. Ensure all unichat servers are running *before* sending the `multichat` request. * **Invalid session directory:** This error occurs when `read_response` cannot find the specified `outputDir` within the `multichat-mcp/responses` directory. Double-check the `outputDir` value and ensure that the `multichat` command was run successfully and created the output directory. * **No response files created:** If no files are created in the `responses` directory, even after following the corrected usage, there might be an issue with file system permissions or a silent error within the `multichat` server's response handling. Check the server logs for any error messages. It's also crucial to verify that the unichat servers you are targeting are running and responding correctly. You can test them individually using `use_mcp_tool` with the `unichat` tool. The errors were: 1. Incorrect usage of `setRequestHandler`: I was passing the method name and schema separately, instead of including the method name within the schema. 2. Incorrect parameter access: `request.params` was not correctly typed due to the schema issue. 3. Incorrect response schema in `client.request`: I was using `z.any()`, which is not compatible with `RequestOptions`. The fixes are: 1. **Define `ForwardRequestSchema` correctly:** Include the `method` field with `z.literal("mcp.forward")`. 2. **Use `setRequestHandler` correctly:** Pass only the schema and the handler function. 3. **Access parameters correctly:** Use `request.params` after parsing with the schema. 4. Use `z.unknown()` in the client.request call.