Skip to main content
Glama
guillaume-galp

dremio-mcp-lite

by guillaume-galp
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

dremio-mcp-lite

A TypeScript MCP (Model Context Protocol) server for Dremio data exploration. This tool enables AI assistants to interact with Dremio through a set of read-only operations.

Features

  • Fast Startup: Optimized for <1s startup time for VS Code stdio MCP

  • Read-Only Operations: Safe exploration of your Dremio data catalog

  • 6 Core Tools:

    • catalog_browse: List sources, spaces, folders, and tables

    • schema_get: Get table schemas

    • sql_query: Execute SELECT queries (max 1000 rows)

    • table_preview: Preview first 10 rows of a table

    • search_catalog: Find tables by name

    • explain_query: Get query execution plans

Related MCP server: iceberg-mcp-server

Installation

npm install @guillaume-galp/dremio-mcp-lite

Configuration

Create a .env file in your project root:

DREMIO_URL=http://localhost:9047
DREMIO_PAT=your_personal_access_token_here

# SSL Configuration (optional)
# Set to 'false' to disable SSL certificate verification for self-signed certificates
# WARNING: Only use in development/testing environments
DREMIO_REJECT_UNAUTHORIZED=true

Or copy from the example:

cp .env.example .env

SSL Certificate Configuration

When connecting to Dremio instances with self-signed SSL certificates (common in internal/corporate environments), you may encounter certificate verification errors. To disable SSL certificate verification:

  1. Set DREMIO_REJECT_UNAUTHORIZED=false in your .env file

  2. Important: Only use this setting in development or testing environments

  3. Never disable certificate verification in production environments

Example for self-signed certificates:

DREMIO_URL=https://dremio.internal.company.com:9047
DREMIO_PAT=your_personal_access_token_here
DREMIO_REJECT_UNAUTHORIZED=false

Getting a Dremio Personal Access Token

  1. Log in to your Dremio instance

  2. Go to Settings → Personal Access Tokens

  3. Click "Create Token"

  4. Copy the token and add it to your .env file

Usage

As an MCP Server

Add to your MCP client configuration (e.g., VS Code mcp.json):

{
  "mcpServers": {
    "dremio": {
      "type": "stdio",
      "command": "npx",
      "args": [
        "-y",
        "@guillaume-galp/dremio-mcp-lite"
      ],
      "envFile": "${userHome}/.dremio-mcp.env",
      "gallery": true
    }
  }
}

Configuration Notes:

  • type: Must be "stdio" for standard input/output communication

  • -y: Auto-confirms npx package installation

  • envFile: Path to your environment file containing DREMIO_URL and DREMIO_PAT

    • Recommended: Use ${userHome} variable: "${userHome}/.dremio-mcp.env"

    • Windows absolute path: "C:\\Users\\<YourUsername>\\.dremio-mcp.env"

    • macOS/Linux absolute path: "/Users/<YourUsername>/.dremio-mcp.env" or "/home/<YourUsername>/.dremio-mcp.env"

    • Replace <YourUsername> with your actual username

  • gallery: Optional, set to true to show in MCP gallery

Or if installed globally:

{
  "mcpServers": {
    "dremio": {
      "type": "stdio",
      "command": "dremio-mcp-lite",
      "envFile": "${userHome}/.dremio-mcp.env",
      "gallery": true
    }
  }
}

Available Tools

catalog_browse

Browse the Dremio catalog structure.

// List all sources
catalog_browse()

// Browse a specific path
catalog_browse({ path: ["source_name", "folder"] })

schema_get

Get the schema definition of a table.

schema_get({ table_path: ["source", "schema", "table"] })

sql_query

Execute SELECT queries (read-only).

sql_query({
  sql: "SELECT * FROM source.schema.table WHERE id > 100",
  max_rows: 500  // Optional, default 1000
})

table_preview

Quick preview of table data (first 10 rows).

table_preview({ table_path: ["source", "schema", "table"] })

search_catalog

Search for tables and datasets by name.

