Skip to main content
Glama
llm-guy

Data File Analysis MCP Server

by llm-guy
OverviewSchemaRelated ServersScoreDiscussions
Python

Basic MCP Server for Data File Analysis

A Model Context Protocol (MCP) server that provides tools for analyzing CSV and Parquet files.

Features

  • CSV File Analysis: Summarize CSV files by reporting row and column counts

  • Parquet File Analysis: Summarize Parquet files by reporting row and column counts

  • Sample Data: Includes sample user data in both CSV and Parquet formats

Related MCP server: MCP File Analyzer

Project Structure

mix_server/
│
├── data/                 # Sample CSV and Parquet files
│   ├── sample.csv
│   └── sample.parquet
│
├── tools/                # MCP tool definitions
│   ├── __init__.py
│   ├── csv_tools.py
│   └── parquet_tools.py
│
├── utils/                # Reusable file reading logic
│   ├── __init__.py
│   └── file_reader.py
│
├── server.py             # MCP server instance
├── main.py              # Entry point for the MCP server
├── generate_parquet.py  # Script to convert CSV to Parquet
└── README.md            # This file

Installation

  1. Install uv (if not already installed):

    curl -LsSf https://astral.sh/uv/install.sh | sh

  2. Create and activate virtual environment:

    uv venv
source .venv/bin/activate

  3. Install dependencies:

    uv add "mcp[cli]" pandas pyarrow

Usage

Running the Server

Start the MCP server:

uv run main.py

Using with LM Studio

To use this MCP server with LM Studio, edit your mcp.json file and add:

This starts the MCP server for you.

{
  "mcpServers": {
    "mix_server": {
      "command": "uv",
      "args": [
        "--directory",
        "/path/to/your/mcp_server_public",
        "run",
        "main.py"
      ]
    }
  }
}

Note: Replace /path/to/your/mcp_server_public with the actual path to your mcp_server_public directory.

Once loaded you should see all available tools for your local LLM to use.

Available Tools

  1. summarize_csv_file(filename: str)

    • Summarizes a CSV file by reporting its number of rows and columns

    • Example: summarize_csv_file("sample.csv")

  2. summarize_parquet_file(filename: str)

    • Summarizes a Parquet file by reporting its number of rows and columns

    • Example: summarize_parquet_file("sample.parquet")

Sample Data

The server includes sample user data with the following structure:

  • id: Unique identifier

  • name: User's full name

  • email: User's email address

  • signup_date: Date when the user signed up

Development

Adding New Tools

  1. Create a new file in the tools/ directory

  2. Import the MCP server instance: from server import mcp

  3. Define your tool function with the @mcp.tool() decorator

  4. Import the new tool module in main.py

Adding New File Formats

  1. Add utility functions in utils/file_reader.py

  2. Create corresponding tools in the tools/ directory

  3. Import the new tools in main.py

Dependencies

  • mcp[cli]: Official MCP SDK and command-line tools

  • pandas: For reading CSV and Parquet files

  • pyarrow: Adds support for reading Parquet files via Pandas

License

This project is open source and available under the MIT License.

Available Tools

2 tools
summarize_csv_fileA

Summarize a CSV file by reporting its number of rows and columns. Args: filename: Name of the CSV file in the /data directory (e.g., 'sample.csv') Returns: A string describing the file's dimensions.

ParametersJSON Schema
NameRequiredDescriptionDefault
filenameYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/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 burden. It describes the operation (reporting rows and columns) which is a read-only analysis, but doesn't explicitly state it's non-destructive or disclose edge cases like malformed CSVs, empty files, or large files. The return value is described as 'a string describing the file's dimensions,' which is helpful, but behavioral detail is thin.

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?

Extremely concise: a single summary sentence plus minimal Args/Returns documentation. Every sentence earns its place, with zero waste or fluff.

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?

This is a simple single-param read-only tool with an output schema. The description explains purpose, parameter format, and return type. For the tool's low complexity, it is reasonably complete. Minor gaps: no handling of error cases or explicit confirmation of non-destructive read behavior, but these are minor for a summary tool.

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?

Schema coverage is 0%, so the description must compensate for the single parameter. It does: 'filename: Name of the CSV file in the /data directory (e.g., 'sample.csv')' adds the directory constraint and a concrete example format, which goes beyond the bare schema field. Baseline for 1 param with 0% coverage would be 4, and this delivers exactly that.

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

Purpose4/5

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

