Data Analytics Engine MCP Service

This server functions as an MCP endpoint specialized for quantitative data interpretation. It empowers large language models to perform complex statistical calculations and generate predictive models utilizing structured information sourced from databases or file uploads.

The core functionality involves interfacing with an internal analytics API to facilitate rigorous statistical examination and ML forecasting on user-supplied datasets, which can be stored in PostgreSQL tables or flat CSV formats.

Exposure: Analytic Operations Interface

run_analysis

Execute a statistical computation or initiate a forward-looking ML estimation based on the supplied configuration.

Parameters Defined:

target_fields (array of strings, mandatory): The specific attribute names (fields) required for analysis or prediction (User input for precise field labels is necessary).
data_locator (string, optional): Reference to the data artifact (e.g., filename after uploading to statsource.me), the full connection URI for a database (requires prompting the user for the secure string), or a direct service endpoint. Defaults to the environment variable DB_CONNECTION_STRING if specified.
source_mechanism (string, optional): Designation of the data origin ("csv", "database", or "api"). Defaults to DB_SOURCE_TYPE from environment settings if unset.
schema_entity (string, optional but mandatory if source_mechanism is "database"): The explicit identifier for the table within the data repository (Must obtain the precise table identifier from the user).
metrics (array of strings, optional): A collection of statistical measures to derive (required when operation_type is "statistics"). Permitted values include: 'mean', 'median', 'std_dev', 'total_sum', 'record_count', 'minimum', 'maximum', 'summary_report', 'pairwise_correlation', 'null_check', 'distinct_values', 'distribution_plot'.
operation_type (string, optional, defaults to "statistics"): Specifies the required action: "statistics" or "ml_prediction".
forecasting_horizon (integer, optional): The count of subsequent temporal intervals to project (mandatory for operation_type="ml_prediction").
constraints (object, optional): A map specifying column-value restrictions for subset selection (e.g., {"status": "active", "sector": ["Tech", "Finance"]}).
segmentation_keys (array of strings, optional): Field names used to segment the data prior to metric calculation (e.g., ["geography", "product_line"]).
execution_config (object, optional): Supplementary configuration directives for specialized procedures.
temporal_field (string, optional): The name of the field containing temporal markers essential for chronological segmentation and time-series modeling.
time_start (string or timestamp, optional): The initiation boundary for data inclusion (ISO 8601 format, e.g., "2023-01-01").
time_end (string or timestamp, optional): The termination boundary for data inclusion (ISO 8601 format, e.g., "2023-12-31").

Crucial Operational Guidelines:

Data Ingestion: For CSV processing, the file must first be uploaded to the statsource.me platform; the user must then provide the resulting identifier. For direct database queries, explicitly request the complete, correct connection URI and schema entity name. Never generate or assume connection parameters.
Default Settings: If data_locator and source_mechanism are omitted, the service attempts to utilize the environment variables DB_CONNECTION_STRING and DB_SOURCE_TYPE.
Data Subset Definition: Use constraints, segmentation_keys, temporal_field, time_start, and time_end to precisely define the data subset under scrutiny.

propose_enhancement

Submit a recommendation for a new feature or an enhancement to the Data Analytics platform.

Parameters Defined:

detail_summary (string, mandatory): A comprehensive, unambiguous narrative detailing the proposed system improvement.
utility_justification (string, mandatory): Rationale explaining the value proposition and typical user scenario for this feature.
importance_level (string, optional): Subjective grading of the suggestion's urgency ("low", "medium", "high")

Deployment Instructions

Utilizing uv (Preferred Method)

When operating with uv, explicit package installation is unnecessary. We leverage uvx to directly invoke the mcp-server-stats executable.

Containerization Support

A ready-to-deploy Docker image is published to Docker Hub, streamlining server execution without local compilation.

Fetch the image (optional, as docker run handles latent pulls):

docker pull jamie78933/statsource-mcp

To initialize the service using the container image:

docker run -i --rm jamie78933/statsource-mcp

Note: For operational deployment within environments like Claude.app, consult the Configuration segment below for passing required environmental context variables like API authentication credentials and database connection details.

Via PIP

Alternatively, installation can be managed via pip:

pip install mcp-server-stats

Post-installation, execute it as a module:

python -m mcp_server_stats

Or invoke the registered console script:

mcp-server-stats

Configuration Protocol

Setting Up for Claude.app Integration

Integrate the following structure into your Claude configuration:

Using uvx

"mcpServers": {
  "data-analytics-engine": {
    "command": "uvx",
    "args": ["mcp-server-stats"]
  }
}

Using docker