search_catalog({ search_term: "customer" })

explain_query

Get the execution plan for a query.

explain_query({ sql: "SELECT * FROM source.schema.table" })

Security

This MCP server implements several security measures:

  • Read-Only Operations: Only SELECT queries are allowed. All modifications (INSERT, UPDATE, DELETE, etc.) are blocked.

  • SQL Injection Protection: Table paths are properly escaped using SQL identifier quoting to prevent injection attacks.

  • Query Validation: SQL queries are validated to ensure they are SELECT statements, even when prefixed with comments or whitespace.

  • Personal Access Tokens: Uses Dremio PAT authentication stored securely in .env file (never commit .env to version control).

Development

Build

npm run build

Run Locally

npm start

Publishing to npm

The package is automatically published to npm when a version tag is pushed:

  1. Update the version in package.json:

    npm version patch  # or minor, or major

  2. Push the tag to GitHub:

    git push origin master --tags

    Or if using the main branch:

    git push origin main --tags

  3. The GitHub Actions workflow will automatically build and publish to npm

Prerequisites:

  • NPM_TOKEN must be configured in GitHub repository secrets

  • The token must have publish access to the @guillaume-galp scope on npmjs.org

Requirements

  • Node.js >= 18

  • Access to a Dremio instance (default port: 9047)

  • Valid Dremio Personal Access Token

License

MIT

Available Tools

6 tools
catalog_browseB

Browse Dremio catalog to list sources, spaces, folders, and tables. Optionally provide a path to browse a specific location.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathNoOptional path array to browse (e.g., ["source_name", "folder_name"])

TDQS

B3.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the burden of disclosing behavior. It communicates that this is a read-only browsing operation and that an optional path narrows the location. It does not mention output format, pagination, error behavior, or what happens when no path is given.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that states the operation, the resource, and the optional parameter. It is front-loaded and contains no filler or redundant information.

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

Completeness3/5

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

For a simple tool with one optional parameter, the description provides enough to invoke it, but the lack of annotations and output schema means more context would help. It does not describe what a successful response looks like, how deep browsing works, or the behavior at the root catalog level.

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

Parameters3/5

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

The schema already documents the path parameter with full coverage and a helpful description. The tool description adds only that the path lets you browse a specific location, which is consistent but does not significantly extend the semantic meaning beyond the schema.

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

Purpose4/5

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

The description clearly states the tool browses the Dremio catalog and lists sources, spaces, folders, and tables. It uses a specific verb and resource, making the core purpose understandable. However, it does not explicitly distinguish itself from sibling tools like search_catalog.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies browsing by path but provides no guidance on when to use this tool versus alternatives such as search_catalog or table_preview. There are no explicit when-to-use or when-not-to-use instructions.

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

explain_queryB

Get the execution plan for a SQL query

ParametersJSON Schema
NameRequiredDescriptionDefault
sqlYesThe SQL query to explain

TDQS

B3.3/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. The description does not state whether the query is executed, whether EXPLAIN ANALYZE behavior is included, what side effects may occur, or what the returned execution plan contains. For a database tool, this leaves important behavioral ambiguity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler. Every word contributes to conveying the tool's purpose.

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

Completeness3/5

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

The tool is simple with one parameter and no output schema, so the description covers the basic call. However, the absence of annotations and lack of detail about the execution plan's nature or the behavior of the EXPLAIN operation leaves some context gaps for an agent that needs to interpret results correctly.

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

Parameters3/5

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

The input schema covers the single 'sql' parameter with a direct description, and schema description coverage is 100%, so the baseline is 3. The description adds no extra semantic detail about supported SQL syntax, limits, or formatting beyond the schema.

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

Purpose4/5

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

The description clearly identifies the action ('Get') and resource ('execution plan for a SQL query'), which distinguishes it from the sibling sql_query tool that likely executes the query and returns rows. It does not explicitly name the distinction from siblings, so it misses a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool should be used when the agent needs an execution plan rather than query results, but it does not explicitly state when to use this tool versus sql_query or other siblings. There are no exclusions or alternative suggestions, so usage guidance is only implicit.

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

