Skip to main content
Glama
kurror

Multichat MCP Server

by kurror

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.

Related MCP server: MCP Server

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:

<use_mcp_tool>
<server_name>multichat</server_name>
<tool_name>multichat</tool_name>
<arguments>
{
  "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"
}
</arguments>
</use_mcp_tool>
  • 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:

<use_mcp_tool>
<server_name>multichat</server_name>
<tool_name>read_response</tool_name>
<arguments>
{
  "outputDir": "test_output",
  "server": "Lacayo 1"
}
</arguments>
</use_mcp_tool>
  • 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):

<use_mcp_tool>
<server_name>multichat</server_name>
<tool_name>read_response</tool_name>
<arguments>
{
  "outputDir": "my-test-output",
  "server": "Lacayo 1"
}
</arguments>
</use_mcp_tool>

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 <server>.json file (for successful responses) or a <server>_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.

Available Tools

2 tools
multichatC

Send messages to multiple unichat servers and save responses

ParametersJSON Schema
NameRequiredDescriptionDefault
messagesYesMessages to send to each server
outputDirYesDirectory name for response files
serversYesList of unichat server names to call

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It mentions sending messages and saving responses, implying a write operation, but doesn't disclose critical behaviors like error handling, authentication needs, rate limits, or whether it's synchronous/asynchronous. For a tool with no annotation coverage, this leaves significant gaps in understanding how it behaves.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and purpose, making it easy to parse quickly. Every word contributes directly to understanding the tool's function.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations, no output schema, and a tool that performs write operations (sending messages and saving files), the description is incomplete. It doesn't cover return values, error cases, or behavioral nuances needed for safe and effective use. For a 3-parameter tool with mutation implications, this level of detail is inadequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all three parameters (messages, outputDir, servers). The description adds minimal value by implying that messages are sent to servers and responses are saved to outputDir, but doesn't provide additional syntax, format details, or constraints beyond what the schema states. Baseline 3 is appropriate when schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Send messages') and target ('multiple unichat servers'), and mentions saving responses. It distinguishes from the sibling 'read_response' by focusing on sending rather than reading. However, it doesn't specify what type of messages or the exact nature of 'unichat servers', keeping it from a perfect score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives, prerequisites, or exclusions. It mentions saving responses but doesn't explain when this is appropriate compared to other communication methods. Without any context on usage scenarios, the agent lacks direction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

read_responseC

Read a saved response file

ParametersJSON Schema
NameRequiredDescriptionDefault
outputDirYesDirectory name containing the responses
serverYesServer name whose response to read

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It states 'Read', implying a read-only operation, but doesn't disclose behavioral traits like error handling, file format expectations, or whether it requires specific permissions. This leaves significant gaps in understanding how the tool behaves beyond basic function.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with zero waste. It's front-loaded and appropriately sized for the tool's apparent simplicity, making it easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description is incomplete. It doesn't explain what a 'saved response file' entails, the return format, or error conditions. For a tool with two required parameters and no structured behavioral hints, this leaves the agent under-informed about critical usage aspects.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents both parameters ('outputDir' and 'server') with descriptions. The description adds no additional meaning beyond implying file reading, which the schema covers. Baseline 3 is appropriate as the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Read') and resource ('a saved response file'), making the purpose understandable. However, it doesn't differentiate from the sibling tool 'multichat', which might handle similar data or operations, leaving room for confusion about when to use each.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like 'multichat'. The description lacks context about prerequisites, such as needing pre-saved files, or exclusions, leaving the agent without usage direction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 2 tool updatesv1.0.0
    • First observedmultichat
    • First observedread_response

TDQS

C2.9/5.0
Disambiguation5/5

The two tools have completely distinct purposes: multichat handles sending messages and saving responses, while read_response focuses on reading saved files. There is no overlap in functionality, making it impossible for an agent to confuse them.

Naming Consistency3/5

The naming is mixed: multichat uses a compound word without underscores, while read_response follows a verb_noun pattern with an underscore. This inconsistency in convention reduces predictability, though both names are still readable and descriptive.

Tool Count2/5

With only 2 tools, the server feels thin for a multichat domain that likely involves managing multiple chat servers. Key operations like listing servers, configuring connections, or handling errors are missing, making the toolset insufficient for robust agent workflows.

Completeness2/5

The toolset is severely incomplete for a multichat server. It lacks essential operations such as adding/removing servers, checking server status, managing configurations, or handling response errors. Agents will face dead ends when trying to perform basic multichat management tasks.

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    A
    maintenance
    A unified Model Context Protocol server that aggregates multiple MCP servers into one, allowing AI assistants like Claude Desktop, Cursor, and Cherry Studio to connect to a single server instead of managing multiple instances.
    1,339
    499
    Apache 2.0
  • A
    license
    Not graded
    quality
    D
    maintenance
    An implementation of the Model Context Protocol (MCP) server that enables multiple clients to connect simultaneously and handles basic context management and messaging with an extendable architecture.
    MIT
  • A
    license
    A
    quality
    D
    maintenance
    A server that enables users to chat with each other by repurposing the Model Context Protocol (MCP), designed for AI tool calls, into a human-to-human communication system.
    4
    5
    MIT
  • F
    license
    Not graded
    quality
    D
    maintenance
    A server that enables WebChat functionality through MCP (Model-Control-Protocol), solving long-term connection issues while providing both common method calls and business API integration capabilities.
    2
    -

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/kurror/mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server