Which integrations are available for this server?

Provides tools for querying and analyzing Apache Iceberg™ data lakehouses, including listing namespaces, tables, retrieving table schemas, properties, and partitions from AWS Glue catalogs. References GitHub for project repository hosting, licensing information, and contribution management. Distributes the IcebergMCP package through PyPI, allowing for installation via package managers.

How do I use IcebergMCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@IcebergMCP list all tables for the bronze namespace" 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.

IcebergMCP

by ryft-io

Overview Schema Source Related Servers Score Discussions Admin

Python

IcebergMCP 🚀

AI-native Lakehouse Integration

PyPI - Version License

IcebergMCP is a Model Context Protocol (MCP) server that lets you interact with your Apache Iceberg™ Lakehouse using natural language in Claude, Cursor, or any other MCP client.

Related MCP server: MCP Trino Server

Installation

Prerequisites

Apache Iceberg™ catalog managed in AWS Glue
AWS profile configured on the machine, with access to the catalog
uv package manager - install via brew install uv or see official installation guide

Claude

Inside Claude, go to Settings > Developer > Edit Config > claude_desktop_config.json
Add the following:

{
  "mcpServers": {
    "iceberg-mcp": {
      "command": "uv", // If uv can't be found, replace with full absolute path to uv
      "args": [
        "run",
        "--with",
        "iceberg-mcp",
        "iceberg-mcp"
      ],
      "env": {
        "ICEBERG_MCP_PROFILE": "<aws-profile-name>"
      }
    }
  }
}

Cursor

Inside Cursor, go to Settings -> Cursor Settings -> MCP -> Add new global MCP server
Add the following:

{
  "mcpServers": {
    "iceberg-mcp": {
      "command": "uv", // If uv can't be found, replace with full absolute path to uv
      "args": [
        "run",
        "--with",
        "iceberg-mcp",
        "iceberg-mcp"
      ],
      "env": {
        "ICEBERG_MCP_PROFILE": "<aws-profile-name>"
      }
    }
  }
}

Configuration

Environment variables can be used to configure the AWS connection:

ICEBERG_MCP_PROFILE - The AWS profile name to use. This role will be assumed and used to connect to the catalog and the object storage. If not specified, the default role will be used.
ICEBERG_MCP_REGION - The AWS region to use. This is used to determine the catalog and object storage location. us-east-1 by default.

Available Tools

The server provides the following tools for interacting with your Apache Iceberg™ tables:

get_namespaces: Gets all namespaces in the Apache Iceberg™ catalog
get_iceberg_tables: Gets all tables for a given namespace
get_table_schema: Returns the schema for a given table
get_table_properties: Returns table properties for a given table, like total size and record count
get_table_partitions: Gets all partitions for a given table

Examples

Once installed and configured, you can start interacting with your Apache Iceberg™ tables through your MCP client. Here are some simple examples of how to interact with your lakehouse:

"List all namespaces in my catalog"
"List all tables for the namespace called bronze"
"What are all the string columns in the table raw_events?
"What is the size of the raw_events table?"
"Generate an SQL query that calculates the sum and the p95 of all number columns in raw_metrics for all VIP users from users_info"
"Why did the queries on raw_events recently become much slower?"

Limitations & Security Considerations

All tools are currently read-only and cannot modify or delete data from your lakehouse
Currently supported catalogs:
- AWS Glue
- Apache Iceberg™ REST Catalog (coming soon!)

Contributing

Contributions are welcome! Please feel free to submit a Pull Request.

Available Tools

5 tools

get_iceberg_tablesC

Provides a list of iceberg tables from the Iceberg catalog for a given namespace

ParametersJSON Schema

Name	Required	Description	Default
`namespace`	Yes

TDQS