schema_getA

Get the schema of a specific table in Dremio

ParametersJSON Schema
NameRequiredDescriptionDefault
table_pathYesFull path to the table as an array (e.g., ["source_name", "schema", "table_name"])

TDQS

A3.5/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the behavioral burden. 'Get' implies a read-only operation, which is a useful cue, but the description does not disclose return format, error behavior, or Dremio-specific requirements. It is adequate but incomplete.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single front-loaded sentence with no filler. Every word contributes to stating the action, object, and scope.

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

Completeness3/5

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

For a one-parameter metadata getter with no output schema, the input side is fully covered. However, the description leaves the return value format unstated and provides no usage context or alternative routing, making it minimally adequate rather than complete.

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

Parameters3/5

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

Schema description coverage is 100%, and the schema fully documents table_path with a concrete example. The description adds no additional semantic detail beyond calling the table 'specific,' so the schema does the heavy lifting.

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

Purpose5/5

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

The description states a specific action ('Get') and a specific resource ('schema of a specific table in Dremio'). This clearly differentiates it from siblings like catalog_browse, table_preview, and sql_query, even though no sibling is explicitly named.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no guidance on when to use this tool versus alternatives. There are no exclusions, prerequisites, or conditions such as 'use this when you need table metadata' or 'for data rows use table_preview instead.'

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

search_catalogC

Search for tables and datasets in the Dremio catalog by name

ParametersJSON Schema
NameRequiredDescriptionDefault
search_termYesSearch term to find tables/datasets by name

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description must carry the full behavioral disclosure burden. It does not explicitly say the operation is read-only, how matching behaves (case sensitivity, wildcards, partial matches), whether results are paginated or limited, or what the return payload looks like. The phrase 'by name' is the only behavioral detail provided.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence with no waste or repetition. The core purpose is front-loaded, but it is also quite terse and lacks additional useful structure or context.

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

Completeness3/5

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

For a one-parameter read-style search tool, the description plus schema are minimally suficient to understand how to call it. However, there is no output schema and no description of return values or scope, and there is no guidance on how it relates to sibling tools, leaving some contextual gaps.

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

Parameters3/5

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

Schema description coverage is 100%, and the parameter description already conveys that search_term is used to find tables/datasets by name. The tool description merely restates 'by name' and adds no extra meaning such as accepted formats, examples, wildcard support, or length constraints, so the baseline score of 3 applies.

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

Purpose4/5

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

The description states a clear verb ('Search'), a specific resource ('tables and datasets in the Dremio catalog'), and a qualifier ('by name'). It is not a tautology and gives an agent a good sense of the tool's purpose, though it does not explicitly differentiate it from sibling tools like catalog_browse.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided about when to use this tool versus alternatives such as catalog_browse, sql_query, or schema_get. There are no exclusions, prerequisites, or conditions stated; the only implied context is that the agent is looking for catalog entries by name.

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

sql_queryA

Execute a SELECT query on Dremio. Returns up to 1000 rows. Read-only queries only.

ParametersJSON Schema
NameRequiredDescriptionDefault
sqlYesThe SELECT SQL query to execute
max_rowsNoMaximum number of rows to return (default: 1000, max: 1000)

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the behavioral burden. It clearly discloses the read-only nature ('Read-only queries only') and the row limit ('Returns up to 1000 rows'), which are the most important behavioral traits for safe invocation. It does not cover error behavior or output format, but the key usage boundary is explicit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The entire description is two short sentences. The main action and resource are first, followed by the row cap and safety constraint, with no filler or repetition.

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

Completeness4/5

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

For a simple two-parameter query tool, the description covers the core contract: what it executes, the read-only constraint, and the row limit. It could mention result shape or how to handle errors, but nothing necessary for selecting or invoking the tool is missing; the schema supplies parameter details.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents the sql and max_rows parameters. The description reinforces that the query must be a SELECT and that results cap at 1000 rows, but it adds no new semantic details beyond what the schema states.

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

