Allows querying PostgreSQL databases, including cross-source joins with other data sources like CSV files and REST APIs via DuckDB.
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., "@mcp-data-pipeline-connector Show me the first 5 rows of sales"
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.
npm mcp-data-pipeline-connector package
One MCP server for all your data sources — with cross-source SQL joins and no external query service. DuckDB runs embedded in-process, so you can join a CSV file against a Postgres table against a REST API response in a single query, entirely on your machine. Agents work with your data without needing source-specific knowledge or multiple MCP server configs.
Tool reference | Configuration | Contributing | Troubleshooting
Unified query interface: SQL across all connected sources via DuckDB — including cross-source joins.
Multiple source types: CSV/JSON files, PostgreSQL databases, and REST API endpoints in a single server.
Auto schema detection: Infers column names and types from CSV headers and Postgres metadata.
REST caching: REST API responses are cached with a configurable TTL to avoid redundant calls.
Schema normalization: Maps source-specific types to a standard set (string, number, date, boolean, json).
In-process query engine: DuckDB runs embedded — no separate query service to install or manage.
Related MCP server: MotherDuck DuckDB MCP Server
The common alternative is running one MCP server per data source — a postgres MCP server, a CSV MCP server, a REST MCP server. Each works fine in isolation, but they can't talk to each other.
mcp-data-pipeline-connector | Separate per-source servers | |
Cross-source joins | Native SQL via embedded DuckDB | Not possible — agent must fetch and join manually |
Config complexity | One server entry in your MCP config | One entry per source type |
Query engine | DuckDB in-process — no install, no service | Depends on each source's query capabilities |
Schema unification | Normalizes all types to string/integer/number/datetime/boolean/json/unknown | Each source uses its own type system |
Data residency | All queries run locally | Depends on each connector's implementation |
If you're asking questions that span multiple data sources — "join my sales CSV with the users table" — this is the right tool. If you only ever query one source type, a dedicated single-source server is simpler.
mcp-data-pipeline-connector connects to data sources you configure and executes queries against them on behalf of your agent. Ensure agents only have the database permissions they need. Connection strings are never logged or transmitted; keep them out of version-controlled config files. Use environment variables for credentials.
Node.js v20.19 or newer.
npm.
Optional: A running PostgreSQL instance for the Postgres connector.
Add the following config to your MCP client:
{
"mcpServers": {
"data-connector": {
"command": "npx",
"args": ["-y", "mcp-data-pipeline-connector@latest"]
}
}
}Define your data sources in ~/.mcp/data-sources.yaml:
sources:
- name: sales
type: csv
path: ~/data/sales-2025.csv
- name: users
type: postgres
connection_string: "${POSTGRES_URL}"
tables: [users, subscriptions]Store connection strings in environment variables, not directly in the YAML file.
Amp · Claude Code · Cline · Cursor · VS Code · Windsurf · Zed
Place a CSV file at ~/data/sample.csv, add it as a source in your config, then enter:
What columns are in the sample table? Show me the first 5 rows.Your client should return the schema and a preview of the data.
connect_source
list_sources
list_tables
get_schema
query
transform
check_health
--config / --sources-configPath to the YAML file defining data sources.
Type: string
Default: ~/.mcp/data-sources.yaml
--rest-cache-ttlTime-to-live in seconds for cached REST API responses. Set to 0 to disable caching.
Type: number
Default: 300
--max-rowsMaximum number of rows returned by a single query call. Prevents accidental large result sets.
Type: number
Default: 1000
--read-onlyReject any SQL statements that are not SELECT queries. Enforces read-only access across all sources.
Type: boolean
Default: true
Pass flags via the args property in your JSON config:
{
"mcpServers": {
"data-connector": {
"command": "npx",
"args": ["-y", "mcp-data-pipeline-connector@latest", "--max-rows=5000", "--rest-cache-ttl=60"]
}
}
}Before publishing a new version, verify the server with MCP Inspector to confirm all tools are exposed correctly and the protocol handshake succeeds.
Interactive UI (opens browser):
npm run build && npm run inspectCLI mode (scripted / CI-friendly):
# List all tools
npx @modelcontextprotocol/inspector --cli node dist/index.js --method tools/list
# List resources and prompts
npx @modelcontextprotocol/inspector --cli node dist/index.js --method resources/list
npx @modelcontextprotocol/inspector --cli node dist/index.js --method prompts/list
# Call a tool (example — replace with a relevant read-only tool for this plugin)
npx @modelcontextprotocol/inspector --cli node dist/index.js \
--method tools/call --tool-name list_sources
# Call a tool with arguments
npx @modelcontextprotocol/inspector --cli node dist/index.js \
--method tools/call --tool-name list_sources --tool-arg key=valueRun before publishing to catch regressions in tool registration and runtime startup.
Each connector lives in src/connectors/ and must implement the DataConnector interface. Add fixture data files under tests/fixtures/ for integration tests. Never log connection strings or credentials — sanitize before any output or error message.
npm install && npm testmcp-data-pipeline-connector is listed on MCP Registry and MCP Market.
REST source fails to connect: Confirm the URL is reachable and any auth env var is set. Use check_health to retest after startup.
Cross-source join returns no results: Ensure both sources are CSV type and registered before using source='_all'.
Query returns truncated: true: Increase --max-rows or add a LIMIT clause to your SQL.
Check whether registered data sources are still reachable and responsive.
| Name | Required | Description | Default |
|---|---|---|---|
| source | No | Optional: name of a specific source to health-check |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare readOnlyHint=true, so the read-only nature is covered. The description adds the behavioral detail of checking reachability and responsiveness, but it does not disclose the return format, per-source behavior, or edge cases like unreachable sources.
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 a single, focused sentence that states the tool's purpose immediately, with no filler or redundant 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?
The tool is simple, but without an output schema, the description does not specify what the function returns (e.g., a boolean, status per source, or a summary). This leaves minor ambiguity for an agent that needs to interpret the result, though the core behavior is clear.
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 schema provides a clear description for the single optional 'source' parameter with 100% coverage. The tool description does not add parameter-specific meaning but none is needed given the schema's clarity.
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 uses the specific verb 'check' with the resource 'registered data sources' and defines the success criteria ('reachable and responsive'). This clearly distinguishes it from sibling tools like 'query' or 'list_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?
The description implies a diagnostic use case (verify connectivity) but does not explicitly say when to use this tool over alternatives like 'connect_source' or 'list_sources'. It also lacks explicit exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register a data source (CSV file, Postgres database, or REST API). Credentials must be in environment variables or a YAML config file — never pass connection strings directly.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Base URL for REST API sources | |
| name | Yes | Unique name for this data source | |
| path | No | File path for CSV/JSON sources | |
| type | Yes | Type of the data source | |
| source_config_path | No | Path to a YAML config file. If provided, all sources in the file are registered. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only state readOnlyHint=false, so the 'Register' action's mutating nature is already clear. The description adds meaningful credential-handling guidance (env vars/config, never direct connection strings), which goes beyond the annotation and helps avoid security misuse.
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 concise sentences, front-loaded with the primary purpose and immediately followed by a critical security constraint. 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?
Given the tool's moderate complexity (5 params, enum, no output schema), the description covers the registration types and credential requirements. The source_config_path behavior is described in the schema, and the security note fills a practical gap, though it does not mention return values or failure handling.
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 100%, so the baseline is 3. The description adds value by explaining that credentials must never be passed directly, which affects how url and source_config_path should be used. This is extra semantic context not present in the schema descriptions.
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 registers a data source, enumerating supported types (CSV, Postgres, REST). 'Register' is a specific verb that distinguishes it from siblings like list_sources and query, which operate on already-registered 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?
The description implies use when adding a new data source and clarifies credential requirements (env vars or YAML config). However, it does not explicitly mention alternatives or when not to use it, though the sibling context makes this reasonably inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the column names and types for a specific table.
| Name | Required | Description | Default |
|---|---|---|---|
| table | Yes | Name of the table | |
| source | Yes | Name of the source that contains the table |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds the output content (column names/types) and the scoping to a specific table. It does not disclose additional behaviors such as error handling or requirements, but given the annotation coverage, this is adequate baseline.
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 a single, concise sentence that immediately conveys the tool's function. Every word contributes meaning, with no redundancy or filler.
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 two clearly described parameters, the description fully explains what the tool returns and when it is used. The lack of an output schema is compensated by the explicit statement of return content, and the read-only annotation covers the safety profile.
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 already provides descriptions for both parameters (source and table), achieving 100% coverage. The description adds minimal semantic value beyond the schema, merely reinforcing that the table is 'specific' and that the output is schema-related, so the baseline of 3 is appropriate.
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 uses a specific verb 'Return' and clearly states the resource ('column names and types for a specific table'). It distinguishes itself from siblings like list_tables (which lists table names) and query (which returns data) by focusing on schema metadata.
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 should be used when you need the column names and types of a specific table, providing clear context. It does not explicitly mention alternatives or exclusions, but the purpose is specific enough to guide appropriate usage among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all registered data sources and their connection status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds context about the return content ('connection status'), which goes beyond the annotation. However, it does not disclose output format, ordering, or any prerequisites like needing to connect first. With annotations covering the safety profile, a 3 is appropriate.
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 a single, front-loaded sentence that says exactly what the tool does without any filler. 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?
With zero parameters, a read-only annotation, and no output schema, the description adequately covers the tool's purpose and key detail (connection status). It could mention return shape or whether sources must be registered first, but for a simple listing operation it is sufficiently complete given the simple context.
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, so the description has no parameter details to clarify. The phrase 'all registered data sources' adds meaning about scope. Baseline for zero parameters is 4, and the description does not reduce that value.
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 uses a specific verb 'List' with a clear resource 'registered data sources' and adds useful scope 'connection status'. It clearly distinguishes from siblings like list_tables (which lists tables within a source) and check_health (which checks system health).
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 like connect_source or query. It implies usage for discovering available sources, but no explicit context or exclusions are given. With multiple siblings present, this lack of guidance is a gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available tables across all sources, or just the named source.
| Name | Required | Description | Default |
|---|---|---|---|
| source | No | Optional: name of a specific source to list tables for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, covering the safety profile. The description adds the scoping detail (all sources vs named source) but no other behavioral traits such as pagination, rate limits, or return format. This is similar to the get_calls calibration example.
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 a single sentence, efficiently front-loaded with the verb and resource, with zero 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?
The tool is simple with one optional parameter and a read-only annotation. The description adequately covers its purpose and scope; no output schema is needed because the result is clearly implied as a list of table names.
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 provides 100% description coverage for the 'source' parameter, and the tool description reinforces the same meaning without adding extra syntax or format details. The baseline of 3 applies because the schema does the heavy lifting.
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 uses the specific verb 'List' with the resource 'tables' and clearly states the optional scoping to a named source, which differentiates it from siblings like list_sources. It is direct and unambiguous.
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 by describing what it lists and the optional source filter, but it does not explicitly state when to use this tool over alternatives like get_schema or list_sources, nor does it provide exclusions or 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.
Execute a SQL query against a registered data source using DuckDB. Returns up to --max-rows rows (default 1000). In read-only mode (default), only SELECT statements are allowed. Use source='_all' to query across all CSV sources with cross-source joins. Supports limit and offset for pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | The SQL query to execute | |
| limit | No | Maximum number of rows to return (pagination) | |
| offset | No | Number of rows to skip before returning results (pagination) | |
| source | No | Name of the source to query, or '_all' for cross-source joins. Required if multiple sources are registered. | |
| sources | No | Array of source names for cross-source queries (alternative to source='_all') | |
| max_rows | No | Override the default max row limit for this query |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint is reinforced and expanded by the description's mention of read-only mode and SELECT-only restriction. It adds specific behavior like max-rows default, cross-source joins, and pagination support. No contradiction; the description goes beyond the annotation by disclosing default limits and mode.
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 sentences deliver a clear purpose, constraints, and pagination details with no wasted words. The description is front-loaded with the main function and includes all key behavioral notes in a compact, structured way.
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 (6 params, no output schema), the description covers essential context: data source registration, DuckDB, read-only mode, max rows, pagination, and cross-source joins. It doesn't detail error handling or exact return format, but that's partially covered by the mention of row limits and the sibling tools provide supplementary context.
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 100%, so all parameters are individually documented. The description adds valuable context beyond the schema: clarifies source='_all' for cross-source joins, confirms limit/offset are for pagination, and explains max_rows as an override. This extra meaning helps the agent use the parameters correctly.
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 executes a SQL query against a registered data source using DuckDB, distinguishing it from sibling tools like list_sources or get_schema. The verb 'Execute' and resource 'SQL query' are specific and unambiguous.
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?
It provides explicit context: default read-only mode, only SELECT allowed, and how to use source='_all' for cross-source joins. It also mentions pagination via limit/offset. It doesn't explicitly enumerate when not to use or compare with alternatives, but the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply aggregations, filters, renaming, or column selection to a source table and return or save results.
| Name | Required | Description | Default |
|---|---|---|---|
| table | Yes | Name of the table within the source to transform | |
| source | Yes | Name of the data source to transform | |
| operations | Yes | List of transform operations to apply in order | |
| output_format | No | Output format (default: json) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'return or save results', which implies a write operation, directly contradicting the annotation readOnlyHint=true. This is a serious inconsistency that could mislead an agent about the tool's side effects. The annotation's safety signal is undermined by the 'save' wording.
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 a single, concise sentence that front-loads the primary action and lists the operation types. Every word earns its place, with no filler or redundancy.
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 the core functionality and the schema fills in parameter details, but it lacks guidance on when to use this tool over 'query', how operations compose (though schema says 'in order'), and what 'save results' actually means. Without an output schema, the return value is only vaguely described. It is adequate but leaves notable 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 provides descriptions for all four parameters, achieving 100% coverage, so the baseline is 3. The description adds little beyond the schema: it lists operation types that are already enumerated in the schema (filter, aggregate, rename, select) and repeats 'save results' which is vague. No additional syntax or format details are given.
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 uses a specific verb 'apply' and a clear resource ('transformations to a source table'). It enumerates the operation types (aggregations, filters, renaming, column selection) and indicates the output behavior ('return or save results'), which distinguishes it from the sibling 'query' tool that likely handles raw retrieval.
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 transformation tasks but provides no explicit comparison to alternatives. It does not state when to use this tool versus 'query' or other siblings, nor does it mention any exclusions or prerequisites. The context is clear but under-specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct concern: connection registration, listing sources, tables, schemas, querying, transforming, and health checks. No two tools have overlapping purposes, making selection unambiguous.
All tool names follow an imperative verb pattern (connect_source, list_sources, list_tables, get_schema, check_health), with 'query' and 'transform' as clear single-verb actions. The convention is consistent and predictable.
Seven tools cover the core pipeline connector workflow without bloat. Each tool serves a distinct function and contributes to the overall purpose, making the count well-scoped.
The surface covers source registration, discovery, schema inspection, querying, transformation, and health monitoring. Minor gaps exist (no delete/update source), but the core lifecycle of connecting and exploring data is well covered.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Query, join, profile, clean and convert CSV/JSON/Parquet with server-side DuckDB over MCP.
MCP server for querying and analyzing data from ad platforms, analytics tools, and spreadsheets
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.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dbsectrainer/mcp-data-pipeline-connector'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