C2.9/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. It states the tool provides a list but doesn't disclose behavioral traits such as whether it's read-only, pagination behavior, error handling, or rate limits. The description is minimal and lacks essential operational context.

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 function without unnecessary words. It is appropriately sized and front-loaded, making it easy to grasp quickly.

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 lack of annotations and output schema, the description is incomplete. It doesn't cover behavioral aspects, return format, or error conditions. For a tool with one parameter but no schema descriptions, more context is needed to be fully helpful.

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 0%, but the description adds meaning by specifying that the namespace parameter is used to filter iceberg tables. However, it doesn't explain what a namespace is, its format, or examples, leaving gaps in understanding beyond the basic 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 action ('Provides a list') and resource ('iceberg tables from the Iceberg catalog'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like get_namespaces or get_table_schema, which would require a more specific scope comparison.

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 usage for listing tables in a namespace but provides no guidance on when to use this tool versus alternatives like get_namespaces or get_table_schema. There are no explicit when/when-not instructions or prerequisites mentioned.

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

get_namespacesB

Provides a list of namespaces from the Iceberg catalog.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/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. It states the tool provides a list, implying a read-only operation, but lacks details on permissions, rate limits, pagination, or error behavior. For a tool with zero annotation coverage, this is a significant gap in behavioral disclosure.

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 function without any wasted words. It is front-loaded with the core purpose, making it highly concise and well-structured.

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?

Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but minimal. It covers the basic purpose but lacks context about the Iceberg catalog, return format, or usage scenarios, leaving gaps for an agent to infer behavior.

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

Parameters4/5

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

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, earning a baseline score of 4 for not adding unnecessary information 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 verb ('Provides') and resource ('list of namespaces from the Iceberg catalog'), making the purpose understandable. It doesn't explicitly differentiate from sibling tools like 'get_iceberg_tables' or 'get_table_schema', but the resource specificity (namespaces vs tables/partitions/properties/schema) provides implicit distinction.

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 explicit guidance is provided on when to use this tool versus alternatives. The description implies it's for retrieving namespaces, but it doesn't mention prerequisites, context (e.g., before accessing tables), or comparisons to sibling tools like 'get_iceberg_tables' for related data.

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

get_table_partitionsC

Provides the partitions for a given Iceberg table

ParametersJSON Schema

Name	Required	Description	Default
`namespace`	Yes
`table_name`	Yes

TDQS

