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:

   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:

   npm install

5. Build the TypeScript code:

   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:

{
  "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:

   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:

   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:

   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.