Apache Hive MCP Server
Allows an LLM agent to query Apache Hive through HiveServer2, including listing tables and running read-only SQL queries such as SELECT, SHOW, DESCRIBE, and WITH, with results returned as JSON.
Provides integration with Cloudera CDP Base and CDP Public Cloud (CDW) HiveServer2 endpoints, enabling read-only SQL queries and schema retrieval using LDAP, Kerberos, HTTP, and TLS configuration.
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., "@Apache Hive MCP ServerShow me the tables in the sales database"
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.
Apache Hive MCP Server
An MCP server for Apache Hive (HiveServer2), built with FastMCP. Connects to any HiveServer2-compatible endpoint — open-source Apache Hive, Cloudera CDP Base, or Cloudera CDP Public Cloud (CDW) — and exposes two read-only tools that an LLM agent can call.
Project summary
What it is — a Model Context Protocol server that lets an LLM agent query Apache Hive: list tables and run read-only SQL, with results returned as JSON.
Feature parity — mirrors Cloudera's Impala/Iceberg MCP server: same
execute_query+get_schematools and structure, with the connection layer swapped to HiveServer2 viaimpyla.Works everywhere HiveServer2 does — open-source Apache Hive, CDP Base (Kerberos/LDAP), and CDP Public Cloud / CDW (Knox, LDAP over HTTPS). Auth, transport, and TLS are all driven by
HIVE_*environment variables.Safe by default —
execute_queryenforces a read-only prefix guard (SELECT/SHOW/DESCRIBE/WITH); write/DDL statements are rejected before a connection is opened.Transport —
stdio(default),http, orsse, selected viaMCP_TRANSPORT.Tech stack — Python ≥3.10, FastMCP,
impyla,uv. 11 unit tests (connection mocked — no live Hive required).
Related MCP server: Hue MCP Server
Tools
Tool | Signature | Description |
|
| Execute a read-only SQL query (SELECT, SHOW, DESCRIBE, WITH) and return results as a JSON array of column-keyed objects. Write operations are rejected with an error string. |
|
| Run |
Configuration
All configuration is via environment variables (or a .env file at the project root).
Variable | Default | Description |
|
| HiveServer2 hostname or IP |
|
| HiveServer2 thrift port |
|
| Database to connect to |
| (empty) | Username (leave empty for NOSASL/Kerberos) |
| (empty) | Password (used with PLAIN/LDAP) |
|
| Auth method: |
|
| Use HTTP transport instead of binary thrift |
|
| HTTP path when |
|
| Enable TLS for the thrift connection |
|
| Kerberos service principal name (GSSAPI only) |
|
| MCP transport: |
Copy .env.example to .env and fill in your values.
Deployment presets
Local / development (Docker HiveServer2)
HIVE_HOST=localhost
HIVE_PORT=10000
HIVE_DATABASE=default
HIVE_AUTH_MECHANISM=NOSASL
MCP_TRANSPORT=stdioCDP Public Cloud (CDW Virtual Warehouse)
HIVE_HOST=<coordinator-hostname>.dw.cloudera.site
HIVE_PORT=443
HIVE_DATABASE=default
HIVE_USER=<workload-username>
HIVE_PASSWORD=<workload-password>
HIVE_AUTH_MECHANISM=LDAP
HIVE_USE_HTTP_TRANSPORT=true
HIVE_HTTP_PATH=cliservice
HIVE_USE_SSL=true
MCP_TRANSPORT=stdioCDP Base / on-premises with Kerberos
HIVE_HOST=<hiveserver2-host.example.com>
HIVE_PORT=10000
HIVE_DATABASE=default
HIVE_AUTH_MECHANISM=GSSAPI
HIVE_KERBEROS_SERVICE_NAME=hive
MCP_TRANSPORT=stdioObtain a Kerberos ticket (
kinit) before starting the server.
Running
# Install
pip install -e .
# or with uv:
uv sync
# Copy and edit config
cp .env.example .env
# Start (stdio transport, for use with an MCP host)
uv run hive-mcp-serverMCP client configuration
MCP hosts (Claude Desktop, Cloudera AI Agent Studio, etc.) register servers with
a mcpServers JSON block. uvx runs this server straight from GitHub — no
local install or PyPI publish required. Fill in the HIVE_* values for your
environment (see Configuration and the presets above).
{
"mcpServers": {
"Hive": {
"command": "uvx",
"args": [
"--from",
"git+https://github.com/avelloal/hive-mcp-server@v0.1.0",
"hive-mcp-server"
],
"env": {
"HIVE_HOST": "<coordinator-hostname>.dw.cloudera.site",
"HIVE_PORT": "443",
"HIVE_DATABASE": "default",
"HIVE_USER": "<workload-username>",
"HIVE_PASSWORD": "<workload-password>",
"HIVE_AUTH_MECHANISM": "LDAP",
"HIVE_USE_HTTP_TRANSPORT": "true",
"HIVE_HTTP_PATH": "cliservice",
"HIVE_USE_SSL": "true"
}
}
}
}The example above targets CDP Public Cloud / CDW. For local or Kerberos
targets, swap the env values using the presets above.
@v0.1.0 pins a fixed release — drop it to track the latest, or bump it for a
newer version.
For Cloudera AI Agent Studio specifically (registration steps, env-var
handling, stdio/uvx limitations), see
examples/agent-studio/.
Smoke test
Start a local HiveServer2 (e.g., Apache Hive Docker image):
docker run -d -p 10000:10000 apache/hive:3.1.3Configure
.envwith the local preset above.Start the server:
uv run hive-mcp-serverIn a second terminal, use the
fastmcpdev inspector or any MCP client to call both tools:get_schema()— should return[]or a list of table names.execute_query("SHOW DATABASES")— should return a JSON array of databases.
License
Apache License 2.0 — see LICENSE.
Available Tools
2 toolsexecute_queryA
Execute a read-only SQL query on Hive and return results as JSON.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It usefully discloses that the tool is read-only and returns JSON, which are meaningful safety and output traits. However, it doesn't explain error behavior, query size limits, permission expectations, or how results are shaped.
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?
A single sentence that front-loads the action, target, and output format. There is no wasted or redundant phrasing; every clause adds 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?
For a single-parameter tool with an output schema present, the description covers the essential usage context: the action, the data source, the read-only safety property, and the return format. It could add routing to get_schema, but the core invocation context is adequate.
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 description coverage is 0%, so the description must carry parameter semantics. 'SQL query on Hive' clarifies that the query parameter should be a Hive SQL string, which adds meaning beyond the schema's bare 'query' field. But the description never mentions the parameter by name or provides syntax, limits, or examples.
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 states a specific verb ('Execute') and resource ('SQL query on Hive'), and also names the output format ('results as JSON'). It clearly distinguishes this tool from the sibling get_schema, which is about schema retrieval rather than running queries.
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?
There is no explicit guidance about when to use this tool versus get_schema, or when not to use it. The 'read-only' qualifier is a constraint, but it doesn't describe alternatives or usage scenarios beyond what the description literally states.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_schemaA
List the table names in the current Hive database.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It communicates a read-only, list-style behavior and the scope to the current Hive database, but it does not mention return format, potential limitations, or side effects. For such a simple zero-parameter read operation, this is adequate but not richly transparent.
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?
A single-front-loaded sentence communicates the core action and target resource with no superfluous words. Every part of the description adds value.
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 has no parameters and an output schema is provided, so the description only needs to specify what is listed and in what context. The single sentence fully covers that for a minimal introspection operation.
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 parameter count is 0, so there is no semantic burden on the description. The description accurately describes what the tool will produce, and no parameter-related information is required beyond the schema's empty object.
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'), identifies the exact resource ('table names'), and scopes it to the 'current Hive database.' This clearly distinguishes it from the sibling tool execute_query, which focuses on running queries rather than returning 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 makes the tool's purpose obvious: use it when you need the list of table names in the current Hive database. However, it does not explicitly contrast this with execute_query or state when to prefer one over the other, leaving the routing decision somewhat implied.
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.
2 tool updates
v0.1.0- First observed
execute_query - First observed
get_schema
TDQS
The two tools have clearly distinct purposes: one executes SQL queries, the other lists table names. There is no overlap or ambiguity between them.
Both tool names follow a consistent snake_case verb_noun pattern: execute_query and get_schema. The naming is predictable and easy to extend.
Two tools is on the thin side for a full Apache Hive server, though the set is minimal and comprehensible. It feels borderline but not absurdly incomplete.
The set covers basic querying and table listing, but lacks explicit schema/column detail, database selection, and non-query operations. An agent can partially work around this via execute_query, but there are notable gaps.
Maintenance
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
Safe, read-only Postgres and MySQL access for AI agents. Audit log + column-level controls.
Query your org's data in natural language — read-only MCP access to SQL, NoSQL, files & warehouses.
- OleanderOAuthdev.oleander
The all-in-one data stack for agents. Upload files, run SQL, evolve tables, and render charts.
Explore, query, and inspect SQLite databases with ease. List tables, preview results, and view det…
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceProvides read-only access to Iceberg tables via Apache Impala, enabling LLMs to inspect database schemas and execute SQL queries on Iceberg data.Apache 2.0
- AlicenseAqualityDmaintenanceEnables AI assistants to interact with Hadoop Hue for executing SQL queries using Hive, SparkSQL, or Impala and managing HDFS files. It supports directory browsing, file transfers, and exporting query results to CSV through the Model Context Protocol.81MIT
- AlicenseAqualityDmaintenanceEnables AI agents to execute SQL queries and explore Snowflake databases using natural language, with schema discovery, table inspection, and readonly mode.11679MIT
- FlicenseAqualityCmaintenanceEnables LLM agents to query and explore Cloudera Hive virtual warehouses through tools like list_databases, list_tables, describe_table, get_table_sample, and execute_query with read-only safety.5-
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/avelloal/hive-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server