Description states a specific verb+resource: 'Summarize a CSV file by reporting its number of rows and columns.' It clearly distinguishes from sibling summarize_parquet_file (CSV vs parquet). Could be improved but purpose is clear.

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?

It states the file must be in the /data directory, providing some context, and the tool is clearly for CSV vs parquet. However, it doesn't explicitly note when to use this vs summarize_parquet_file or any exclusions, relying on the format in the name.

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

summarize_parquet_fileB

Summarize a Parquet file by reporting its number of rows and columns. Args: filename: Name of the Parquet file in the /data directory (e.g., 'sample.parquet') Returns: A string describing the file's dimensions.

ParametersJSON Schema
NameRequiredDescriptionDefault
filenameYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.2/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. The description mentions the return value (a string describing dimensions) but does not disclose the actual output format, whether it reads the entire file into memory, error behavior for missing files, or whether it handles nested/partitioned Parquet files. For a read-only tool, the absence of annotations and lack of behavioral detail is a 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 compact and uses the Args/Returns structure for clarity. It's front-loaded with the core purpose in the first sentence. Every sentence earns its place, though the Args/Returns formatting is slightly verbose for a single-parameter tool.

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

Completeness3/5

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

For a simple 1-parameter, read-only tool with an output schema present, the description is reasonably complete. It states inputs and return type. However, the return format is vague ('a string describing the file's dimensions') and the /data directory constraint could use more precision (absolute vs relative paths, access permissions). Given the low complexity, this is adequate but not thorough.

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

Parameters3/5

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

With a single parameter and 0% schema description coverage, the description compensates somewhat by specifying the filename format with an example ('sample.parquet') and the /data directory location. However, it doesn't clarify whether the path extension matters, whether it accepts paths with subdirectories under /data, or what happens with invalid filenames. The description adds moderate value beyond the bare schema.

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

Purpose4/5

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

The description clearly states the verb+resource: 'Summarize a Parquet file by reporting its number of rows and columns.' This is specific about what it does and distinguishes it from the sibling summarize_csv_file by explicitly naming the Parquet format. However, it doesn't explicitly contrast itself with the sibling tool, so it doesn't fully maximize sibling differentiation.

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 context by stating the tool works on files in the /data directory, but gives no explicit guidance on when to choose this over summarize_csv_file or any exclusions. The file-format naming (Parquet vs CSV) makes the usage distinction implicit but not explicitly stated.

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. 2 tool updatesv0.1.0
    • First observedsummarize_csv_file
    • First observedsummarize_parquet_file
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.3/5.0
Disambiguation3/5

The two tools are clearly distinct by file type (Parquet vs CSV), so an agent should be able to tell them apart when the file format is known. However, they share the identical purpose and structure (summarizing file dimensions), and there is no unified or generic tool to handle either format, which could cause confusion if an agent must guess the format.

Naming Consistency4/5

Both tools follow the same verb_noun pattern (summarize_parquet_file, summarize_csv_file), sharing the identical 'summarize' verb and 'file' suffix. The only variation is the file format in the middle, which is consistent and predictable, though the format should ideally be a parameter rather than baked into the tool name.

Tool Count3/5

With only 2 tools, this sits at the boundary of 'too few.' It's not a single trivial tool, but two near-identical tools covering only file summarization feels thin for a 'Data File Analysis' server, which implies a much broader analysis scope than just counting rows and columns.

Completeness2/5

For a server named 'Data File Analysis,' this surface is severely limited: there is no way to read, sample, filter, compute statistics, inspect columns/types, or join files. Even for a narrow summarization-only scope, neither tool supports inspecting column schemas or data previews, leaving significant gaps that will cause agent failures for common analysis tasks.

Maintenance

ActivityInactive
ResponsivenessSyncing

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 File Analyzer

    CindyGao8
    F
    license
    Not graded
    quality
    D
    maintenance
    An MCP server that enables the analysis of CSV and Parquet files by providing tools for statistical summaries, data previews, and structure exploration. It allows users to query local datasets and create sample data using natural language.
    -

  • mcp-server

    laurensanp
    F
    license
    Not graded
    quality
    D
    maintenance
    Enables AI models to interact with local CSV and Parquet data through MCP tools, providing summarization and analysis capabilities.
    1
    -

  • data-profiler-mcp

    haiiibin
    A
    license
    A
    quality
    A
    maintenance
    Enables LLMs to profile and analyze tabular data files (CSV, Parquet, Excel, JSON) by extracting schema, statistics, data quality issues, and dtype suggestions, returning structured JSON.
    7
    2
    MIT

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/llm-guy/mcp_server_public'

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