Skip to main content
Glama
khuyentran1401

database-analytics-mcp

by khuyentran1401
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

Database Analytics MCP Server

A practical database analytics MCP server built with FastMCP, providing SQLite database operations through the Model Context Protocol (MCP). Perfect for data analysis workflows with AI assistants like Claude.

What This Server Provides

๐Ÿ› ๏ธ Tools (Interactive Operations)

  • connect_db - Connect to SQLite database files

  • execute_query - Execute SQL queries with safety checks

  • list_tables - List all tables in the database

๐Ÿ“Š Resources (Read-only Data Access)

  • schema://tables/{table_name} - Get table column information and structure

  • data://tables/{table_name} - Get sample table data for preview

๐Ÿ” Safety Features

  • SQL injection prevention with dangerous operation blocking

  • Read-only resource access for safe schema exploration

  • Comprehensive error handling with descriptive messages

Related MCP server: MCP SQLite Server

Setup and Installation

  1. Clone the repository:

    git clone https://github.com/khuyentran1401/database-analytics-mcp.git
cd database-analytics-mcp

  2. Install UV (recommended):

    # Install UV if you haven't already
curl -LsSf https://astral.sh/uv/install.sh | sh

  3. Install dependencies:

    # UV automatically manages dependencies from pyproject.toml
uv sync

  4. Test the server:

    uv run example_usage.py

  5. Add to Claude Code

    # Quick setup
claude mcp add database-analytics -- uv run database_mcp_server.py

    Verify installation:

    # Check if the server is registered
claude mcp list

Other MCP Clients

For any MCP client that supports the standard protocol:

servers:
  - name: database-analytics
    transport:
      type: stdio
      command: uv
      args: ["run", "database_mcp_server.py"]

Example Workflows

Data Exploration with Claude Code

  1. Connect to Database

    Connect to my SQLite database at ./sample_database.db

  2. Explore Schema

    What tables are available in this database?

  3. Examine Table Structure

    Show me the schema for the users table

  4. Preview Data

    Show me some sample data from the users table

  5. Run Analytics Queries

    Calculate total sales by product category

  6. Export Results

    Export the query "SELECT product_name, SUM(quantity) as total_sold FROM orders GROUP BY product_name" to CSV file called sales_report.csv

  7. Get Table Statistics

    Show me statistics for the users table

Common Use Cases

  • Database Schema Discovery: Quickly understand database structure

  • Data Quality Checks: Sample data to verify data integrity

  • Ad-hoc Analysis: Run custom SQL queries safely

  • Report Generation: Execute complex analytical queries

  • Data Exploration: Browse tables and relationships with pagination

  • Data Export: Export query results to CSV for external analysis

  • Performance Monitoring: Track query execution times

Available Tools & Resources

Tools (Interactive Operations)

Tool

Parameters

Description

connect_db

database_path: str

Connect to SQLite database file

execute_query

sql: str

Execute SQL query with safety checks and timing

list_tables

None

List all tables in connected database

export_to_csv

sql: str, filename: str

Export query results to CSV file

Resources (Read-only Access)

Resource URI

Description

schema://tables/{table_name}

Get column info, types, constraints, foreign keys

data://tables/{table_name}

Get sample rows with pagination, statistics (limit, offset)

stats://tables/{table_name}

Get comprehensive table statistics and column analysis

Available Tools

4 tools
connect_dbB

Connect to an SQLite database file.

ParametersJSON Schema
NameRequiredDescriptionDefault
database_pathYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description lacks any disclosure about side effects, error handling, or state changes. It does not say whether connecting creates the database file if it doesn't exist, whether a persistent connection is opened, or if a connection handle is returned. With no annotations to provide safety or side-effect hints, the description leaves critical behavioral unknowns.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, consisting of a single 7-word sentence. It communicates the core purpose without any unnecessary words or filler. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple input schema and the presence of an output schema (not shown), the description is still incomplete. It omits prerequisites, return values, and side-effect information. For a tool that establishes a connection, an agent would need to know whether to call this before queries, what to do with the result, and how to handle existing vs. non-existing database files. The lack of behavioral and usage context makes it insufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter, database_path, is not explained beyond its name. The schema has zero description coverage (0%), and the description merely mentions an 'SQLite database file' without linking it to the parameter format, constraints, or behavior (e.g., relative vs. absolute path). It fails to compensate for the lack of schema documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Connect to an SQLite database file.' It uses a specific verb (connect) and resource (SQLite database file), distinguishing it from sibling tools like execute_query, list_tables, and export_to_csv, which are about querying and exporting. No ambiguity about the core purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided about when to use this tool versus alternatives. The description does not mention that establishing a connection is a prerequisite for execute_query or list_tables, nor does it explain the connection lifecycle. There is no explicit or implicit contextual advice for usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

execute_queryC

Execute a SQL query on the connected database.

