Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-csv-database analyze missing data in the sales table"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that provides comprehensive tools for loading CSV files into a temporary SQLite database and performing advanced data analysis with AI assistance.
Smart CSV Loading: Automatically detect CSV separators and load multiple files from a folder
Advanced SQL Queries: Execute any SQL query with automatic result formatting and pagination
Schema Inspection: View database schema, table structures, and relationships
Data Quality Analysis: Comprehensive missing data analysis, duplicate detection, and data profiling
Statistical Analysis: Column statistics, data summaries, and distribution analysis
Export Capabilities: Export query results or tables back to CSV with custom formatting
Performance Tools: Create indexes, analyze query execution plans, and optimize performance
AI-Ready: Designed for seamless integration with AI assistants for data analysis workflows
Related MCP server: mcp-server
pip install mcp-csv-databasegit clone https://github.com/Lasitha-Jayawardana/mcp-csv-database.git
cd mcp-csv-database
pip install -e .Start the server with stdio transport:
mcp-csv-databaseRecommended: Auto-load CSV files from a folder using positional argument:
mcp-csv-database /path/to/csv/filesAlternative syntax with explicit flag:
mcp-csv-database --csv-folder /path/to/csv/filesWith custom table prefix:
mcp-csv-database /path/to/csv/files --table-prefix sales_For remote access with HTTP transport:
mcp-csv-database /path/to/csv/files --transport sse --port 8080Add to your MCP client configuration:
{
"mcpServers": {
"csv-database": {
"command": "mcp-csv-database",
"args": ["/path/to/your/csv/files"]
}
}
}Alternative configuration with explicit options:
{
"mcpServers": {
"csv-database": {
"command": "mcp-csv-database",
"args": ["--csv-folder", "/path/to/csv/files", "--table-prefix", "analytics_"]
}
}
}load_csv_folder(folder_path, table_prefix="") - Load all CSV files from a folder with smart separator detection
list_loaded_tables() - List currently loaded tables with source file information
clear_database() - Clear all loaded data and temporary files
backup_database(backup_path) - Create complete database backups
execute_sql_query(query, limit=100) - Execute any SQL query with automatic result formatting
get_database_schema() - View complete database schema with column types and sample data
get_table_info(table_name) - Get detailed information about specific tables
get_query_plan(query) - Analyze query execution plans for performance optimization
get_data_summary(table_name) - Comprehensive data overview with insights and data types
get_column_stats(table_name, column_name) - Detailed statistical analysis for specific columns
analyze_missing_data(table_name) - Complete missing data analysis across all columns
find_duplicates(table_name, columns="all") - Advanced duplicate detection with configurable column sets
create_index(table_name, column_name, index_name="") - Create indexes for query optimization
export_table_to_csv(table_name, output_path, include_header=True) - Export tables with custom formatting
# Load CSV files
result = load_csv_folder("/path/to/csv/files")
# View what's loaded
schema = get_database_schema()
# Query the data
result = execute_sql_query("SELECT * FROM my_table LIMIT 10")
# Export results
export_table_to_csv("my_table", "/path/to/output.csv")# Get comprehensive data overview
summary = get_data_summary("sales_data")
# Detailed statistical analysis for specific columns
price_stats = get_column_stats("sales_data", "price")
quantity_stats = get_column_stats("sales_data", "quantity")
# Data quality assessment
missing_analysis = analyze_missing_data("sales_data")
duplicates = find_duplicates("sales_data", "customer_id,product")
# Complex analytical queries
result = execute_sql_query("""
SELECT
category,
COUNT(*) as count,
AVG(price) as avg_price,
SUM(quantity) as total_quantity,
MIN(price) as min_price,
MAX(price) as max_price,
STDDEV(price) as price_stddev
FROM sales_data
GROUP BY category
ORDER BY total_quantity DESC
""")
# Performance optimization
create_index("sales_data", "category")
query_plan = get_query_plan("SELECT * FROM sales_data WHERE category = 'Electronics'")# Step 1: Load and inspect data
load_csv_folder("/path/to/data")
schema = get_database_schema()
# Step 2: Data quality assessment
missing_data = analyze_missing_data("customers")
duplicates = find_duplicates("customers", "email")
summary = get_data_summary("customers")
# Step 3: Statistical analysis
age_stats = get_column_stats("customers", "age")
income_stats = get_column_stats("customers", "income")
# Step 4: Clean and analyze
clean_data = execute_sql_query("""
SELECT customer_id, name, email, city, age, income
FROM customers
WHERE email IS NOT NULL
AND age BETWEEN 18 AND 100
AND income > 0
""")The server supports multiple transport methods:
stdio (default): Standard input/output
sse: Server-sent events
streamable-http: HTTP streaming
# SSE transport
mcp-csv-database --transport sse --port 8080
# HTTP transport
mcp-csv-database --transport streamable-http --port 8080Python 3.10+ (required for MCP framework compatibility)
pandas >= 1.3.0
sqlite3 (built-in)
mcp >= 1.0.0
mcp-csv-database [folder_path] [OPTIONS]
# Positional Arguments:
# folder_path Path to folder containing CSV files (recommended)
# Options:
# --csv-folder PATH Alternative way to specify CSV folder path
# --table-prefix PREFIX Optional prefix for table names (e.g., 'sales_')
# --transport TYPE Transport type: stdio (default), sse, streamable-http
# --port PORT Port for HTTP transport (default: 3000)
# -h, --help Show help message and exit
# Examples:
mcp-csv-database /data/sales # Load CSV files from /data/sales
mcp-csv-database --csv-folder /data --table-prefix t_ # Load with table prefix
mcp-csv-database /data --transport sse --port 8080 # HTTP transport on port 8080Fork the repository
Create a feature branch (git checkout -b feature/amazing-feature)
Commit your changes (git commit -m 'Add amazing feature')
Push to the branch (git push origin feature/amazing-feature)
Open a Pull Request
This project is licensed under the MIT License - see the LICENSE file for details.
Enhanced CLI interface with positional argument support for CSV folder paths
Improved command-line help with comprehensive examples and tool descriptions
Fixed mypy type checking and added pandas-stubs for better development experience
Resolved GitHub Actions CI/CD pipeline configuration issues
Updated Python requirement to 3.10+ for MCP framework compatibility
Added comprehensive data analysis tools: get_data_summary(), get_column_stats(), analyze_missing_data(), find_duplicates()
Enhanced statistical analysis capabilities with numeric data detection
Improved data quality assessment and missing data visualization
Added advanced duplicate detection with configurable column sets
Enhanced table information display with better formatting
Improved CSV separator auto-detection (semicolon, comma, tab)
Enhanced error handling and user feedback
Better table naming with special character handling
Added comprehensive test coverage
Improved documentation and examples
Initial release
Basic CSV loading and SQL querying
Schema inspection tools
Data export capabilities
Multiple transport support
Analyze missing data patterns in a table.
Args: table_name: Name of the table to analyze
Returns: Summary of missing data patterns across all columns
| Name | Required | Description | Default |
|---|---|---|---|
| table_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It implies a read-only analysis but does not explicitly state non-destructive behavior, side effects, or output details beyond a vague 'summary'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a bulleted argument list. It is front-loaded with the main purpose, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to detail return format. It covers the single parameter adequately and is complete for a simple tool, though it could further clarify what 'missing data patterns' means.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description adds a simple explanation for table_name ('Name of the table to analyze'), which adds minimal value beyond the parameter name and type from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'analyze' and resource 'missing data patterns in a table', which distinguishes it from sibling tools like get_column_stats or find_duplicates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., get_data_summary, get_column_stats). The description lacks recommendations, exclusions, or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a backup of the current database to a file.
Args: backup_path: Path where to save the backup file
Returns: Status message
| Name | Required | Description | Default |
|---|---|---|---|
| backup_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose whether the backup locks the database, overwrites existing files, or requires specific permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short but includes redundant Args/Returns sections that mostly repeat schema information. Could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with 1 required param and an output schema, but description lacks context on impact (e.g., downtime, size estimates) and prerequisites (e.g., write permissions to backup_path).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but description adds a brief explanation for backup_path ('Path where to save the backup file') beyond the schema's title. However, it lacks details on format, validity, or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Create a backup of the current database to a file' using a specific verb and resource, and it distinguishes from sibling tools like clear_database or export_table_to_csv.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., export_table_to_csv) or any prerequisites (e.g., admin permissions).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clear the temporary database and remove all loaded tables.
Returns: Status message
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose that this operation is destructive and irreversible, nor does it mention any authorization requirements or side effects. Annotations are absent, so the description carries the full burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences; the first clearly states the action, the second notes the return value. No wasted words, though the return description is minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature, the description is incomplete. It fails to warn about irreversibility, impact on other operations, or recovery options. The existence of an output schema is not leveraged to describe the status message.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema coverage is 100%. The description adds no parameter-specific information, but baseline for high coverage is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool clears a temporary database and removes loaded tables. The verb 'clear' and resource 'temporary database' are specific, and it distinguishes from siblings like backup_database.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., backup_database). There is no mention of prerequisites or contraindications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an index on a table column for better query performance.
Args: table_name: Name of the table column_name: Name of the column to index index_name: Optional custom index name
Returns: Status message
| Name | Required | Description | Default |
|---|---|---|---|
| index_name | No | ||
| table_name | Yes | ||
| column_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It omits potential side effects like table locking, performance impact during creation, or permission requirements. The return is only 'Status message' with no detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and includes structured Args/Returns sections. However, it could be slightly more streamlined; the Args section duplicates schema info but adds value. No wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 params, no nested objects), the description covers basic usage. However, it lacks behavioral context (e.g., does it lock the table?) and the output schema is not shown but mentioned. Sibling tools suggest alternatives, but description doesn't guide selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaning by listing table_name, column_name, and index_name with brief explanations. It clarifies index_name's optionality and custom name role. Could mention default naming behavior but sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'index on a table column', with a specific purpose 'for better query performance'. It distinguishes from siblings like execute_sql_query (general SQL) and get_query_plan (plan analysis).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for query performance but provides no explicit guidance on when to use this tool versus alternatives (e.g., get_query_plan to analyze performance first). No when-not-to-use or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute any SQL query on the loaded database.
Args: query: Any SQL query to execute (SELECT, INSERT, UPDATE, DELETE, CREATE, etc.) limit: Maximum number of rows to return for SELECT queries (default: 100)
Returns: Query results formatted as XML or execution status
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states it can execute any SQL (SELECT, INSERT, etc.) and returns XML or status. However, it does not explicitly warn about destructive operations (e.g., DELETE, DROP) or the need for caution, which is important given no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (8 lines) with a clear structure: summary line, Args section, Returns section. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose and parameters but lacks warnings about destructive operations and does not elaborate on return formats beyond 'XML or execution status.' Given the tool's power, it could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the query parameter as 'Any SQL query to execute' and the limit parameter as 'Maximum number of rows to return for SELECT queries (default: 100).' This adds significant meaning beyond the bare schema (0% coverage).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Execute any SQL query on the loaded database,' clearly specifying the verb (execute) and resource (SQL query on the loaded database). This distinguishes it from sibling tools like get_database_schema and get_column_stats, which are read-only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives. It lists query types but lacks explicit when-to-use or when-not-to-use context, such as preferring get_database_schema for schema exploration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export a table to a CSV file.
Args: table_name: Name of the table to export output_path: Path for the output CSV file include_header: Whether to include column headers
Returns: Status message
| Name | Required | Description | Default |
|---|---|---|---|
| table_name | Yes | ||
| output_path | Yes | ||
| include_header | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully disclose behavioral traits. It does not mention side effects (e.g., file overwriting), permissions, encoding, or error handling. Only the basic action and parameter roles are described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence stating the purpose, followed by a compact parameter list. No wasted words, and the structure is clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple operation and no annotations, the description covers the core purpose and parameters. However, it lacks context on return values (status message is mentioned but not detailed), error scenarios, and output behavior. Adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates with brief parameter explanations: 'Name of the table to export', 'Path for the output CSV file', 'Whether to include column headers'. This adds some meaning beyond schema titles but remains minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports a table to a CSV file. The verb 'export' and resource 'table' are specific, and the output format 'CSV file' distinguishes it from sibling tools like 'execute_sql_query' or 'get_column_stats'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Does not mention prerequisites, scenarios, or when not to use it. Sibling tools offer different database operations but no comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find duplicate rows in a table.
Args: table_name: Name of the table to check columns: Comma-separated column names to check for duplicates, or "all" for all columns
Returns: Information about duplicate rows found
| Name | Required | Description | Default |
|---|---|---|---|
| columns | No | all | |
| table_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only mentions finding duplicates and returns 'Information about duplicate rows found,' lacking details on side effects, errors, performance, or behavior with empty tables.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single-line summary followed by structured 'Args' and 'Returns' sections. Every sentence is necessary, and the format is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description covers the core functionality and parameters adequately. However, it lacks details on edge cases, error handling, or how duplicates are defined, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains that 'columns' is a comma-separated list or 'all', and 'table_name' is the table to check. This adds meaningful semantics beyond the empty schema properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find duplicate rows in a table.' It uses a specific verb-resource pair and is distinct from sibling tools like 'analyze_missing_data' or 'execute_sql_query'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites, when not to use it, or trade-offs. It simply states the function without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get statistical summary for a specific column.
Args: table_name: Name of the table column_name: Name of the column to analyze
Returns: Statistical summary including count, nulls, unique values, and distribution info
| Name | Required | Description | Default |
|---|---|---|---|
| table_name | Yes | ||
| column_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose that the tool returns a statistical summary including count, nulls, unique values, and distribution info. However, it does not mention any safety or side effects (e.g., whether it is read-only, requires permissions, or is destructive), leaving some behavioral aspects unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and structured as a docstring with clear sections for Args and Returns. It is appropriately sized and front-loaded with the main purpose. However, it could be slightly more concise by removing redundant information (e.g., the Returns section already mirrors the main purpose).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description does not need to fully detail return values, but it does provide useful information about what is included. However, the description lacks usage guidelines and parameter details, which are important for a tool with moderate complexity. It is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, meaning no parameter descriptions are provided in the schema. The description merely restates the parameter names ('Name of the table', 'Name of the column to analyze') without adding any additional meaning, format constraints, or examples. With two parameters and no schema descriptions, the description does not compensate adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get statistical summary for a specific column.' It uses a specific verb and resource, and the tool is distinct from siblings like 'get_data_summary' (broader) and 'analyze_missing_data' (focused on missing data). However, it does not explicitly differentiate itself from these siblings, so it is not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. Siblings like 'get_data_summary' and 'analyze_missing_data' might be more appropriate in certain contexts, but the description does not mention these or provide any usage conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current database schema showing all loaded tables and their structure
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, but the description implies a read-only operation. No further behavioral traits (e.g., performance impact) are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, front-loaded sentence with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and an output schema, the description is adequate. It could mention handling of empty databases but not necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and schema coverage is 100%. The description adds context about what the schema includes (all loaded tables and their structure).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the current database schema showing all loaded tables and their structure, distinguishing it from siblings like list_loaded_tables.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided; the description does not indicate when to use this tool versus alternatives like get_table_info or execute_sql_query.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a comprehensive summary of the table data.
Args: table_name: Name of the table to summarize
Returns: Quick overview with key insights about the data
| Name | Required | Description | Default |
|---|---|---|---|
| table_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It does not state that the tool is read-only, what side effects exist (likely none), or authorization requirements. The phrase 'comprehensive summary' implies data access but lacks clarity on performance or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the purpose. The docstring style is clean, and every line serves a purpose (purpose, args, returns). It could be slightly more verbose on specifics but remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (summarizing data) and the existence of an output schema (not shown), the description should explain the nature of the summary (e.g., row count, columns, missing values). It only promises 'Quick overview with key insights', which is insufficient for accurate selection among sibling tools like analyze_missing_data or get_column_stats.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes a docstring for the single parameter 'table_name' as 'Name of the table to summarize', but this adds no meaning beyond what the schema's title already conveys. Schema description coverage is 0%, and the description fails to provide format constraints, examples, or context for the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get a comprehensive summary of the table data', which is a clear verb+resource pair. However, it fails to specify what 'comprehensive summary' entails, making it ambiguous compared to sibling tools like get_column_stats or get_table_info. It distinguishes itself but lacks concrete details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., get_column_stats, get_database_schema). The description does not mention prerequisites, exclusions, or typical scenarios, leaving the agent without context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the execution plan for a query to understand performance.
Args: query: SQL query to analyze
Returns: Query execution plan
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. While 'Get' suggests read-only, it does not explicitly state that the tool is non-destructive, nor does it mention any side effects, cost, or permissions. For a tool that analyzes queries, the lack of disclosure on whether it runs the query or just plans 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with only two lines of main text plus structured Args and Returns sections. It is front-loaded with the purpose. Minor reduction for including redundant 'Returns: Query execution plan' since output schema exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter) and existence of output schema, the description provides the essential purpose and parameter meaning. However, it lacks usage context and behavioral details that would make it fully self-contained for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds a brief explanation for the parameter ('SQL query to analyze'), which adds some meaning beyond the schema's title-only field. However, it does not specify format constraints or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the execution plan for a query to understand performance.' It uses a specific verb ('Get') and identifies the resource ('execution plan for a query'), distinguishing it from siblings like execute_sql_query which runs the query itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for performance understanding but provides no explicit guidance on when to use vs. alternatives, nor any exclusions or prerequisites. It lacks the precision needed to differentiate from similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific table.
Args: table_name: Name of the table to inspect
Returns: Detailed table information including schema and sample data
| Name | Required | Description | Default |
|---|---|---|---|
| table_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. It mentions returning schema and sample data, but does not explicitly state that it is read-only, safe, or any side effects. A simple get operation is inferred, but lacking explicit safety guarantees.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and uses a clear docstring format (Args, Returns). However, the Returns section is vague ('detailed table information') and could be more specific. No wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool operates in a database context with many sibling tools. The description gives a high-level idea but does not specify what 'detailed information' includes beyond schema and sample data, nor how it differs from get_database_schema or get_column_stats.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage (the schema's title 'Table Name' only restates the name), the description adds little: 'Name of the table to inspect' is still vague. No details on required format, allowed values, or impact of incorrect input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get detailed information about a specific table,' specifying the action (get) and resource (table). However, it does not differentiate from siblings like get_database_schema or get_column_stats, which might overlap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The context implies it is for individual table details, but no exclusion criteria or sibling 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 all currently loaded tables with their source CSV files
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It clearly states a read-only list operation with no side effects. Additional detail like format or limitations would improve but is not critical given tool simplicity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, 10 words, front-loaded with key action and resource. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and presence of output schema, description fully covers purpose and outcome for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, schema coverage 100%. Description adds no new parameter info but none needed. Baseline 4 for no-param tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'list' and resource 'currently loaded tables with their source CSV files'. Clearly distinguishes from sibling tools like get_table_info or get_database_schema by focusing on 'loaded' status and CSV sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied (when you need list of loaded tables and their CSV sources) but no explicit when-to-use or when-not-to-use, nor alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load all CSV files from a folder into a temporary SQLite database.
Args: folder_path: Path to folder containing CSV files table_prefix: Optional prefix for table names
Returns: Status message with details of loaded files
| Name | Required | Description | Default |
|---|---|---|---|
| folder_path | Yes | ||
| table_prefix | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses that loading is into a temporary SQLite database and returns a status message, but does not specify if database is in-memory or file-based, error handling, or side effects (e.g., overwriting existing tables).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences plus Args; no wasted words. Front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main action, inputs, and return (status message). Lacks prerequisites or caveats (e.g., folder existence, CSV format), but for a simple file-loading tool with only 2 parameters and no annotations, it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description's Args section provides clear explanations for both parameters (folder path and optional table prefix), adding meaning beyond the schema's type/title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Load all CSV files from a folder into a temporary SQLite database' – specific verb and resource, distinct from sibling tools which are database manipulation or analysis tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. Usage is implied by the resource (CSV files to database), but alternatives like export_table_to_csv are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.6analyze_missing_databackup_databaseclear_databasecreate_indexexecute_sql_queryexport_table_to_csvfind_duplicatesget_column_statsget_data_summaryget_database_schemaget_query_planget_table_infolist_loaded_tablesload_csv_folderScored across 14 tools
Most tools have clearly distinct purposes, but there is some overlap among info tools (get_table_info, get_database_schema, get_data_summary) that could cause confusion if an agent doesn't read descriptions carefully.
All tool names follow a consistent verb_noun pattern (e.g., load_csv_folder, find_duplicates, get_column_stats), making it easy to predict functionality from the name.
14 tools cover the core operations of a CSV database server (loading, querying, analysis, management, export) without being excessive or sparse.
The tool surface covers loading, querying, analysis, schema inspection, indexing, backup, and export. Missing dedicated tools for dropping tables or bulk data modifications, but these can be handled via execute_sql_query.
Query, join, profile, clean and convert CSV/JSON/Parquet with server-side DuckDB over MCP.
Query your warehouse or a CSV with Claude/ChatGPT over MCP, governed by table-level ACL + audit.
Analytical memory for AI agents: a real Postgres queried in plain English over MCP. One command.
Open, inspect, filter, edit and convert xlsx and csv files from your AI chat. Processing is local.