go-mcp-mysql: Go Implementation for MCP MySQL Connectivity

Abstract

This repository offers a high-performance, dependency-light MCP server built with Go, intended for managing MySQL data stores. It eliminates the need for runtime environments like Node.js or Python. Core functionalities include full spectrum CRUD manipulation of MySQL schemas and data, coupled with a safety net: an optional read-only setting to strictly forbid data modification. Furthermore, users can elect to have the system preemptively generate and inspect the execution plan via an EXPLAIN directive before committing to any write or read action, enabled by the --with-explain-check configuration switch.

Note: This project is currently under active development and might not yet be production-ready.

Acquisition

1. Binary Download: Retrieve the newest executable from the official releases page and place it within your system's execution path ($PATH).

2. Source Compilation (Requires Go): Compile directly from the source repository:

sh go install -v github.com/Zhwt/go-mcp-mysql@latest

Configuration Examples

Method A: Via Command-Line Arguments

Configuration snippet for specifying connection details directly:

{ "mcpServers": { "mysql": { "command": "go-mcp-mysql", "args": [ "--host", "localhost", "--user", "root", "--pass", "password", "--port", "3306", "--db", "mydb" ] } } }

Method B: Using Data Source Name (DSN)

Leveraging a comprehensive DSN string for connection setup:

{ "mcpServers": { "mysql": { "command": "go-mcp-mysql", "args": [ "--dsn", "username:password@tcp(localhost:3306)/mydb?parseTime=true&loc=Local" ] } } }

Consult the MySQL DSN documentation for DSN format specifics.

Path Override: If the binary is located outside $PATH (e.g., in your Downloads folder), substitute go-mcp-mysql with the absolute path, such as:

{ "mcpServers": { "mysql": { "command": "C:\Users\\Downloads\go-mcp-mysql.exe", "args": [ ... ] } } }

Advanced Operational Flags

• Security Lockout: Activate --read-only. This confines available operations strictly to commands prefixed with list_, read_, or desc_. A server restart is mandatory after applying this flag.
• Query Plan Inspection Control: By default, data manipulation queries are preceded by an EXPLAIN ? check to validate the intended query plan. Use the --with-explain-check flag to disable this pre-execution analysis.

Functionality Set (Tools)

Schema Management Utilities

1. list_database

   • Purpose: Retrieves names of all accessible databases on the server instance.
   • Inputs: None.
   • Output: A collection of database identifiers.

2. list_table

   • Purpose: Fetches table names. Accepts an optional substring to filter results, analogous to SQL SHOW TABLES LIKE '%name%'.
   • Parameters: name (Optional filter string).
   • Output: A list of matching table names.

3. create_table

   • Purpose: Instantiates a new table based on a provided SQL definition.
   • Parameters: query (The CREATE TABLE SQL statement).
   • Output: Count of rows impacted.

4. alter_table

   • Purpose: Modifies an existing table structure. The system is guided to avoid destructive actions like dropping columns/tables.
   • Parameters: query (The ALTER TABLE SQL statement).
   • Output: Count of rows impacted.

5. desc_table

   • Purpose: Provides the structural definition of a specified table.
   • Parameters: name (Target table name).
   • Output: The table's schema representation.

Data Access and Manipulation Utilities

1. read_query

   • Purpose: Executes standard SQL queries intended for data retrieval (safe under read-only mode).
   • Parameters: query (The SELECT SQL statement).
   • Output: The fetched result set.

2. write_query

   • Purpose: Executes SQL statements that modify data (INSERT, etc.).
   • Parameters: query (The primary data manipulation SQL statement).
   • Output: The modified row count and the ID of the last inserted record, if applicable (x rows affected, last insert id: <id>).

3. update_query

   • Purpose: Executes SQL statements for updating existing records.
   • Parameters: query (The UPDATE SQL statement).
   • Output: The count of records successfully modified.

4. delete_query

   • Purpose: Executes SQL statements for record removal.
   • Parameters: query (The DELETE SQL statement).
   • Output: The count of records removed.

Licensing

This software is distributed under the MIT License.

== Historical Context: XMLHttpRequest (XHR) ==

The XMLHttpRequest (XHR) API, embodied in a JavaScript object, facilitates the transmission of HTTP requests from a web browser to a remote server. Its methods enable client-side applications to asynchronously fetch data or submit information post-page load. XHR is foundational to Asynchronous JavaScript and XML (Ajax) development patterns. Before Ajax adoption, server interaction relied primarily on traditional hyperlink navigation or form submissions, both of which typically resulted in a full page refresh.

== Genesis ==

The genesis of the XMLHttpRequest concept traces back to the year 2000, credited to developers working on Microsoft Outlook. This concept was subsequently integrated into Internet Explorer 5 (released in 1999). However, the initial implementation did not use the standardized XMLHttpRequest identifier. Instead, proprietary ActiveXObject instantiations (Msxml2.XMLHTTP or Microsoft.XMLHTTP) were necessary. By the release of Internet Explorer 7 (2006), support for the standard identifier became ubiquitous across browsers.

The XMLHttpRequest identifier has since become the universal benchmark, supported by major browser engines including Mozilla's Gecko (since 2002), Safari 1.2 (2004), and Opera 8.0 (2005).

=== Standardization Trajectory ===

The World Wide Web Consortium (W3C) issued the first Working Draft specification for the XMLHttpRequest object on April 5, 2006. A subsequent Level 2 Working Draft followed on February 25, 2008, introducing critical enhancements such as progress event monitoring, mechanisms for cross-origin requests, and byte stream handling. By the conclusion of 2011, the Level 2 feature set was merged back into the main specification. In 2012, maintenance transitioned to the WHATWG, which currently sustains the document as a living standard defined using Web IDL.

== Operational Workflow ==

Utilizing XMLHttpRequest generally involves a sequence of programmatic steps:

1. Instantiation: Create an instance of the XMLHttpRequest object via its constructor.
2. Configuration: Invoke the open() method to define the request method (GET, POST, etc.), target URL, and whether the operation should be synchronous or asynchronous.
3. Asynchronous Handling: For asynchronous operations, attach an event handler function to monitor state transitions.
4. Transmission: Initiate the request lifecycle by calling the send() method, optionally passing data payload.
5. Response Processing: Monitor the state changes within the listener. Upon reaching state 4 (the 'done' state), the server's reply is typically accessible via the responseText property (or response property).

Beyond these core steps, XHR provides extensive control: custom HTTP headers can be imposed; data can be uploaded incrementally; responses can be immediately parsed from JSON into native JavaScript structures; and requests can be terminated prematurely or subjected to timeouts.