ashbansal03/analytics-mcp

1. This repository is a small deployment package for an “Analytics-MCP” service, not a large multi-module application. The core runtime appears to be a single Python entrypoint, server.py, supported by environment configuration and a systemd service file for VPS deployment.

2. The main application boundary is the Python process in server.py. Based on the README, its purpose is to provide an Analytics MCP layer over a PostgreSQL database. In an architecture diagram, this is the central service node that sits between client/tooling on one side and PostgreSQL on the other.

3. The data backend is PostgreSQL. The README explicitly says the repo is for “Analytics MCP for PostgreSQL DB on VPS,” so the service is likely responsible for reading analytics data from that database and exposing it through the MCP interface. PostgreSQL should be shown as an external datastore, separate from the application runtime.

4. Configuration is externalized into an environment file. The checked-in a.env is intended to be renamed to .env on Linux web servers, which means the service likely reads runtime settings from environment variables rather than hardcoded values. This is an important boundary for secrets such as DB credentials, hostnames, or ports.

5. analytics-mcp.service indicates the app is managed by systemd on Linux. That means the deployment architecture includes the host OS as an operational layer, with systemd responsible for starting, stopping, and restarting the Python service. This file is part of the runtime lifecycle, not the business logic.

6. uk_cafe_sales.csv is a bundled data file, likely a sample dataset or local analytics input used during development/testing. It should be treated as a data artifact rather than a core service dependency unless server.py explicitly loads it. In a diagram, place it as optional local test data or example input.

7. The repository is therefore organized around three practical layers: service code (server.py), configuration (a.env / .env), and deployment control (analytics-mcp.service). The external data boundary is PostgreSQL, and the local CSV is an auxiliary data asset.

8. The most important flow is: systemd launches the Python process using environment configuration; the Python service connects to PostgreSQL; the service then acts as the analytics/MCP interface for upstream consumers. If the CSV is used, it would be a secondary input path into the same Python service.

9. There are no signs here of a frontend, message queue, ORM layer, or multi-service backend. So the architecture should be drawn as a compact server-side integration service with one main executable, one external database, and one deployment unit.

10. For a diagram, the key nodes are: Linux VPS / systemd, server.py service, .env configuration, PostgreSQL database, and optional CSV data file. The main trust and dependency boundary is between the Python service and PostgreSQL, with systemd handling process supervision.