Skip to main content
Glama
enesjakozh
ahodroj

MCP Iceberg Catalog

by ahodroj
OverviewSchemaRelated ServersScoreDiscussions
Python
Hybrid

MCP Iceberg Catalog

A MCP (Model Context Protocol) server implementation for interacting with Apache Iceberg. This server provides a SQL interface for querying and managing Iceberg tables through Claude desktop.

Claude Desktop as your Iceberg Data Lake Catalog

image

Related MCP server: Databricks MCP Server

How to Install in Claude Desktop

Installing via Smithery

To install MCP Iceberg Catalog for Claude Desktop automatically via Smithery:

npx -y @smithery/cli install @ahodroj/mcp-iceberg-service --client claude

  1. Prerequisites

    • Python 3.10 or higher

    • UV package installer (recommended) or pip

    • Access to an Iceberg REST catalog and S3-compatible storage

  2. How to install in Claude Desktop Add the following configuration to claude_desktop_config.json:

{
  "mcpServers": {
    "iceberg": {
      "command": "uv",
      "args": [
        "--directory",
        "PATH_TO_/mcp-iceberg-service",
        "run",
        "mcp-server-iceberg"
      ],
      "env": {
        "ICEBERG_CATALOG_URI" : "http://localhost:8181",
        "ICEBERG_WAREHOUSE" : "YOUR ICEBERG WAREHOUSE NAME",
        "S3_ENDPOINT" : "OPTIONAL IF USING S3",
        "AWS_ACCESS_KEY_ID" : "YOUR S3 ACCESS KEY",
        "AWS_SECRET_ACCESS_KEY" : "YOUR S3 SECRET KEY"
      }
    }
  }
}

Design

Architecture

The MCP server is built on three main components:

  1. MCP Protocol Handler

    • Implements the Model Context Protocol for communication with Claude

    • Handles request/response cycles through stdio

    • Manages server lifecycle and initialization

  2. Query Processor

    • Parses SQL queries using sqlparse

    • Supports operations:

      • LIST TABLES

      • DESCRIBE TABLE

      • SELECT

      • INSERT

  3. Iceberg Integration

    • Uses pyiceberg for table operations

    • Integrates with PyArrow for efficient data handling

    • Manages catalog connections and table operations

PyIceberg Integration

The server utilizes PyIceberg in several ways:

  1. Catalog Management

    • Connects to REST catalogs

    • Manages table metadata

    • Handles namespace operations

  2. Data Operations

    • Converts between PyIceberg and PyArrow types

    • Handles data insertion through PyArrow tables

    • Manages table schemas and field types

  3. Query Execution

    • Translates SQL to PyIceberg operations

    • Handles data scanning and filtering

    • Manages result set conversion

Further Implementation Needed

  1. Query Operations

    • Implement UPDATE operations

    • Add DELETE support

    • Support for CREATE TABLE with schema definition

    • Add ALTER TABLE operations

    • Implement table partitioning support

  2. Data Types

    • Support for complex types (arrays, maps, structs)

    • Add timestamp with timezone handling

    • Support for decimal types

    • Add nested field support

  3. Performance Improvements

    • Implement batch inserts

    • Add query optimization

    • Support for parallel scans

    • Add caching layer for frequently accessed data

  4. Security Features

    • Add authentication mechanisms

    • Implement role-based access control

    • Add row-level security

    • Support for encrypted connections

  5. Monitoring and Management

    • Add metrics collection

    • Implement query logging

    • Add performance monitoring

    • Support for table maintenance operations

  6. Error Handling

    • Improve error messages

    • Add retry mechanisms for transient failures

    • Implement transaction support

    • Add data validation

Available Tools

1 tool
execute_queryC

Execute a query on Iceberg tables

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesQuery to execute (supports: LIST TABLES, DESCRIBE TABLE, SELECT, CREATE TABLE)

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure but offers minimal information. It mentions the query types supported (LIST TABLES, DESCRIBE TABLE, SELECT, CREATE TABLE), which adds some context, but fails to address critical aspects like permissions needed, whether it's read-only or mutating, error handling, or output format expectations.

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, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to understand at a glance.

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

Completeness2/5

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

Given the complexity of a query execution tool with no annotations and no output schema, the description is insufficient. It lacks details on behavioral traits, error handling, permissions, or what to expect from results, leaving significant gaps for an AI agent to operate effectively.

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 has 100% description coverage, explicitly documenting the 'query' parameter with supported query types. The description does not add any additional semantic details beyond what the schema already provides, so it meets the baseline for adequate but unremarkable 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 clearly states the action ('Execute a query') and target resource ('on Iceberg tables'), providing a specific verb+resource combination. However, with no sibling tools mentioned, it cannot demonstrate differentiation from alternatives, so it falls short of a perfect score.

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 provides no guidance on when to use this tool versus alternatives, prerequisites, or contextual constraints. It merely states what the tool does without indicating appropriate scenarios or limitations.

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. Dates show when Glama detected each change.

  1. 1 tool updatev1.0.0
    • First observedexecute_query
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3/5.0
Disambiguation5/5

With only one tool, there is no possibility of ambiguity or overlap between tools, as there are no other tools to confuse it with. The tool's purpose is clearly defined and distinct by default.

Naming Consistency5/5

Since there is only one tool, naming consistency is inherently perfect with no deviations or mixed conventions to evaluate. The tool name follows a clear verb_noun pattern (execute_query).

Tool Count2/5

A single tool is too few for a catalog server, which typically requires operations like list_tables, get_table, create_table, or update_metadata to be useful. This minimal set severely limits functionality and scope.

Completeness1/5

The tool set is severely incomplete for an Iceberg catalog domain, lacking basic CRUD operations such as listing, creating, or managing tables. With only a query execution tool, agents cannot perform essential catalog tasks, leading to dead ends.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • MCP Snowflake Service

    datawiz168
    A
    license
    Not graded
    quality
    D
    maintenance
    A Model Context Protocol server that enables Claude to execute SQL queries on Snowflake databases with automatic connection lifecycle management.
    45
    MIT

  • IcebergMCP

    ryft-io
    A
    license
    C
    quality
    D
    maintenance
    An MCP server that enables natural language interaction with Apache Iceberg data lakehouses, allowing users to query table metadata, schemas, and properties through Claude, Cursor, or other MCP clients.
    5
    41
    Apache 2.0

  • MCP Trino Server

    alaturqua
    A
    license
    B
    quality
    C
    maintenance
    A Model Context Protocol server that provides seamless integration with Trino and Iceberg, enabling data exploration, querying, and table maintenance through a standard interface.
    22
    25
    Apache 2.0

Appeared in Searches

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ahodroj/mcp-iceberg-service'

If you have feedback or need assistance with the MCP directory API, please join our Discord server