mcp-duckdb-analyst
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| db | No | Existing DuckDB database file, attached read-only as catalog db | |
| data | Yes | Directory scanned recursively for .csv .parquet .json .jsonl .ndjson (required) | |
| host | No | Bind address for streamable HTTP | 127.0.0.1 |
| port | No | Bind port for streamable HTTP; the endpoint is /mcp | 8000 |
| check | No | Register the files, print the catalog and exit | false |
| max-rows | No | Hard cap on rows per result; query(limit=...) can only lower it | 500 |
| log-level | No | Server log level; logs go to stderr | WARNING |
| max-cells | No | Cap on rows x columns per result | 20000 |
| timeout-s | No | Per-query timeout; the query is interrupted | 30 |
| transport | No | MCP transport | stdio |
| allow-extensions | No | Accept INSTALL/LOAD and extension autoloading (relaxes the DuckDB sandbox) | false |
| allow-saved-queries | No | Enable save_query / list_saved_queries (writes saved_queries.json into the data directory) | false |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_tablesA | List all queryable tables and views with source file, kind and row count. |
| describe_tableB | Columns of a table with DuckDB type, nullability, null count and sample values. |
| profile_tableA | Per-column statistics: count, null %, distinct, min, max, mean/stddev (numeric), top-5 values for low-cardinality columns. Optionally restrict to some columns. |
| sample_rowsA | A reproducible random sample of n rows from a table (n is capped at max rows). |
| queryA | Run one read-only SQL statement (SELECT / WITH / DESCRIBE / SHOW / SUMMARIZE / EXPLAIN). Returns columns, JSON rows, a Markdown table, a truncated flag and the elapsed time. The row limit is min(limit, server max rows). |
| explain_queryA | Show DuckDB's physical query plan for a SELECT without running it. |
| search_columnsA | Find columns across all tables by case-insensitive substring or * / ? glob. |
| table_relationshipsA | Heuristic foreign-key candidates: *_id columns whose sampled values are contained in a matching column of another table. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| analyze_table | Step-by-step instructions for a first structured analysis of a table. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| schema | All tables with their columns and types. |
TDQS
Scored across 8 tools
Most tools have clearly distinct purposes: table listing, column search, profiling, sampling, relationships, and query execution. The main ambiguity is that `query` supports DESCRIBE, SUMMARIZE, and EXPLAIN, which overlaps semantically with `describe_table`, `profile_table`, and `explain_query`, though the specialized tools return richer structures.
Tool names generally follow a clear snake_case verb_noun pattern like list_tables, describe_table, profile_table, and explain_query. Two deviations exist: `query` has no object and `table_relationships` is noun_noun rather than verb_noun, but the overall naming style remains coherent.
Eight tools is well within the ideal range for a read-only DuckDB analyst server. Each tool covers a meaningful part of the analytical workflow without unnecessary redundancy or bloat.
The tool surface covers the core read-only analysis lifecycle: discovering tables, exploring schemas, profiling columns, sampling rows, searching columns, understanding relationships, and running arbitrary queries. There are no obvious dead ends for a typical data-analysis workflow.