Multichat MCP Server
Enables integration with FiveM resources, allowing for refactoring and extension of capabilities through communication with external services and APIs
Serves as the runtime environment for the MCP server, enabling cross-server communication management
Provides access to Perplexity for researching MCP documentation, examples, and troubleshooting information
Utilizes TypeScript SDK for implementing MCP server functionality with type safety and schema validation
Implements schema validation for ensuring correct request and response formats in MCP communications
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Multichat MCP Servercompare responses from Lacayo 1 and openrouter-chat about quantum computing basics"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
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:
Verified MCP Server Configurations: We carefully reviewed the
cline_mcp_settings.jsonfile to ensure that all servers (multichat,Lacayo 1, andopenrouter-chat) are correctly configured, with the correct commands, arguments, and environment variables.Checked JSON-RPC Request Formats: We consulted the MCP documentation and examples to ensure that the JSON-RPC requests sent by
multichat-mcpwere correctly formatted, including themethod,params, andidfields.Tested Direct Calls: We confirmed that direct calls to the
unichattools onLacayo 1andopenrouter-chatusinguse_mcp_toolwork as expected. This isolated the issue to the cross-server communication attempts withinmultichat-mcp.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/listandtools/call), and the client-host-server architecture. We learned that direct server-to-server communication is not supported.Modified Server Code (Multiple Iterations): We iteratively modified the
multichat-mcpserver code (src/index.tsandsrc/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
Clientinstances 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_instructionsresponse 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 oftools/call(plural).Attempting to use
rpc.discoverandmcp.tools.listwhich are not standard MCP methods.Trying to use a
tool/routenotification, which is not a standard MCP method.
Correct Approach (Current Implementation):
Creating a single
Clientinstance per target server (Lacayo 1, openrouter-chat) and storing them in aMap.Using the
StdioClientTransportto spawn theunichat-ts-mcp-serveras a subprocess. This is necessary becausemultichat-mcpneeds 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 correcttools/callmethod 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.jsonandnpm 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:
Navigate to the MCP servers directory:
cd C:\\Users\\kurror\\AppData\\Roaming\\Roo-Code\\MCPClone or create the
multichat-mcpdirectory.Place the server files (
package.json,tsconfig.json,src/index.ts,src/server.ts) inside themultichat-mcpdirectory.Install the dependencies:
npm installBuild 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 withroleandcontent).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 1andopenrouter-chatservers are running and correctly configured incline_mcp_settings.json.After making code changes to
multichat-mcp, you must runnpm run buildin themultichat-mcpdirectory 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 1andopenrouter-chatservers provide access to language models through theunichattool. You can use these servers for general coding assistance, debugging, and generating code snippets. You can test them directly usinguse_mcp_toolto 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.
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.jsStart the multichat server: In a separate terminal window, navigate to the
multichat-mcpdirectory and run:cd C:\Users\kurror\AppData\Roaming\Roo-Code\MCP\multichat-mcp node ./build/index.jsSend the request: In a third terminal window, navigate to the
multichat-mcpdirectory and create arequest.jsonfile 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.jsThis will create a directory
responses/my-test-outputwithin themultichat-mcpdirectory, containing the responses from each server (e.g.,Lacayo 1.json,openrouter-chat.json) and a_session.jsonfile 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
multichatcould directly call other servers. The corrected usage, with all servers running in separate terminals, addresses this. Ensure all unichat servers are running before sending themultichatrequest.Invalid session directory: This error occurs when
read_responsecannot find the specifiedoutputDirwithin themultichat-mcp/responsesdirectory. Double-check theoutputDirvalue and ensure that themultichatcommand was run successfully and created the output directory.No response files created: If no files are created in the
responsesdirectory, even after following the corrected usage, there might be an issue with file system permissions or a silent error within themultichatserver'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 usinguse_mcp_toolwith theunichattool.
The errors were:
Incorrect usage of
setRequestHandler: I was passing the method name and schema separately, instead of including the method name within the schema.Incorrect parameter access:
request.paramswas not correctly typed due to the schema issue.Incorrect response schema in
client.request: I was usingz.any(), which is not compatible withRequestOptions.
The fixes are:
Define
ForwardRequestSchemacorrectly: Include themethodfield withz.literal("mcp.forward").Use
setRequestHandlercorrectly: Pass only the schema and the handler function.Access parameters correctly: Use
request.paramsafter parsing with the schema.Use
z.unknown()in the client.request call.
Available Tools
2 toolsmultichatC
Send messages to multiple unichat servers and save responses
| Name | Required | Description | Default |
|---|---|---|---|
| messages | Yes | Messages to send to each server | |
| outputDir | Yes | Directory name for response files | |
| servers | Yes | List of unichat server names to call |
TDQS
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.
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.
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.
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.
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.
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
| Name | Required | Description | Default |
|---|---|---|---|
| outputDir | Yes | Directory name containing the responses | |
| server | Yes | Server name whose response to read |
TDQS
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.
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.
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.
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.
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.
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.
2 tool updates
v1.0.0- First observed
multichat - First observed
read_response
TDQS
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.
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.
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.
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
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
MCP server for building and testing AI agents with multi-model experimentation and insights.
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
Related MCP Servers
- AlicenseNot gradedqualityAmaintenanceA 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,339499Apache 2.0
- AlicenseNot gradedqualityDmaintenanceAn 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
- AlicenseAqualityDmaintenanceA 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.45MIT
- FlicenseNot gradedqualityDmaintenanceA 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
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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