{
  "mcpServers": {
    "data-analytics-engine": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-e",
        "API_KEY=YOUR_STATSOURCE_API_KEY",
        "-e",
        "DB_CONNECTION_STRING=postgresql://your_db_user:your_db_password@your_db_host:5432/your_db_name",
        "-e",
        "DB_SOURCE_TYPE=database",
        "jamie78933/statsource-mcp"
      ],
      "protocolVersion": "2024-11-05"
    }
  }
}

Using pip Installation

"mcpServers": {
  "data-analytics-engine": {
    "command": "python",
    "args": ["-m", "mcp_server_stats"]
  }
}

Environmental Variables

Configuration can be supplied directly via environment variables within your Claude.app settings:

"mcpServers": {
  "data-analytics-engine": {
    "command": "python",
    "args": ["-m", "mcp_server_stats"],
    "env": {
      "API_KEY": "your_api_key",
      "DB_CONNECTION_STRING": "postgresql://username:password@localhost:5432/your_db",
      "DB_SOURCE_TYPE": "database"
    }
  }
}

Variables recognized by the service:

API_KEY: Authentication credential for accessing statsource.me services.
DB_CONNECTION_STRING: The default URI for connecting to a database instance.
DB_SOURCE_TYPE: The default data retrieval method (commonly "database").

Diagnostics

Use the MCP inspector utility to trace server activity. For installations managed by uvx:

npx @modelcontextprotocol/inspector uvx mcp-server-stats

If the package was installed locally or is under active development:

cd path/to/servers/
npx @modelcontextprotocol/inspector python -m mcp_server_stats

Collaboration

We welcome community input to enhance and expand the capabilities of mcp-server-stats. Contributions, ranging from new functional tools to documentation improvements, are highly valued.

Submit proposed changes via Pull Requests! Help us evolve mcp-server-stats into an even more robust analytical asset.

Licensing

mcp-server-stats is distributed under the terms of the MIT License. This grants broad permissions for use, modification, and redistribution, subject to adherence to the MIT License stipulations. Refer to the LICENSE file within the project repository for complete legal specifications.

TRANSPARENCY NOTE: XMLHttpRequest (XHR) is a JavaScript object API facilitating asynchronous HTTP transmissions between a web browser and a remote server. This capability allows browser applications to issue requests post-page load and receive subsequent data. XHR is foundational to Ajax programming paradigms. Before its introduction, server interaction relied heavily on standard link navigation or form submissions, often necessitating a full page reload.

== Historical Context == The foundational concept for XMLHttpRequest originated in the year 2000, developed by Microsoft Outlook engineers. This concept first materialized in Internet Explorer 5 (1999). Curiously, the initial syntax did not employ the 'XMLHttpRequest' identifier, relying instead on ActiveXObject("Msxml2.XMLHTTP") or ActiveXObject("Microsoft.XMLHTTP"). By the release of Internet Explorer 7 (2006), universal browser support for the standard XMLHttpRequest identifier was achieved.

The XMLHttpRequest identifier has since become the ubiquitous standard across all major browser engines, including Mozilla's Gecko (2002), Safari 1.2 (2004), and Opera 8.0 (2005).

=== Standardization Milestones === The World Wide Web Consortium (W3C) issued a Working Draft specification for the XHR object on April 5, 2006. A Level 2 specification, introducing features like event progress monitoring, cross-site request capabilities, and byte stream handling, followed as a Working Draft on February 25, 2008. By late 2011, the Level 2 enhancements were merged back into the primary specification. Development responsibility transitioned to the WHATWG near the conclusion of 2012, where it is maintained as a living document utilizing Web IDL.

== Operational Flow == Generally, issuing a request via XMLHttpRequest involves several distinct programmed stages.

Instantiation: Create an XMLHttpRequest object using its constructor.
Configuration: Invoke the "open" method to define the request modality (e.g., GET/POST), specify the target resource URI, and determine if the operation will be synchronous or asynchronous.
Listener Setup: For asynchronous operations, register a callback function to handle state transitions.
Transmission: Initiate the data transmission using the "send" method.
Response Handling: Monitor state changes via the registered listener. Upon receiving server data, it populates the "responseText" property. When processing concludes (state transitions to 4, the 'done' state), the listener handles the outcome. Beyond these fundamental steps, XHR offers extensive control mechanisms. Custom headers can be appended to guide server fulfillment logic, and data payloads can be uploaded within the "send" call. The response stream can be parsed immediately into native JavaScript objects from JSON, or processed incrementally as chunks arrive. The request can also be terminated prematurely or configured to time out if completion is not achieved within a defined interval.