C2.8/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. It states 'provides the partitions' but doesn't specify what 'provides' entails—e.g., whether it returns a list, count, or detailed metadata of partitions, or if it has any side effects like caching. For a tool with zero annotation coverage, this is a significant gap in transparency about its operation and output.

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 any wasted words. It's appropriately sized for a simple tool and front-loaded with the key action and resource. Every part of the sentence earns its place by conveying essential information.

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 the tool (2 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what partitions are, why they're useful, or what the return value looks like (e.g., a list of partition keys or metadata). For a tool that likely returns structured data about table partitions, more context is needed to make it fully usable by an AI agent.

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

Parameters2/5

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

The schema description coverage is 0%, meaning the input schema provides no descriptions for the two parameters (namespace and table_name). The description adds no meaning beyond the schema—it doesn't explain what a 'namespace' or 'table_name' represents in the context of Iceberg tables, such as database or catalog names. Since the description doesn't compensate for the low schema coverage, it falls short of the baseline 3.

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 verb 'provides' and the resource 'partitions for a given Iceberg table', making the purpose specific and understandable. It distinguishes from siblings like 'get_table_schema' or 'get_table_properties' by focusing on partitions rather than other table metadata. However, it doesn't explicitly differentiate from all siblings (e.g., 'get_iceberg_tables' also deals with tables), so it's not a perfect 5.

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 like 'get_table_schema' or 'get_table_properties'. It mentions 'partitions' but doesn't explain why one would need partitions specifically, such as for query optimization or data management. There's no mention of prerequisites or exclusions, leaving usage context implied at best.

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

get_table_propertiesD

ParametersJSON Schema

Name	Required	Description	Default
`namespace`	Yes
`table_name`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_table_schemaC

Provides the schema for a given Iceberg table

ParametersJSON Schema

Name	Required	Description	Default
`namespace`	Yes
`table_name`	Yes

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden but only states what the tool does without behavioral details. It doesn't disclose if this is a read-only operation, potential error conditions, performance characteristics, or output format. For a tool with no annotation coverage, this is a significant gap in transparency.

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's appropriately sized for a simple retrieval tool and front-loads the essential information. Every word earns its place.

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 no annotations, 0% schema coverage, no output schema, and 2 parameters, the description is incomplete. It doesn't explain what the schema output looks like, how to interpret results, or provide any context about Iceberg table schemas. For a tool that presumably returns structured data, this leaves significant gaps.

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

Parameters2/5

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

Schema description coverage is 0%, meaning neither parameter has descriptions in the schema. The description adds no information about what 'namespace' or 'table_name' represent, their expected formats, or examples. With 2 undocumented parameters, the description fails to compensate for the schema's lack of documentation.

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 ('Provides') and resource ('schema for a given Iceberg table'), making the purpose understandable. It distinguishes from siblings like get_table_partitions or get_table_properties by focusing specifically on schema retrieval. However, it doesn't explicitly differentiate from get_iceberg_tables which might also provide schema information, keeping it from 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. It doesn't mention siblings like get_table_properties or get_table_partitions, nor does it specify prerequisites or contexts for usage. This leaves the agent without explicit direction on tool selection.

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.

5 tool updatesAug 15, 2025
- First observedget_iceberg_tables
- First observedget_namespaces
- First observedget_table_partitions
- First observedget_table_properties
- First observedget_table_schema

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

C2.7/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose targeting different aspects of Iceberg metadata: listing tables, listing namespaces, retrieving partitions, properties, and schema. There is no overlap in functionality, making tool selection straightforward for an agent.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with 'get_' prefix and descriptive suffixes (e.g., get_iceberg_tables, get_namespaces, get_table_partitions). The naming is uniform and predictable across all five tools.

Tool Count5/5

With 5 tools, this server is well-scoped for its purpose of retrieving Iceberg catalog metadata. Each tool serves a specific, non-trivial function, and the count is neither too sparse nor overwhelming for the domain.

Completeness3/5

The toolset covers read operations for Iceberg metadata (tables, namespaces, partitions, properties, schema) but lacks any write, update, or delete capabilities. While it provides a solid foundation for querying, it is incomplete for full lifecycle management of Iceberg resources.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

ContextfloOAuth
com.contextflo
Query your warehouse or a CSV with Claude/ChatGPT over MCP, governed by table-level ACL + audit.
Databases Security
1
mcpOAuth
com.gibsonai
GibsonAI MCP server: manage your databases with natural language
Databases Search
233
Artificial Wit AIOAuth
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2
ChrysaiOAuth
com.chrysai.www
Hosted MCP server for AI-driven data ops. Create apps, manage schemas, and CRUD structured data.
Data Platforms Developer Tools App Automation
2

Related MCP Servers

MCP Iceberg Catalog
Databases Search
ahodroj
F
license
B
quality
D
maintenance
A Model Context Protocol server that provides a SQL interface for querying and managing Apache Iceberg tables through Claude desktop, allowing natural language interaction with Iceberg data lakes.
Updated a year ago (2025-04-04 12:19 UTC)
1
8
-
MCP Trino Server
Databases Data Platforms
fastmcp-me
A
license
Not graded
quality
C
maintenance
MCP server providing seamless integration with Trino and Iceberg for advanced data exploration, querying, and table maintenance.
Updated a year ago (2025-10-13 22:05 UTC)
Apache 2.0
@lakehouse/mcp-server
RAG Systems Search Data Platforms
lakehouse-42
A
license
B
quality
D
maintenance
MCP server for Lakehouse42, enabling code-first tool discovery, hybrid search, document management, and Iceberg time-travel queries with optimized responses.
Updated 7 months ago (2026-02-04 19:56 UTC)
10
7
MIT
iceberg-mcp-server
Databases Data Platforms
dragonejt
A
license
Not graded
quality
A
maintenance
MCP Server for Apache Iceberg, enabling users to read, query, and manipulate data within Iceberg catalogs.
Updated 21 days ago (2026-08-18 21:24 UTC)
2
Apache 2.0

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/ryft-io/iceberg-mcp'

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

IcebergMCP 🚀

Table of Contents

Installation

Prerequisites

Claude

Cursor

Configuration

Available Tools

Examples

Limitations & Security Considerations

Contributing

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API