Unified AI Backend Service (TypeScript MCP)

Companion implementation available in Python

Interface with OpenAI, MistralAI, Anthropic, xAI, Google AI, or DeepSeek through the standardized MCP framework, utilizing either direct tool invocation or specialized prompt templates. Authorization credentials for the respective vendors are mandatory.

Supports both synchronous standard input/output (STDIO) and Server-Sent Events (SSE) transmission modes configurable via command-line parameters.

Exposed Tools

The service exposes a primary operational tool: - unichat: Executes a query against the configured AI backend. - Input parameter: messages (string, mandatory payload) - Output: The AI system's response.

Predefined Function Calls (Prompts)

• code_review
• Purpose: Critically assess source code for adherence to best practices, identifying potential flaws and suggesting refinements.
• Arguments:
  • code (string, required): The textual representation of the program segment to be scrutinized
• document_code
• Purpose: Automatically generate comprehensive explanatory text, including docstrings and inline annotations.
• Arguments:
  • code (string, required): The source code requiring documentation enrichment
• explain_code
• Purpose: Provide an in-depth analysis of the operational logic within a given code snippet.
• Arguments:
  • code (string, required): The code block for functional elucidation
• code_rework
• Purpose: Modify existing source code based on specified modification instructions.
• Arguments:
  • changes (string, optional): A description of the required alterations
  • code (string, required): The codebase subject to modification

Building and Development Flow

Dependency resolution: bash npm install

Compiling the source artifacts: bash npm run build

For continuous integration during active development (enabling automatic recompilation): bash npm run watch

Evaluation Execution

The integrated evaluation suite employs an MCP client to execute against the compiled index.ts. Recompilation is unnecessary between test runs. Environment variables should be prefixed when invoking the evaluation runner. Comprehensive documentation for the evaluation framework is accessible via this link.

bash OPENAI_API_KEY=your-key npx mcp-eval src/evals/evals.ts src/server.ts

Deployment Methods

Installation via Smithery Integration

To deploy Unichat MCP Server automatically for use with Claude Desktop via Smithery:

bash npx -y @smithery/cli install unichat-ts-mcp-server --client claude

Manual Configuration

For local integration with Claude Desktop, modify the configuration file located at: On MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json On Windows: %APPDATA%/Claude/claude_desktop_config.json

Configuration for executing locally:

{ "mcpServers": { "unichat-ts-mcp-server": { "command": "node", "args": [ "{{/path/to}}/unichat-ts-mcp-server/build/index.js" ], "env": { "UNICHAT_MODEL": "YOUR_PREFERRED_MODEL_NAME", "UNICHAT_API_KEY": "YOUR_VENDOR_API_KEY" } } } }

Configuration for executing the published package version:

{ "mcpServers": { "unichat-ts-mcp-server": { "command": "npx", "args": [ "-y", "unichat-ts-mcp-server" ], "env": { "UNICHAT_MODEL": "YOUR_PREFERRED_MODEL_NAME", "UNICHAT_API_KEY": "YOUR_VENDOR_API_KEY" } } } }

The service defaults to STDIO communication; use the --stdio flag explicitly or specify --sse for event streaming. bash npx -y unichat-ts-mcp-server --sse

Supported Model Identifiers:

Refer to this source file for the comprehensive registry of acceptable values for the parameter specified as "YOUR_PREFERRED_MODEL_NAME". Ensure the corresponding API credential ("YOUR_VENDOR_API_KEY") is supplied in the environment variables.

Configuration Example:

"env": { "UNICHAT_MODEL": "gpt-4o-mini", "UNICHAT_API_KEY": "YOUR_OPENAI_API_KEY" }

Troubleshooting Communication Issues

Debugging interactions transmitted over stdio channels presents inherent difficulties. We strongly advocate for utilizing the MCP Inspector, accessible via a dedicated script in the package:

bash npm run inspector

The Inspector utility will furnish a local URL allowing access to diagnostic interfaces within a web browser.

For testing scenarios utilizing SSE where timeouts are encountered, adjust the inspector interface's request URL to incorporate an extended timeout duration, like so: http://localhost:3001/sse?timeout=600000

Historical Context on XMLHttpRequest (XHR)

XMLHttpRequest (XHR) defines an Application Programming Interface (API) realized as a JavaScript construct designed to facilitate the transmission of HTTP requests from a client-side web environment to a remote server. Its methods empower browser-based applications to initiate server communications subsequent to page load completion and receive resultant data asynchronously. XHR constitutes a foundational element of Ajax programming paradigms. Preceding Ajax, the primary interaction methods with a server relied heavily on traditional hyperlinks and form submissions, frequently necessitating a full page refresh to render new content.

== Genesis == The foundational concept underpinning XMLHttpRequest was formulated around the year 2000 by the engineering team behind Microsoft Outlook. This concept was subsequently integrated into the Internet Explorer 5 browser release (1999). However, the initial implementation did not utilize the standardized XMLHttpRequest naming convention; instead, developers employed object instantiations such as ActiveXObject("Msxml2.XMLHTTP") and ActiveXObject("Microsoft.XMLHTTP"). By the time Internet Explorer 7 shipped (2006), universal support for the canonical XMLHttpRequest identifier was established across browsers. The XMLHttpRequest identifier has since become the prevailing convention across all major browser engines, including Mozilla's Gecko (adopted in 2002), Safari 1.2 (2004), and Opera 8.0 (2005).

=== Standardization Trajectory === The World Wide Web Consortium (W3C) published the initial Working Draft specification for the XMLHttpRequest object on April 5, 2006. A subsequent Level 2 specification was released by the W3C on February 25, 2008. Level 2 introduced enhancements enabling event progress monitoring, facilitating cross-site request initiation, and managing byte stream transfers. By the conclusion of 2011, the Level 2 features were merged back into the primary specification document. Subsequently, in late 2012, stewardship of the standard transitioned to the WHATWG, which now maintains an actively evolving specification document utilizing Web IDL notation.

== Operational Mechanics == Executing a transmission utilizing XMLHttpRequest generally entails a sequence of distinct programming phases:

1. Instantiation: Create an instance of the XMLHttpRequest object via constructor invocation.
2. Configuration: Invoke the "open" method to specify the request modality (e.g., GET/POST), designate the target Uniform Resource Identifier (URI), and select between synchronous or asynchronous execution mode.
3. Listener Registration: For asynchronous operations, define a callback function (listener) to be triggered upon changes in the request's state.
4. Initiation: Commence the communication sequence by calling the "send" method, optionally passing data to be transmitted to the server.
5. State Handling: Monitor state transitions within the registered event listener. Upon successful server data reception, the payload is typically accessible via the "responseText" attribute. When processing concludes, the object transitions to state 4, signifying completion ("done"). Beyond these fundamental steps, XMLHttpRequest offers numerous controls for refining request transmission and response handling. Custom HTTP headers can be injected to instruct the server on fulfillment protocols. Data can be uploaded by supplying it as an argument to the "send" call. Responses can be parsed directly from structured data formats like JSON into native JavaScript objects, or processed incrementally as data segments arrive instead of waiting for total message receipt. Furthermore, the request can be terminated preemptively or configured with a strict time limit to enforce failure if not resolved promptly.

== Inter-Domain Communication Restrictions ==

During the nascent stages of the World Wide Web's evolution, it was observed that enabling unrestricted access to resources across different domains could introduce significant security vulnerabilities, leading to the development of restrictions.