Purpose5/5

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

The description opens with 'Execute a SELECT query on Dremio', identifying a concrete verb, target system, and query type. It also adds the limit 'Returns up to 1000 rows' and the constraint 'Read-only queries only', making it easy to distinguish from sibling tools like explain_query or table_preview.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies this tool is for ad-hoc read-only SQL SELECTs, but it never explicitly names alternatives or states when NOT to use it versus table_preview, search_catalog, or explain_query. An agent must infer the appropriate context from the tool name and the sibling list.

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

table_previewB

Preview the first 10 rows of a table

ParametersJSON Schema
NameRequiredDescriptionDefault
table_pathYesFull path to the table as an array (e.g., ["source_name", "schema", "table_name"])

TDQS

B3.4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral burden. It discloses the key constraint 'first 10 rows', which implies a read-only, bounded operation, but it does not mention side effects, ordering, failure behavior, or what happens with missing tables.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler or redundant details. Every word contributes to the meaning.

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

Completeness4/5

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

For a single-parameter preview tool, the description is largely sufficient: it names the resource and the row limit. The lack of an output schema and any mention of return format is a minor gap, but the tool is simple enough that the description remains usable.

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

Parameters3/5

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

The schema already provides a complete description of table_path with an example. The tool description adds no parameter-level meaning beyond that, so it meets the baseline for full schema coverage.

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

Purpose4/5

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

The description states a specific verb ('Preview') and resource ('the first 10 rows of a table'), which is clear and actionable. It differentiates from siblings by emphasizing a bounded preview rather than full querying, though it does not explicitly name any alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus alternatives like sql_query or catalog_browse. The description implies a lightweight look at data, but it does not provide conditions, exclusions, or comparisons.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 6 tool updatesv0.1.9
    • First observedcatalog_browse
    • First observedexplain_query
    • First observedschema_get
    • First observedsearch_catalog
    • First observedsql_query
    • First observedtable_preview
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.6/5.0

Scored across 6 tools

Disambiguation5/5

Each tool targets a clearly distinct operation: catalog browsing, schema retrieval, arbitrary SQL, quick preview, catalog search, and query explanation. The only potentially overlapping pair is catalog_browse and search_catalog, but one navigates the hierarchy while the other searches by name, so they are easy to distinguish.

Naming Consistency3/5

The naming is readable and consistently uses snake_case, but the verb placement is mixed: object-verb forms like catalog_browse, schema_get, and table_preview sit alongside verb-object forms like search_catalog and explain_query, and sql_query has no verb at all. This is not chaotic, but it does not follow a single predictable pattern.

Tool Count5/5

Six tools is well-scoped for a read-only Dremio exploration and querying server. Each tool serves a distinct purpose without redundancy, and the count is comfortably within the ideal range.

Completeness5/5

The tool set covers the full read-only workflow: discovering data via browse/search, inspecting structure via schema, peeking at data via preview, running arbitrary queries, and understanding performance via explain. No obvious dead ends or missing essential operations exist for the stated purpose.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • iceberg-mcp-server

    dragonejt
    A
    license
    Not graded
    quality
    A
    maintenance
    MCP Server for Apache Iceberg, enabling users to read, query, and manipulate data within Iceberg catalogs.
    153 PyPI
    2
    Apache 2.0

  • sql-explorer-mcp

    timsuv
    F
    license
    A
    quality
    C
    maintenance
    A read-only MCP server for browsing and querying SQL Server databases, providing tools to list schemas, tables, describe columns, and execute safe SELECT queries with validated parameters.
    15
    -

  • Oracle MCP Server

    AlexandruDodita
    F
    license
    Not graded
    quality
    C
    maintenance
    A read-only MCP server for exploring and querying Oracle schemas safely. Provides tools for table listing, schema description, column search, and validated SELECT execution.
    2
    -