ParametersJSON Schema
NameRequiredDescriptionDefault
sqlYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden, but it only states the action without disclosing potential side effects like data mutation, permission requirements, or error behavior. For a SQL execution tool, this is a significant transparency gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence with no redundant information. It is appropriately front-loaded, though brevity comes at the expense of critical context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having an output schema, the description lacks essential usage context: no safety warnings, no connection prerequisites, no parameter guidance, and no mention of side effects. For a tool executing arbitrary SQL, this is incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter 'sql' has no schema description, and the tool description adds no detail about SQL dialect, query format, or examples. With 0% schema coverage, the description fails to compensate, leaving parameter semantics largely undefined.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it executes a SQL query on the connected database, using a specific verb and resource. It distinguishes itself from sibling tools like connect_db, list_tables, and export_to_csv without confusion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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, nor any prerequisites such as ensuring a database connection is active. It does not mention whether it is appropriate for read-only vs. write operations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

export_to_csvB

Execute a SQL query and export results to CSV file

ParametersJSON Schema
NameRequiredDescriptionDefault
sqlYes
filenameYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3.3/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic action and does not mention potential side effects like file overwriting, permissions, or dependencies on an existing database connection.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that directly states the tool's purpose without any superfluous words. It is optimally concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool, the description is minimal but lacks important context such as file overwrite behavior, whether a database connection is required, and what the output schema entails. The presence of an output schema reduces some burden, but the description still does not adequately guide the agent on prerequisites or side effects.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description must compensate, but it only indirectly references the parameters ('SQL query' and 'CSV file') without adding meaningful detail about the expected format, constraints, or relationship between sql and filename. The parameter names are already suggestive, so the description adds minimal value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool executes a SQL query and exports the results to a CSV file. This specific verb+resource distinguishes it from siblings like execute_query, which presumably returns results but does not export to a file.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for exporting query results to CSV, but it does not explicitly mention when to use this tool versus alternatives such as execute_query. No exclusions or alternative references are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_tablesA

List all tables in the connected database.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It adds the context that the tool operates on the 'connected database', which hints at a prerequisite state, but it does not explicitly state that it is read-only, how errors are handled, or what happens if no connection exists. This is minimal but acceptable for a simple listing operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no unnecessary words. It delivers the essential purpose clearly and directly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple, has no parameters, and an output schema exists, so the description does not need to explain return values. The description captures the core function, but could optionally mention that it requires a prior connect_db call for full completeness. Still, it is sufficient for its simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters, and the baseline for 0 params is 4. The description adds no parameter-specific details because there are none, and no additional context is needed beyond what the schema already indicates.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'List all tables in the connected database' with a specific verb (List), a resource (tables), and a context (connected database). This distinguishes it from sibling tools like execute_query and connect_db by focusing specifically on enumerating tables.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage after establishing a database connection (via 'connected database'), but it does not explicitly state when to use this tool versus alternatives like execute_query. There are no exclusions or alternative recommendations, so the usage guidance is implied rather than explicit.

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.

  1. 4 tool updatesv0.1.0
    • First observedconnect_db
    • First observedexecute_query
    • First observedexport_to_csv
    • First observedlist_tables
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0
Disambiguation5/5

Each tool has a clearly distinct role: connecting, executing queries, listing tables, and exporting results. Even though export_to_csv involves executing a query, its output destination (file) differentiates it from execute_query.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (connect_db, execute_query, list_tables, export_to_csv), making the set predictable and easy to understand.

Tool Count5/5

Four tools is well-scoped for a focused SQLite analytics server, covering the essential operations without unnecessary bloat.

Completeness4/5

The set covers connection, querying, table listing, and export, which are core for analytics. A minor gap is lack of explicit schema inspection, but agents can work around this via SQL queries (e.g., PRAGMA table_info).

Maintenance

ActivityInactive
ResponsivenessNo issues

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

Related MCP Servers

  • MCP SQLite Server

    jparkerweb
    A
    license
    Not graded
    quality
    C
    maintenance
    Provides comprehensive SQLite database interaction through MCP, enabling CRUD operations, custom SQL queries, and database exploration.
    545
    127
    MIT

  • MCP SQLite Server

    moaaz01
    F
    license
    Not graded
    quality
    D
    maintenance
    Query, explore, and manage SQLite databases through the Model Context Protocol. Connect any MCP-compatible AI client to your databases.
    -

  • DataBook

    Ethan2298
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables AI assistants to manage and query SQLite databases through MCP tools, supporting CRUD operations, schema management, and saved views.
    3
    MIT

  • mcp-sqlite

    nhevers
    F
    license
    Not graded
    quality
    D
    maintenance
    MCP server that provides SQLite database operations. Allows AI assistants to query, modify and manage SQLite databases through the Model Context Protocol.
    -

Latest Blog Posts

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/khuyentran1401/database-analytics-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server