eda-mcp is an MCP server for exploratory data analysis (EDA) that lets AI assistants load datasets, compute statistics, generate plots, and produce comprehensive reports.
Load a dataset (load_dataset): Load local files (CSV, Parquet, Excel, JSON, NDJSON, Avro, SQLite, DuckDB) and get a structural overview — column names, types, classifications, row count, and missing value counts.
Query with SQL (query_dataset): Run DuckDB SQL queries against local files, remote sources (S3, GCS, HTTP), or perform cross-file joins; results are saved to Parquet for further analysis.
Single column summary (get_column_summary): Retrieve full statistics for one column — five-number summary, skewness, kurtosis, outlier count, normality test, value counts, class balance, date ranges, etc., depending on column type.
All column summaries (get_all_summaries): Retrieve summary statistics for every column in a single call.
Diagnostic plots (get_diagnostic_plot): Auto-generate and save a PNG plot for a column — histograms/KDE/boxplot/QQ for continuous, bar charts for categorical/binary, time series for temporal, etc.
Correlation analysis (get_correlations): Compute Pearson and Spearman correlation matrices, generate a heatmap, and produce scatter plots for strongly correlated numeric pairs.
Full EDA report (generate_report): Produce a markdown report with dataset overview, data quality flags, per-column summaries with diagnostic plots, and plain-English interpretations.
Click on "Install 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., "@eda-mcp Generate a full EDA report for customers.xlsx"
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.
An MCP server for exploratory data analysis. Point it at a dataset and let your AI assistant do the analysis — summary statistics, diagnostic plots, correlation analysis, and full markdown reports, all from a single conversation.
Built by MLMecham.
Run instantly with no install step:
uvx eda-mcpOr install permanently:
pip install eda-mcpRelated MCP server: holoviz-viz-mcp
Add this to your claude_desktop_config.json:
Mac: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"eda-mcp": {
"command": "uvx",
"args": ["eda-mcp"]
}
}
}Restart Claude Desktop. The tools will appear automatically.
Tip: Add
--refreshto always pull the latest version from PyPI on startup:"args": ["--refresh", "eda-mcp"]
Tools not appearing after install or update
uvx caches the installed version and won't update automatically. Force a refresh:
uvx --refresh eda-mcp --helpThen fully quit and reopen Claude Desktop (not just close the window).
Check server logs
If the tools still don't appear, check the MCP server logs:
Windows: %APPDATA%\Claude\logs\mcp-server-eda-mcp.log
Mac: ~/Library/Logs/Claude/mcp-server-eda-mcp.log
Tool | Description |
| Load a file and return a structural overview — column names, types, classifications, missing value counts, and duplicate stats. Start here. |
| Run a DuckDB SQL query and return the same overview as |
| Full statistics for a single column. Accepts optional |
| Summary statistics for every column at once, keyed by column name. |
| Summary statistics for a column broken down by one or more group columns. Compact by default, |
| Generate a diagnostic plot for a single column. Plot type is auto-selected by classification. Accepts optional |
| Compute all three association types: Pearson + Spearman (numeric), Cramér's V (categorical), and eta-squared (mixed). Each type toggleable independently with separate thresholds. |
| Compare the distributions of two data slices column by column. Accepts file paths or SQL queries. Returns labeled deltas for all numeric and categorical columns. |
| Full EDA report — dataset overview, data quality flags, per-column summaries with plots, and full association analysis. Saved as markdown. |
Format | Extension |
CSV |
|
Parquet |
|
Excel |
|
JSON |
|
Newline-delimited JSON |
|
Avro |
|
SQLite |
|
DuckDB |
|
String columns are automatically coerced to better types on load (integers, floats, dates) where unambiguous.
For SQLite and DuckDB files with multiple tables, pass the table parameter to specify which one. If the database has exactly one table it is loaded automatically.
Use query_dataset for SQL-based loading, remote sources, or cross-file joins:
-- Filter before analysis
SELECT * FROM 's3://bucket/sales.parquet' WHERE year = 2024
-- Cross-file join — mix any DuckDB-readable sources
SELECT t.*, p.bst FROM 'trainers.csv' t JOIN 'pokemon.parquet' p ON t.pokemon = p.name
-- Query a local DuckDB database (pass db_path separately)
SELECT * FROM my_table
-- Hive-partitioned S3
SELECT * FROM read_parquet('s3://bucket/data/', hive_partitioning=true)Pass the result_path from query_dataset to any other tool exactly like a regular file_path.
get_correlations computes three types of associations in one call:
Type | Measure | Columns | Default threshold |
| Pearson + Spearman | continuous, discrete | 0.5 |
| Cramér's V | categorical, binary | 0.3 |
| Eta-squared (η²) | categorical vs numeric | 0.1 |
Toggle each type with numeric=True/False, categorical=True/False, mixed=True/False. Set plots=True to generate heatmaps and pair-level charts.
compare_distributions diffs two slices column by column:
# Compare two cut grades
compare_distributions(
"SELECT * FROM 'diamonds.parquet' WHERE cut='Ideal'",
"SELECT * FROM 'diamonds.parquet' WHERE cut='Fair'",
label_a="Ideal", label_b="Fair"
)
# Compare two time periods
compare_distributions("sales_2023.parquet", "sales_2024.parquet", label_a="2023", label_b="2024")Returns mean, median, std, outlier, and missing value deltas per column — Claude can immediately say how much each statistic changed.
Every column is automatically classified before analysis:
Classification | Description |
| Floats, or integers with more than 20 unique values |
| Integers with 20 or fewer unique values |
| Strings with low cardinality (< 5% unique ratio or ≤ 10 unique values) |
| Booleans, or any column with exactly 2 unique non-null values |
| Date, Datetime, or Duration columns |
| Likely identifiers, UUIDs, or free text — statistical summary skipped |
Pass classification="categorical" to any summary or plot tool to override the auto-detected type.
The core functions are also importable directly:
from eda_mcp import (
load_file, load_query,
classify_column, get_summary,
numeric_columns, categorical_columns,
compute_correlations, compute_cramers_v, compute_eta_squared,
generate_markdown_report,
)
df = load_file("data/sales.parquet")
summary = get_summary(df["revenue"])
generate_markdown_report(df, "data/sales.parquet", "output/")
# Query and analyze
df = load_query("SELECT * FROM 'data.parquet' WHERE region='West'")Once connected to Claude:
Analyze this dataset: /path/to/data.csvJoin the Batting and People tables in my Lahman SQLite database and generate a full EDA reportCompare the price distribution between Ideal and Fair cut diamondsHow does revenue vary across regions and product categories?What columns in sales.parquet have missing values?Generate a full EDA report for customers.xlsxPython 3.11+
Dependencies are installed automatically via uvx or pip
MIT
Generate a complete EDA markdown report for the entire dataset. This is the main tool to call for a thorough, end-to-end analysis. The report includes:
Dataset overview: row count, column count, memory usage, total missing values
Data quality flags: columns with >20% missing values, imbalanced binary columns, high cardinality columns, columns with infinite values, columns with >10% outliers by IQR method
Per-column variable summaries: statistics table, diagnostic plot image, and a 2-3 sentence plain english interpretation of the distribution shape, outliers, and data quality for each column
Saves the report as {filename}_eda_report.md in output_dir alongside the diagnostic plot PNGs. Returns the path to the saved report file.
For quick inspection of a single column use get_column_summary or get_diagnostic_plot instead of running the full report.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | ||
| output_dir | No | ||
| table | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It details the report's contents (overview, flags, per-column summaries) and side effects (saves markdown and PNGs). It does not mention resource usage or error conditions but is otherwise transparent for a read-only operation.
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 well-structured with a single paragraph and bullet points. Every sentence is informative, front-loads the main purpose, and includes alternatives at the end with no wasted verbiage.
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 (3 params, no output schema), the description covers the return value (file path), report contents, and side effects. It lacks explanation for the 'table' parameter and error conditions but is otherwise sufficient for effective use.
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 file_path and output_dir implicitly but fails to describe the 'table' parameter. This partial coverage leaves meaning gaps, though the described parameters add value over 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 tool generates a complete EDA markdown report for the entire dataset, specifying verb and resource. It distinguishes from sibling tools by noting that for single-column inspection, one should use get_column_summary or get_diagnostic_plot.
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 explicitly positions this as the main tool for thorough end-to-end analysis and provides clear alternatives for quick inspection of a single column, giving both when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return summary statistics for every column in the dataset in a single call, keyed by column name. Each value contains all statistics appropriate for the column's detected type — equivalent to calling get_column_summary once per column.
Use this for a complete statistical overview of the entire dataset at once. For large datasets with many columns, prefer get_column_summary to inspect individual columns of interest rather than loading everything at once.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | ||
| table | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It hints at performance implications for large datasets but does not explicitly state non-destructiveness, error handling, or return behavior constraints.
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 succinct sentences, front-loaded with purpose, no redundant or vague language.
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 no output schema and no annotations, the description is adequate but missing details like return format, supported file types, and what happens when table is null.
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%, and the description does not explain file_path or table parameters beyond context of 'dataset' and 'columns'. The table parameter remains mostly undocumented.
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 it returns summary statistics for every column, using clear verb+resource 'Return summary statistics'. It also distinguishes from sibling get_column_summary by noting it's equivalent to calling that once per column.
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?
Explicitly says when to use (complete overview) and when not to (large datasets with many columns), and names alternative get_column_summary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return full summary statistics for a single column. The column type is auto-detected and the appropriate statistics are computed:
continuous/discrete: five-number summary, mean, std, skewness with plain english label, kurtosis with label, outlier count (IQR method), zero count, infinite count, normality test (scipy normaltest p-value and result)
categorical: mode, top 10 value counts with percentages
binary: mode, top value counts, class balance ratio with imbalance flag (flagged if majority:minority ratio exceeds 3:1)
temporal: min/max date, date range in days, gap count, most common year and month
high_cardinality: flagged as likely ID or free text with sample values only
Use this to investigate a specific column in depth after calling load_dataset to identify columns of interest.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | ||
| column | Yes | ||
| table | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description thoroughly discloses behavior: auto-detects column type and lists all computed statistics for continuous, categorical, binary, temporal, and high_cardinality columns.
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 structured with bullet points for clarity and front-loaded with the main action. However, it is somewhat verbose in listing all statistics, which 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?
Given the complexity of column types, the description comprehensively covers return values. It provides usage context relative to load_dataset but lacks details on error cases or edge conditions.
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%, and the description does not explain parameters (file_path, column, table) in detail. The table parameter is not mentioned at all, leaving ambiguity about its role.
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 'Return full summary statistics for a single column' and details the specific statistics for each type, distinguishing it from siblings like 'get_all_summaries' and 'load_dataset'.
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?
Explicitly says to use 'after calling load_dataset to identify columns of interest', providing context for when to use this tool. However, it does not explicitly contrast with 'get_all_summaries' or mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute pairwise correlations between all numeric columns in the dataset and generate a Spearman correlation heatmap. Scatter plots are generated for column pairs with a Spearman correlation above the threshold.
Returns both Pearson and Spearman correlation matrices, the strongest pairs above the threshold (sorted by absolute Spearman correlation, max 10), highly correlated flags for pairs with |ρ| >= 0.9, and file paths for all generated plots.
Only continuous and discrete columns are included — categorical, binary, temporal, and high_cardinality columns are excluded automatically.
threshold controls which pairs get scatter plots (default 0.5). Set higher e.g. 0.7 for only strong correlations, lower e.g. 0.3 to cast a wider net. Scatter plots are capped at 10 pairs regardless of threshold.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | ||
| output_dir | No | ||
| threshold | No | ||
| table | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully discloses behavioral traits: returns both Pearson and Spearman matrices, strongest pairs (max 10), flags for high correlation, generated plot paths, scatter plot cap (10 pairs), and automated column type exclusions.
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 moderately sized with several sentences, but each adds necessary detail. Well-structured: first paragraph overview, second paragraph return values, third paragraph exclusions, fourth paragraph parameter guidance. Could be slightly more concise, but no wasted content.
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 all key aspects: what tool computes, parameters, returns, exclusions, and parameter behavior. With 4 params, 0% schema coverage, and no output schema, it provides sufficient information for an agent to use effectively. Minor gaps in file_path format, but overall 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 has 0% description coverage, so description must explain parameters. It clarifies threshold behavior with examples and mentions file_path (implied input), output_dir, and table. Does not detail file_path format or output_dir structure, but adds significant value over bare 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?
Description clearly states it computes pairwise correlations and generates Spearman heatmap and scatter plots. It distinguishes from sibling tools (generate_report, get_all_summaries, etc.) which serve different purposes.
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?
Provides clear context on when to use (numeric columns) and exclusions (categorical, binary, etc.). Also gives practical advice on threshold adjustment. Lacks explicit when-not-to-use, but overall strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate and save a diagnostic plot for a single column as a PNG file. The plot type is automatically selected based on the column's classification:
continuous: 2x2 panel — histogram with KDE overlay, boxplot with outliers, QQ plot with reference line, ECDF
discrete: bar chart of value counts and boxplot side by side
categorical: horizontal bar chart of top 20 values with percentage labels
binary: bar chart of class balance with proportion labels; bars are red if the majority:minority ratio exceeds 3:1
temporal: line plot of counts over time and bar chart of counts by month
high_cardinality: no plot is generated; a message is returned instead
Saves the PNG to output_dir/{column}_diagnostics.png and returns the file path. Use output_dir to control where plots land — the same folder as the dataset or a dedicated output directory both work well.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | ||
| column | Yes | ||
| output_dir | Yes | ||
| table | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behaviors: auto-selects plot type per column type, handles high_cardinality by returning a message, saves to output_dir, returns file path. This is comprehensive and leaves no ambiguity about side effects.
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 well-structured with front-loaded purpose and organized bullet list for plot types. It is detailed but not overly verbose; each section serves a purpose. Minor redundancy in listing all plot types could be condensed.
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 (multiple column types, automatic selection) and lack of output schema, the description covers all essential behavior: input handling, output path, return value, and special cases (high_cardinality). It is sufficient for an agent to correctly invoke the 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?
Schema coverage is 0%, but the description adds value for output_dir by explaining its purpose. However, file_path, column, and table are not described beyond schema names. The description partially compensates but leaves gaps.
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 generates and saves a diagnostic plot as PNG, and details automatic plot type selection per column classification. This distinguishes it from siblings like get_column_summary or get_correlations which serve different purposes.
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 the tool is for diagnostic visualization but does not explicitly state when to use it versus siblings like get_column_summary or get_all_summaries. No guidance on when not to use it or prerequisites is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load a dataset and return a structural overview. Call this first when exploring an unfamiliar dataset — it gives you the shape, column types, classifications, and missing value counts you need to decide what to investigate next.
Returns: column names, dtypes, row count, per-column classifications (continuous, discrete, categorical, binary, temporal, high_cardinality), missing value counts and percentages per column.
Supports CSV, Parquet, Excel (.xlsx/.xls), JSON, NDJSON, Avro, and SQLite
(.db/.sqlite). For SQLite files with multiple tables, pass the table name
via table. If omitted and the database has exactly one table, it is loaded
automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | ||
| table | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses supported file formats, return structure (column names, dtypes, classifications, missing values), and SQLite auto-load behavior. It implies a read-only operation but doesn't explicitly state 'read-only'. Still thorough 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?
Description is well-structured: starts with purpose, then output details, then supported formats and special behavior. At ~150 words, it is concise but not overly brief. Every sentence adds value, though some repetition could be trimmed.
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?
Tool supports multiple formats and returns structural metadata. Description covers supported formats, column classifications, missing values, and SQLite table handling. It lacks details on file path resolution or permissions, but for an initial loading tool, it is sufficiently complete. No output schema, so description serves as return documentation.
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?
Input schema has 0% description coverage; description adds meaning by explaining file_path as the dataset path and table as optional SQLite table name with default behavior. This compensates well for the schema's lack of descriptions, though file_path could be more specific (e.g., local vs remote).
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 a dataset and return a structural overview', with specific verb 'load' and resource 'dataset'. It distinguishes from sibling tools (e.g., generate_report, get_all_summaries) by explicitly saying 'Call this first when exploring an unfamiliar dataset'.
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?
Description explicitly advises 'Call this first when exploring an unfamiliar dataset', implying when to use. It also explains behavior for SQLite files when table is omitted. However, it does not explicitly state when not to use it or provide alternatives beyond the implicit ordering.
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. Dates show when Glama detected each change.
v0.1.0generate_reportget_all_summariesget_column_summaryget_correlationsget_diagnostic_plotload_datasetEach tool has a clearly distinct purpose: loading data, per-column statistics, bulk statistics, diagnostic plots, correlations, and full report generation. Descriptions further clarify when to use each, with references between tools to avoid confusion.
All tool names follow a consistent verb_noun snake_case pattern: load_dataset, get_column_summary, get_all_summaries, get_diagnostic_plot, get_correlations, generate_report. No mixing of styles or vague verbs.
With 6 tools, the server is well-scoped for its EDA purpose. Each tool serves a necessary function without redundancy, and the count is appropriate for a focused toolkit.
The tool surface covers the core EDA workflow: loading, single-column summaries and plots, multi-column summaries, correlations, and a comprehensive report. Minor gaps like bivariate categorical analysis or data profiling exist, but the set is reasonably complete for exploratory analysis.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
MCP server for building and testing AI agents with multi-model experimentation and insights.
Query, join, profile, clean and convert CSV/JSON/Parquet with server-side DuckDB over MCP.
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/MLMecham/eda-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
