How do I use Hue MCP Server?

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., "@Hue MCP Server Run a Hive query to count the total records in the sales table" 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.

Hue MCP Server

by SpanishST

Overview Schema Related Servers Score Discussions

Python

Remote

Hue MCP Server

An MCP (Model Context Protocol) server that exposes HueClientRest functionality, allowing AI assistants to interact with Hadoop Hue for executing SQL queries and managing HDFS files.

What is This?

This server enables AI assistants (like GitHub Copilot, Claude Desktop, or other MCP-compatible clients) to:

Execute SQL queries on Hadoop Hue using Hive, SparkSQL, or Impala
Manage HDFS files (list, upload, download)
Export query results to CSV files
Browse and manage directory structures

The Model Context Protocol (MCP) is an open standard for connecting AI assistants to external tools and data sources, making them more powerful and context-aware.

Related MCP server: MSSQL MCP Server

Features

SQL Query Execution: Execute queries using Hive, SparkSQL, or Impala dialects
Result Export: Save query results to CSV files with automatic retry on large datasets
HDFS Operations: List, upload, and download files from HDFS
Directory Management: Check directory existence and browse file structures
Robust Error Handling: Built-in retry mechanisms and detailed error reporting

Prerequisites

Before installing this MCP server, you need:

Python 3.10 or higher - Download Python
Astral uv - Fast Python package installer and environment manager
Visual Studio Code - For MCP integration with GitHub Copilot
GitHub Copilot subscription - Required for VS Code MCP integration
Access to a Hadoop Hue server - You'll need the host URL, username, and password

Dependencies

This project uses the following key dependencies:

Astral uv - An extremely fast Python package and project manager, written in Rust. It's 10-100x faster than pip and handles dependency resolution much better.
mcp[cli] - The official Python SDK for the Model Context Protocol, including CLI tools
hueclientrest - Python client library for interacting with Hadoop Hue REST API
pydantic - Data validation using Python type annotations

Installation

Step 1: Install Astral uv

uv is a modern, fast Python package manager that we use for dependency management.

On Windows (PowerShell):

powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

On macOS/Linux:

curl -LsSf https://astral.sh/uv/install.sh | sh

After installation, restart your terminal or add uv to your PATH as instructed by the installer.

Verify installation:

uv --version

Step 2: Clone and Install the Project

# Clone the repository
git clone <your-repo-url>
cd hueclientrest-mpc

# Install dependencies and create virtual environment
uv sync

The uv sync command will:

Create a virtual environment (.venv)
Install all dependencies from pyproject.toml
Set up the project for development

Alternative: Using pip

If you prefer pip over uv:

pip install -e .

However, uv is strongly recommended for better performance and dependency management.

Configuration

Environment Variables

The server requires the following environment variables to connect to your Hue server:

Variable	Required	Description
`HUE_HOST`	Yes	Hue server URL (e.g., `https://hue.example.com`)
`HUE_USERNAME`	Yes	Username for Hue authentication
`HUE_PASSWORD`	Yes	Password for Hue authentication
`HUE_VERIFY_SSL`	No	Verify SSL certificates (default: `true`)
`HUE_SSL_WARNINGS`	No	Show SSL warnings (default: `false`)

Setting Up Environment Variables

Option 1: Using .env file (Recommended for local development)

# Create a .env file in the project root
HUE_HOST=https://your-hue-server.com
HUE_USERNAME=your_username
HUE_PASSWORD=your_password
HUE_VERIFY_SSL=true
HUE_SSL_WARNINGS=false

Option 2: System environment variables

On Windows (PowerShell):

$env:HUE_HOST="https://your-hue-server.com"
$env:HUE_USERNAME="your_username"
$env:HUE_PASSWORD="your_password"

On macOS/Linux:

export HUE_HOST="https://your-hue-server.com"
export HUE_USERNAME="your_username"
export HUE_PASSWORD="your_password"

VS Code Integration with GitHub Copilot

Prerequisites for VS Code Integration

Visual Studio Code - Download VS Code
GitHub Copilot extension - Install from VS Code marketplace
GitHub Copilot subscription - Required for MCP support
This MCP server installed and configured

Step 1: Locate Your MCP Configuration File

The MCP configuration file location depends on your operating system:

Windows: %APPDATA%\Code\User\mcp.json
- Full path: C:\Users\<YourUsername>\AppData\Roaming\Code\User\mcp.json
macOS: ~/Library/Application Support/Code/User/mcp.json
Linux: ~/.config/Code/User/mcp.json

If the file doesn't exist, create it.

Step 2: Configure the MCP Server in VS Code

Add the following configuration to your mcp.json file:

{
  "mcpServers": {
    "hue": {
      "command": "uv",
      "args": [
        "run",
        "--directory",
        "C:\\Projects\\hueclientrest-mpc",
        "hue-mcp-server"
      ],
      "env": {
        "HUE_HOST": "https://your-hue-server.com",
        "HUE_USERNAME": "your_username",
        "HUE_PASSWORD": "your_password",
        "HUE_VERIFY_SSL": "true",
        "HUE_SSL_WARNINGS": "false"
      }
    }
  }
}

Important Notes:

Replace C:\\Projects\\hueclientrest-mpc with the actual path to your project
On Windows, use double backslashes (\\) or forward slashes (/) in paths
Replace the environment variable values with your actual Hue credentials
The command is uv which will use the uv package manager to run the server

Step 3: Verify the Configuration

Restart VS Code completely (close all windows)
Open GitHub Copilot Chat (Ctrl+Shift+I or Cmd+Shift+I)
Check for the Hue MCP tools: Type @workspace and look for Hue-related capabilities
Test the connection: Ask Copilot to "list files in HDFS directory /user"

Step 4: Using the MCP Server with Copilot

Once configured, you can ask GitHub Copilot to interact with your Hue server:

Example queries:

"Execute a Hive query to show tables"
"List files in HDFS directory /user/data"
"Download the file /user/data/results.csv from HDFS"
"Execute this SQL query and save results to CSV: SELECT * FROM my_table LIMIT 100"

Troubleshooting VS Code Integration

Issue: MCP server not appearing in Copilot

Verify the mcp.json path is correct
Check that uv is installed and in your PATH
Restart VS Code completely
Check VS Code's Output panel (View > Output) and select "GitHub Copilot" from the dropdown

Issue: Authentication errors

Verify your HUE_HOST, HUE_USERNAME, and HUE_PASSWORD are correct
Test connectivity to your Hue server directly
Check if SSL verification is causing issues (try setting HUE_VERIFY_SSL to false for testing)

Issue: Command not found

Ensure uv is installed: run uv --version in terminal
Verify the project path in mcp.json is correct and uses proper escaping
Make sure you ran uv sync in the project directory

Alternative: Using Absolute Python Path

If uv is not working or not in your PATH, you can use the absolute path to the Python interpreter:

Windows example:

{
  "mcpServers": {
    "hue": {
      "command": "C:\\Projects\\hueclientrest-mpc\\.venv\\Scripts\\python.exe",
      "args": ["-m", "hue_mcp_server.server"],
      "env": {
        "HUE_HOST": "https://your-hue-server.com",
        "HUE_USERNAME": "your_username",
        "HUE_PASSWORD": "your_password"
      }
    }
  }
}

macOS/Linux example:

{
  "mcpServers": {
    "hue": {
      "command": "/full/path/to/hueclientrest-mpc/.venv/bin/python",
      "args": ["-m", "hue_mcp_server.server"],
      "env": {
        "HUE_HOST": "https://your-hue-server.com",
        "HUE_USERNAME": "your_username",
        "HUE_PASSWORD": "your_password"
      }
    }
  }
}

Other Usage Methods

Claude Desktop Integration

If you're using Claude Desktop instead of VS Code, add this to your Claude config (~/.config/claude/claude_desktop_config.json on Mac/Linux or %APPDATA%\Claude\claude_desktop_config.json on Windows):

{
  "mcpServers": {
    "hue": {
      "command": "uv",
      "args": ["run", "--directory", "/path/to/hueclientrest-mpc", "hue-mcp-server"],
      "env": {
        "HUE_HOST": "https://your-hue-server.com",
        "HUE_USERNAME": "your_username",
        "HUE_PASSWORD": "your_password"
      }
    }
  }
}

Development Mode

Test the server interactively using the MCP inspector:

uv run mcp dev src/hue_mcp_server/server.py

This opens an interactive interface where you can test tools and see requests/responses in real-time.

Direct Command Line Execution

You can also run the server directly:

# Using the installed script (after uv sync)
uv run hue-mcp-server

# Or via Python module
uv run python -m hue_mcp_server.server

Available Tools

SQL Query Tools

`hue_execute_query`

Execute a SQL query and return results directly.

Arguments:
  - statement: SQL statement to execute
  - dialect: 'hive', 'sparksql', or 'impala' (default: 'hive')
  - timeout: Max wait time in seconds (default: 300)
  - batch_size: Rows per batch (default: 1000)

`hue_run_query_to_csv`

Execute a query and save results to a CSV file.

Arguments:
  - statement: SQL statement to execute
  - filename: Output CSV filename (default: 'results.csv')
  - dialect: SQL dialect (default: 'hive')
  - batch_size: Rows per batch (default: 1000)

`hue_export_and_download`

Execute INSERT OVERWRITE DIRECTORY and download resulting files.

Arguments:
  - statement: SQL with INSERT OVERWRITE DIRECTORY
  - hdfs_directory: HDFS output directory
  - local_directory: Local download directory (default: '.')
  - dialect: SQL dialect (default: 'hive')
  - file_pattern: Regex to filter files (optional)
  - timeout: Max wait time (default: 300)

HDFS File Tools

`hue_list_directory`

List contents of an HDFS directory.

Arguments:
  - directory_path: HDFS path (e.g., '/user/data')
  - page_size: Max items to return (default: 1000)

`hue_check_directory_exists`

Check if an HDFS directory exists.

Arguments:
  - directory_path: HDFS path to check

`hue_download_file`

Download a single file from HDFS.

Arguments:
  - remote_path: Full HDFS file path
  - local_filename: Local filename (optional)

`hue_download_directory`

Download all files from an HDFS directory.

Arguments:
  - directory_path: HDFS directory path
  - local_directory: Local directory (default: '.')
  - file_pattern: Regex to filter files (optional)

`hue_upload_file`

Upload a local file to HDFS.

Arguments:
  - local_file_path: Path to local file
  - hdfs_destination: HDFS destination directory

How It Works

The Model Context Protocol (MCP)

MCP is an open protocol that standardizes how AI assistants communicate with external tools and data sources. Think of it as a universal adapter that lets AI assistants "plug into" different services.

Key components:

MCP Server (this project): Exposes tools and capabilities
MCP Client (VS Code/Claude Desktop): Consumes tools and presents them to the AI
Protocol: Defines how they communicate

Architecture Flow

┌─────────────────┐        ┌──────────────────┐        ┌─────────────────┐
│   GitHub        │  MCP   │   Hue MCP        │  REST  │   Hadoop Hue    │
│   Copilot       │◄──────►│   Server         │◄──────►│   Server        │
│   (VS Code)     │Protocol│   (This Project) │  API   │                 │
└─────────────────┘        └──────────────────┘        └─────────────────┘
                                     │
                                     ▼
                           ┌──────────────────┐
                           │  HueClientRest   │
                           │  Library         │
                           └──────────────────┘

User asks Copilot to query Hue data
Copilot recognizes the request requires Hue MCP tools
MCP Server receives the request and translates it to Hue REST API calls
HueClientRest library handles authentication and API communication
Results flow back through the chain to the user

Dependency Details

Astral uv (Package Manager)

What it is: A next-generation Python package and project manager written in Rust.

Why we use it:

Speed: 10-100x faster than pip
Better dependency resolution: Handles complex dependencies more reliably
Unified tool: Combines pip, pip-tools, pipx, poetry, pyenv functionality
Reproducible environments: Lock files ensure consistent installs
Cross-platform: Works seamlessly on Windows, macOS, and Linux

Key commands:

uv sync - Install/update dependencies
uv add <package> - Add a new dependency
uv run <command> - Run commands in the virtual environment
uv pip install <package> - Use like pip if needed

Learn more: https://docs.astral.sh/uv/

mcp[cli] (Python SDK)

What it is: The official Python SDK for building MCP servers.

Key features:

FastMCP framework: Simplified server creation with decorators
Type validation: Pydantic integration for request/response validation
CLI tools: mcp dev for testing, mcp install for setup
Async support: Built on asyncio for efficient I/O
SSE transport: Server-sent events for real-time communication

In this project:

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("Hue MCP Server")

@mcp.tool()
def hue_execute_query(statement: str, dialect: str = "hive"):
    """Execute SQL query on Hue"""
    # Implementation

hueclientrest (Hue Client Library)

What it is: Python client for Hadoop Hue REST API.

Capabilities:

SQL query execution (Hive, SparkSQL, Impala)
HDFS file operations
Session management
Authentication handling
Error handling and retries

In this project:

from hueclientrest import HueClientREST

client = HueClientREST(host, username, password)
client.login()
result = client.execute_query(statement, dialect)

pydantic (Data Validation)

What it is: Data validation library using Python type hints.

Why we use it:

Type safety: Validates tool inputs/outputs at runtime
Auto-documentation: Generates schemas from type hints
Error messages: Clear validation errors for debugging
JSON schema: Automatic schema generation for MCP

In this project:

from pydantic import BaseModel, Field

class QueryResult(BaseModel):
    rows: List[dict]
    columns: List[str]
    row_count: int

Example Usage Scenarios

Scenario 1: Execute a Hive Query

In VS Code with Copilot:

You: "Execute a Hive query to show the first 10 tables"
Copilot: [Uses hue_execute_query tool]
Result: Returns table list from your Hue server

Query executed:

SELECT database_name, table_name 
FROM information_schema.tables 
LIMIT 10

Scenario 2: List HDFS Files

In VS Code with Copilot:

You: "List all files in /user/hive/warehouse directory"
Copilot: [Uses hue_list_directory tool]
Result: Shows file names, sizes, and permissions

Scenario 3: Export Data to CSV

In VS Code with Copilot:

You: "Query the sales table for 2024 and save to CSV"
Copilot: [Uses hue_run_query_to_csv tool]
Result: Creates sales_2024.csv with query results

Query executed:

SELECT * FROM sales WHERE year = 2024

Scenario 4: Complex Data Pipeline

In VS Code with Copilot:

You: "Check if /user/data/processed exists, if not list /user/data, 
     then download all CSV files from there"
Copilot: 
  1. [Uses hue_check_directory_exists]
  2. [Uses hue_list_directory]
  3. [Uses hue_download_directory with file_pattern=".*\.csv$"]
Result: Downloads all CSV files to local directory

Development

Setting Up for Development

# Clone and install
git clone <your-repo-url>
cd hueclientrest-mpc
uv sync

# Install development dependencies
uv sync --dev

Running Tests

# Run all tests
uv run pytest

# Run with coverage
uv run pytest --cov=hue_mcp_server

# Run specific test file
uv run pytest tests/test_server.py

Adding New Tools

To add a new MCP tool:

Define the tool function in server.py:

@mcp.tool()
def hue_new_feature(param: str) -> dict:
    """Description of what this tool does."""
    client = get_client()
    result = client.some_operation(param)
    return {"status": "success", "data": result}

The @mcp.tool() decorator automatically:
- Registers the tool with the MCP server
- Generates JSON schema from type hints
- Validates inputs using Pydantic
- Handles errors and responses
Test your tool:

uv run mcp dev src/hue_mcp_server/server.py

Debugging

Enable verbose logging:

import logging
logging.basicConfig(level=logging.DEBUG)

Test MCP server directly:

# Interactive testing
uv run mcp dev src/hue_mcp_server/server.py

# Check server can start
uv run python -m hue_mcp_server.server

VS Code debugging:

Check Output panel: View > Output > GitHub Copilot
Look for MCP server connection messages
Check for authentication or network errors

Project Structure

hueclientrest-mpc/
├── .venv/                  # Virtual environment (created by uv)
├── pyproject.toml          # Project metadata and dependencies
├── README.md               # This comprehensive guide
├── .env.example            # Example environment variables
├── .gitignore              # Git ignore patterns
└── src/
    └── hue_mcp_server/
        ├── __init__.py     # Package initialization
        └── server.py       # MCP server implementation
            ├── Server setup and configuration
            ├── Tool definitions (@mcp.tool decorators)
            ├── Hue client wrapper functions
            └── Main entry point

Dependencies Management

View installed packages:

uv pip list

Add a new dependency:

uv add <package-name>

Update dependencies:

uv sync --upgrade

Remove a dependency:

uv remove <package-name>

Security Considerations

Credential Management

Best Practices:

Never commit credentials to version control
Use environment variables or secure vaults
Rotate passwords regularly
Use .env files for local development only
Use secrets management (Azure Key Vault, AWS Secrets Manager) in production

SSL/TLS Configuration

For production environments:

# Always verify SSL certificates
HUE_VERIFY_SSL=true
HUE_SSL_WARNINGS=false

For development/testing (self-signed certificates):

# Only for development!
HUE_VERIFY_SSL=false
HUE_SSL_WARNINGS=false

Network Security

Ensure Hue server is accessible from your development machine
Check firewall rules if connection fails
Use VPN if required by your organization
Keep authentication tokens secure

Troubleshooting Common Issues

Issue: uv command not found

Solution:

# Windows PowerShell
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

# Then restart terminal or add to PATH

Issue: Python version mismatch

Error: requires-python = ">=3.10" but you have Python 3.9

Solution:

# Install Python 3.10+ from python.org
# Or use uv to manage Python versions
uv python install 3.11
uv venv --python 3.11

Issue: MCP server not loading in VS Code

Checklist:

uv is installed and in PATH (uv --version)
Project dependencies installed (uv sync)
mcp.json path is correct for your OS
Project path in mcp.json uses proper escaping
VS Code completely restarted (all windows closed)
GitHub Copilot extension is enabled
Active Copilot subscription

Issue: Authentication failures

Error: "Authentication failed" or "401 Unauthorized"

Solution:

Verify credentials are correct
Check if Hue server URL is accessible
Test login directly in browser
Check for special characters in password (may need escaping)
Verify user has necessary permissions in Hue

Issue: Query timeouts

Error: "Query execution timeout"

Solution:

# Increase timeout when calling tools
hue_execute_query(
    statement="SELECT * FROM large_table",
    timeout=600  # 10 minutes instead of default 5
)

Issue: HDFS file not found

Error: "File or directory not found"

Solution:

Verify path is absolute (starts with /)
Check permissions on HDFS
Use hue_list_directory to browse available paths
Verify user has read/write permissions

Performance Tips

Query Optimization

Use batch_size for large result sets:

hue_execute_query(statement="...", batch_size=5000)

Use LIMIT in queries when exploring:

SELECT * FROM large_table LIMIT 1000

Export large datasets directly to HDFS:

INSERT OVERWRITE DIRECTORY '/tmp/export'
SELECT * FROM large_table

Then use hue_export_and_download to retrieve files.

HDFS Operations

Download specific files with patterns:

hue_download_directory(
    directory_path="/user/data",
    file_pattern=".*\\.csv$"  # Only CSV files
)

Use streaming for large file transfers
Batch uploads when possible

FAQ

Q: Can I use this with Claude Desktop?

A: Yes! See the "Claude Desktop Integration" section for configuration details.

Q: Does this work on Windows?

A: Yes, fully supported on Windows, macOS, and Linux.

Q: What Hue versions are supported?

A: Any version with REST API support. Tested with Hue 4.x and newer.

A: Each user should run their own MCP server instance with their own credentials.

Q: How do I update to the latest version?

git pull
uv sync --upgrade

Q: Is my password secure?

A: Credentials are stored in environment variables or mcp.json. Keep these files secure and never commit them to version control.

Resources

Documentation

Community

Contributing

Contributions are welcome! Please feel free to submit issues or pull requests.

Development Setup

git clone <your-repo-url>
cd hueclientrest-mpc
uv sync --dev

Running Tests

uv run pytest
uv run pytest --cov=hue_mcp_server

Code Style

This project uses:

Black for code formatting
isort for import sorting
mypy for type checking

Changelog

v0.1.0 (Current)

Initial release
SQL query execution (Hive, SparkSQL, Impala)
HDFS file operations
CSV export functionality
VS Code and Claude Desktop integration

License

MIT License - See LICENSE file for details

Credits

HueClientRest - The underlying Python client for Hue REST API
Model Context Protocol - Open standard for AI-tool integration
Astral - Creators of uv package manager
Anthropic - MCP specification and implementation

Support

For issues, questions, or feature requests:

Check the Troubleshooting section
Search existing GitHub issues
Create a new issue with detailed information

Happy querying! 🚀

Available Tools

8 tools

hue_check_directory_existsA

Check if a directory exists in HDFS.

Args:
    directory_path: The HDFS directory path to check

Returns:
    True if the directory exists, False otherwise

ParametersJSON Schema

Name	Required	Description	Default
`directory_path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/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 full burden. It discloses the boolean return behavior ('True if exists, False otherwise'), which is helpful, but lacks details on error handling, permissions needed, or performance characteristics. It adds some value but misses key behavioral traits for a file system operation.

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 perfectly front-loaded with the core purpose in the first sentence, followed by structured Args and Returns sections. Every sentence earns its place with no wasted words, making it highly efficient and easy to parse.

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?

Given the tool's low complexity (1 parameter, boolean output), the description is largely complete: it states the purpose, parameter meaning, and return value. The output schema exists, so return values needn't be explained. However, it could benefit from more behavioral context (e.g., error cases) to be fully comprehensive.

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 schema description coverage is 0%, so the description must compensate. It provides a clear explanation of the single parameter ('directory_path: The HDFS directory path to check'), adding essential meaning beyond the bare schema. This adequately covers the parameter semantics for this simple tool.

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 clearly states the specific verb ('check if exists') and resource ('directory in HDFS'), distinguishing it from siblings like hue_list_directory (which lists contents) or hue_download_directory (which downloads). It precisely communicates the tool's function without ambiguity.

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 usage for verifying directory existence in HDFS, but lacks explicit guidance on when to use this versus alternatives (e.g., hue_list_directory for more detailed info) or any prerequisites. It provides basic context but no exclusions or comparative advice.

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

hue_download_directoryA

Download all files from an HDFS directory.

Args:
    directory_path: The HDFS directory path to download from
    local_directory: Local directory to save files to (default: '.')
    file_pattern: Optional regex pattern to filter files (e.g., '.*\.csv')

Returns:
    OperationResult with list of downloaded files

ParametersJSON Schema

Name	Required	Default
`directory_path`	Yes
`local_directory`	No	.
`file_pattern`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`path`	No	Relevant path for the operation
`message`	Yes	Status message
`success`	Yes	Whether the operation succeeded

TDQS

A4.1/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 for behavioral disclosure. It mentions the operation returns an 'OperationResult with list of downloaded files', which adds some context about output format. However, it doesn't address critical behavioral aspects like permissions needed, whether it overwrites existing local files, error handling, or performance implications for large directories.

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 efficiently structured with a clear purpose statement followed by well-organized Args and Returns sections. Every sentence earns its place by providing essential information without redundancy. The formatting enhances readability while maintaining brevity.

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?

Given the tool has an output schema (which handles return values), 3 parameters with no schema descriptions, and no annotations, the description does well by fully documenting parameters and stating the return type. However, as a file transfer operation with potential side effects, it could benefit from more behavioral context about safety and constraints.

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

Parameters5/5

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

With 0% schema description coverage, the description fully compensates by providing clear semantic explanations for all 3 parameters: directory_path specifies the source, local_directory specifies the destination with default, and file_pattern explains filtering with a concrete example. This adds significant value beyond the bare schema.

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 clearly states the specific action ('Download all files') and resource ('from an HDFS directory'), distinguishing it from sibling tools like hue_download_file (single file) and hue_list_directory (listing only). The verb+resource combination is precise and unambiguous.

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

Usage Guidelines4/5

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

The description implies usage context through the parameter explanations (e.g., filtering with file_pattern), but doesn't explicitly state when to use this tool versus alternatives like hue_download_file or hue_export_and_download. It provides clear functional context but lacks explicit comparative guidance.

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

hue_download_fileA

Download a single file from HDFS.

Args:
    remote_path: The full path to the file in HDFS
    local_filename: Local filename to save as (optional, defaults to original name)

Returns:
    OperationResult with the local filename where file was saved

ParametersJSON Schema

Name	Required	Description	Default
`remote_path`	Yes
`local_filename`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`path`	No	Relevant path for the operation
`message`	Yes	Status message
`success`	Yes	Whether the operation succeeded

TDQS

A3.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 of behavioral disclosure. While it mentions the return type ('OperationResult with the local filename'), it does not cover critical aspects like authentication requirements, error handling, file size limits, network timeouts, or whether the operation is idempotent. For a file download tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

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 well-structured and front-loaded with the core purpose, followed by clear sections for Args and Returns. Every sentence adds value without redundancy, making it efficient and easy to parse.

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 has an output schema (which covers return values), the description does not need to explain return details. However, with no annotations and a file operation that could involve permissions, errors, or performance considerations, the description is minimally adequate but lacks depth for safe and effective use in complex scenarios.

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 description adds meaningful context beyond the input schema, which has 0% description coverage. It explains that 'remote_path' is 'the full path to the file in HDFS' and 'local_filename' is 'Local filename to save as (optional, defaults to original name)', clarifying usage and default behavior. However, it does not detail path format requirements or validation rules.

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 clearly states the specific action ('Download a single file') and resource ('from HDFS'), distinguishing it from sibling tools like hue_download_directory (for directories) and hue_upload_file (reverse operation). It precisely defines the tool's scope without ambiguity.

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

Usage Guidelines4/5

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

The description implies usage context through the parameter descriptions (e.g., 'full path to the file in HDFS'), but does not explicitly state when to use this tool versus alternatives like hue_download_directory or hue_export_and_download. It provides clear operational guidance but lacks explicit sibling differentiation.

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

hue_execute_queryA

Execute a SQL query on Hue and return the results.

This tool executes a SQL statement, waits for completion, and fetches all results.
Use this for SELECT queries where you want to retrieve data.

Args:
    statement: The SQL statement to execute (e.g., "SELECT * FROM table LIMIT 100")
    dialect: SQL dialect to use - 'hive', 'sparksql', or 'impala' (default: 'hive')
    timeout: Maximum time to wait for query completion in seconds (default: 300)
    batch_size: Number of rows to fetch per batch for pagination (default: 1000)

Returns:
    QueryResult with headers, rows, and row_count

ParametersJSON Schema

Name	Required	Default
`statement`	Yes
`dialect`	No	hive
`timeout`	No
`batch_size`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`rows`	Yes	Query result rows as nested lists
`headers`	Yes	Column headers from the query result
`row_count`	Yes	Total number of rows returned

TDQS

A4.6/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 full burden of behavioral disclosure. It effectively describes key behaviors: executing a SQL statement, waiting for completion, fetching all results, and handling pagination via batch_size. It also implies potential timeouts and resource usage, though it could add more on error handling or permissions.

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 well-structured and front-loaded, starting with the core purpose, followed by usage guidance, and then detailed parameter explanations. Every sentence adds value without redundancy, making it efficient and easy to scan for an AI agent.

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

Completeness5/5

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

Given the tool's complexity (4 parameters, no annotations, but with an output schema), the description is complete enough. It covers purpose, usage, parameters, and return values ('QueryResult with headers, rows, and row_count'), and the output schema eliminates the need to detail return formats further, ensuring the agent has all necessary context.

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

Parameters5/5

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

The description adds significant meaning beyond the input schema, which has 0% description coverage. It explains each parameter's purpose, provides examples (e.g., SQL statement format), lists dialect options, and clarifies defaults and units (seconds for timeout, rows for batch_size). This fully compensates for the schema's lack of descriptions.

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 clearly states the tool's purpose with a specific verb ('execute a SQL query'), resource ('on Hue'), and outcome ('return the results'). It distinguishes from siblings by focusing on direct SQL execution rather than file operations or directory checks, making it immediately identifiable for its intended use.

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

Usage Guidelines4/5

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

The description provides clear context by specifying 'Use this for SELECT queries where you want to retrieve data,' which helps differentiate it from potential write operations. However, it does not explicitly mention when not to use it or name alternatives among siblings, such as 'hue_run_query_to_csv' for CSV output, leaving some ambiguity.

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

hue_export_and_downloadA

Execute an INSERT OVERWRITE DIRECTORY query and download the results.

This tool is for queries that write output to HDFS (like INSERT OVERWRITE DIRECTORY),
then downloads the resulting files to the local filesystem.

Args:
    statement: SQL statement with INSERT OVERWRITE DIRECTORY
    hdfs_directory: The HDFS directory where results are written
    local_directory: Local directory to download files to (default: '.')
    dialect: SQL dialect - 'hive', 'sparksql', or 'impala' (default: 'hive')
    file_pattern: Optional regex pattern to filter files to download
    timeout: Maximum wait time in seconds (default: 300)

Returns:
    OperationResult with list of downloaded files in message

ParametersJSON Schema

Name	Required	Default
`statement`	Yes
`hdfs_directory`	Yes
`local_directory`	No	.
`dialect`	No	hive
`file_pattern`	No
`timeout`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`path`	No	Relevant path for the operation
`message`	Yes	Status message
`success`	Yes	Whether the operation succeeded

TDQS

A4.2/5.0

Behavior3/5

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

With no annotations provided, the description carries full burden. It discloses key behavioral traits: executes a specific type of SQL query (INSERT OVERWRITE DIRECTORY), writes to HDFS, downloads to local filesystem, and has a timeout default. However, it doesn't mention important aspects like whether the operation is destructive (OVERWRITE implies it might be), authentication requirements, error handling, or rate limits. The description adds value but leaves significant gaps.

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 perfectly structured: a clear purpose statement upfront, followed by context, then a well-organized parameter list with explanations and defaults, and finally the return value. Every sentence earns its place with no redundancy. The information is front-loaded and efficiently presented.

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?

Given 6 parameters with 0% schema coverage and no annotations, the description does an excellent job explaining parameters and stating the return type. However, for a tool that executes queries and downloads files, it lacks information about error conditions, file formats, what happens if the directory already exists, or security implications. The presence of an output schema helps, but behavioral context could be more complete.

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?

Schema description coverage is 0%, so the description must compensate. It provides meaningful explanations for all 6 parameters beyond their titles: statement is 'SQL statement with INSERT OVERWRITE DIRECTORY', hdfs_directory is 'The HDFS directory where results are written', local_directory has default '.', dialect options are listed, file_pattern is 'Optional regex pattern to filter files', and timeout is 'Maximum wait time in seconds'. This adds substantial semantic value over the bare schema.

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 clearly states the specific action: 'Execute an INSERT OVERWRITE DIRECTORY query and download the results.' It distinguishes from siblings like hue_execute_query (general query execution) and hue_download_directory (download without query execution) by combining both operations. The verb+resource combination is precise and unambiguous.

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

Usage Guidelines4/5

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

The description provides clear context: 'This tool is for queries that write output to HDFS (like INSERT OVERWRITE DIRECTORY), then downloads the resulting files.' This implicitly distinguishes it from siblings that don't execute queries or don't download. However, it doesn't explicitly state when NOT to use it or name specific alternatives like hue_run_query_to_csv for different output formats.

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

hue_list_directoryA

List files and directories in an HDFS path.

Use this to browse the contents of HDFS directories.

Args:
    directory_path: The HDFS directory path (e.g., '/user/data', '/tmp')
    page_size: Maximum number of items to return (default: 1000)

Returns:
    DirectoryListing with path, items, and total_count

ParametersJSON Schema

Name	Required	Description	Default
`directory_path`	Yes
`page_size`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`path`	Yes	The directory path that was listed
`items`	Yes	List of files and directories
`total_count`	Yes	Total number of items

TDQS

A4.4/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 full burden. It describes a read-only listing operation, which is clear, but lacks details on permissions, error handling, or rate limits. The mention of pagination (page_size) and return structure adds some behavioral context, but more could be included for a mutation-free tool.

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 well-structured and front-loaded with the core purpose, followed by usage guidance and parameter details. Every sentence adds value without redundancy, making it efficient and easy to parse for an AI agent.

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?

Given the tool's low complexity (2 parameters, no nested objects) and the presence of an output schema (implied by 'Returns' statement), the description is mostly complete. It covers purpose, usage, parameters, and return structure, but could benefit from more behavioral details like error cases or performance considerations to be fully comprehensive.

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?

Schema description coverage is 0%, so the description must compensate. It explains both parameters: directory_path as 'The HDFS directory path' with examples, and page_size as 'Maximum number of items to return' with a default. This adds meaningful semantics beyond the bare schema, though it doesn't cover all possible nuances like path validation.

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 clearly states the verb 'list' and resource 'files and directories in an HDFS path', making the purpose specific and actionable. It distinguishes from siblings like hue_check_directory_exists (checking existence) and hue_download_directory (downloading content), establishing a unique read-only browsing function.

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

Usage Guidelines5/5

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

The description explicitly states 'Use this to browse the contents of HDFS directories', providing clear context for when to use this tool. It implies alternatives like hue_check_directory_exists for existence checks or hue_download_directory for downloading, though it doesn't name them directly, but the guidance is sufficient for effective tool selection.

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

hue_run_query_to_csvA

Execute a SQL query and save results directly to a CSV file.

This is a convenience method that combines query execution with CSV export.
Ideal for exporting large result sets to files.

Args:
    statement: The SQL statement to execute
    filename: Output CSV filename (default: 'results.csv')
    dialect: SQL dialect - 'hive', 'sparksql', or 'impala' (default: 'hive')
    batch_size: Number of rows to fetch per batch (default: 1000)

Returns:
    OperationResult indicating success and the output filename

ParametersJSON Schema

Name	Required	Default
`statement`	Yes
`filename`	No	results.csv
`dialect`	No	hive
`batch_size`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`path`	No	Relevant path for the operation
`message`	Yes	Status message
`success`	Yes	Whether the operation succeeded

TDQS

A4.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 full burden of behavioral disclosure. It describes the tool's core behavior (executing SQL and saving to CSV) and mentions it's for 'large result sets' with batching, but lacks details on permissions, error handling, rate limits, or file system implications. It adds some context but doesn't fully compensate for the absence of annotations.

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 well-structured and appropriately sized. It starts with a clear purpose statement, adds context in the second sentence, and efficiently documents parameters and returns in labeled sections. Every sentence adds value without redundancy, making it easy to parse.

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?

Given the tool's complexity (4 parameters, no annotations, but with an output schema), the description is mostly complete. It explains parameters thoroughly and mentions the return type ('OperationResult'), but since there's an output schema, it doesn't need to detail return values. However, it could better address behavioral aspects like error cases or performance implications.

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

Parameters5/5

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

The description adds significant meaning beyond the input schema, which has 0% description coverage. It explains each parameter's purpose: 'statement' as the SQL to execute, 'filename' as the output CSV file, 'dialect' with allowed values ('hive', 'sparksql', or 'impala'), and 'batch_size' as rows per batch. This fully compensates for the schema's lack of descriptions.

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 clearly states the tool's purpose with specific verbs ('execute a SQL query and save results directly to a CSV file') and distinguishes it from siblings like 'hue_execute_query' (which doesn't export) and 'hue_export_and_download' (which may have different functionality). The phrase 'convenience method that combines query execution with CSV export' further clarifies its unique role.

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

Usage Guidelines4/5

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

The description provides clear context for when to use this tool ('ideal for exporting large result sets to files'), but it doesn't explicitly state when not to use it or name specific alternatives among the sibling tools. It implies usage for CSV export scenarios without detailed exclusions or comparisons.

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

hue_upload_fileA

Upload a local file to HDFS.

Args:
    local_file_path: Path to the local file to upload
    hdfs_destination: Destination directory in HDFS

Returns:
    OperationResult indicating success

ParametersJSON Schema

Name	Required	Description	Default
`local_file_path`	Yes
`hdfs_destination`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`path`	No	Relevant path for the operation
`message`	Yes	Status message
`success`	Yes	Whether the operation succeeded

TDQS

A3.5/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 mentions the return type ('OperationResult indicating success') but fails to detail critical aspects like permissions needed, file size limits, overwrite behavior, or error handling, leaving significant gaps for a mutation tool.

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 well-structured and front-loaded with the core purpose, followed by clear sections for Args and Returns. Every sentence earns its place without redundancy, making it efficient and easy to parse.

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 complexity as a file upload operation with no annotations and an output schema, the description is minimally adequate. It covers basic purpose and parameters but lacks behavioral details like side effects or error cases, which are crucial for safe usage in this context.

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 description adds meaningful context beyond the input schema, which has 0% coverage. It explains that 'local_file_path' is the source and 'hdfs_destination' is the target directory, clarifying their roles. However, it doesn't specify format details like path syntax or HDFS conventions, slightly limiting completeness.

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 clearly states the specific action ('Upload a local file to HDFS') with the resource ('local file'), distinguishing it from siblings like download or list operations. It explicitly names the tool's function without being vague or tautological.

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 on when to use this tool versus alternatives, such as hue_upload_directory (if it existed) or how it relates to siblings like hue_download_file. The description lacks context about prerequisites or exclusions, offering only basic usage without comparative advice.

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.

8 tool updatesv0.1.0Jan 23, 2026
- First observedhue_check_directory_exists
- First observedhue_download_directory
- First observedhue_download_file
- First observedhue_execute_query
- First observedhue_export_and_download
- First observedhue_list_directory
- First observedhue_run_query_to_csv
- First observedhue_upload_file

Install Server

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

TDQS

A4.2/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap. For example, hue_check_directory_exists verifies existence, hue_list_directory browses contents, hue_download_file handles single files, hue_download_directory handles directories, hue_upload_file uploads, hue_execute_query runs queries, hue_export_and_download handles INSERT queries with downloads, and hue_run_query_to_csv exports directly to CSV. The descriptions clearly differentiate their specific use cases.

Naming Consistency5/5

All tools follow a consistent 'hue_verb_noun' pattern with snake_case throughout. The verbs are descriptive and appropriate for each action (e.g., check, download, execute, export, list, run, upload). There are no deviations in naming conventions across the toolset.

Tool Count5/5

With 8 tools, this server is well-scoped for its purpose of interacting with HDFS and executing queries via Hue. The count covers essential operations like file management (upload, download, list, check) and query execution (execute, export, run to CSV) without being excessive. Each tool serves a clear, necessary function in the workflow.

Completeness4/5

The toolset provides strong coverage for core HDFS file operations and SQL query execution, including CRUD-like actions for files and data retrieval. Minor gaps exist, such as no direct tool for deleting files/directories in HDFS or updating queries, but agents can work around these using existing tools (e.g., overwriting with upload or using INSERT queries). The surface supports common workflows effectively.

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

OleanderOAuth
dev.oleander
The all-in-one data stack for agents. Upload files, run SQL, evolve tables, and render charts.
Databases Data Platforms Data Visualization
2
Quadratic A
io.github.quadratichq
AI access to Quadratic spreadsheets: open files, run Python/SQL, query connected databases.
Data Platforms Databases Code Execution
52
stagenth · 数据工具箱 A
com.stagenth
Query, join, profile, clean and convert CSV/JSON/Parquet with server-side DuckDB over MCP.
Databases Data Platforms File Systems
62
mcp AOAuth
co.axiom
List datasets, schemas, run APL queries, and use prompts for exploration, anomalies, and monitoring.
Databases Monitoring Search
29

Related MCP Servers

DuckDB MCP Server
Databases Developer Tools
boettiger-lab
A
license
B
quality
D
maintenance
Enables AI assistants and IDEs to execute SQL queries on local DuckDB databases, in-memory databases, or cloud-stored databases with support for flexible connections and configurable result limits.
Updated 8 months ago (2026-01-04 00:00 UTC)
1
1
MIT
MSSQL MCP Server
Databases Developer Tools
combiz
A
license
Not graded
quality
D
maintenance
Enables AI assistants to interact with Microsoft SQL Server databases through a standardized interface. Supports executing SQL queries, browsing database schemas, and viewing table data with flexible authentication options for both local and Azure SQL databases.
Updated a year ago (2025-07-02 16:16 UTC)
5
MIT
bricks-and-context
Databases Cloud Platforms
laraib-sidd
A
license
Not graded
quality
C
maintenance
Enables AI assistants to interact with Databricks workspaces, running SQL queries, managing jobs, and exploring schemas via the Model Context Protocol.
Updated 17 days ago (2026-08-20 15:45 UTC)
1
GPL 3.0
JobHistory MCP Server
Monitoring Observability
1179860746
F
license
Not graded
quality
D
maintenance
Enables AI assistants to query Hadoop MapReduce job history, including job listing, details, counters, configuration, and logs via the JobHistory REST API.
Updated 7 months ago (2026-02-05 08:19 UTC)
1
-

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/SpanishST/hueclientrest-mpc'

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

Hue MCP Server

What is This?

Features

Prerequisites

Dependencies

Installation

Step 1: Install Astral uv

Step 2: Clone and Install the Project

Alternative: Using pip

Configuration

Environment Variables

Setting Up Environment Variables

VS Code Integration with GitHub Copilot

Prerequisites for VS Code Integration

Step 1: Locate Your MCP Configuration File

Step 2: Configure the MCP Server in VS Code

Step 3: Verify the Configuration

Step 4: Using the MCP Server with Copilot

Troubleshooting VS Code Integration

Alternative: Using Absolute Python Path

Other Usage Methods

Claude Desktop Integration

Development Mode

Direct Command Line Execution

Available Tools

SQL Query Tools

hue_execute_query

hue_run_query_to_csv

hue_export_and_download

HDFS File Tools

hue_list_directory

hue_check_directory_exists

hue_download_file

hue_download_directory

hue_upload_file

How It Works

The Model Context Protocol (MCP)

Architecture Flow

Dependency Details

Astral uv (Package Manager)

mcp[cli] (Python SDK)

hueclientrest (Hue Client Library)

pydantic (Data Validation)

Example Usage Scenarios

Scenario 1: Execute a Hive Query

Scenario 2: List HDFS Files

Scenario 3: Export Data to CSV

Scenario 4: Complex Data Pipeline

Development

Setting Up for Development

Running Tests

Adding New Tools

Debugging

Project Structure

Dependencies Management

Security Considerations

Credential Management

SSL/TLS Configuration

Network Security

Troubleshooting Common Issues

Issue: uv command not found

Issue: Python version mismatch

Issue: MCP server not loading in VS Code

Issue: Authentication failures

Issue: Query timeouts

Issue: HDFS file not found

Performance Tips

Query Optimization

HDFS Operations

FAQ

Q: Can I use this with Claude Desktop?

Q: Does this work on Windows?

Q: What Hue versions are supported?

Q: Can multiple users share one MCP server?

Q: How do I update to the latest version?

Q: Is my password secure?

Resources

Documentation

Community

Related Projects

`hue_execute_query`

`hue_run_query_to_csv`

`hue_export_and_download`

`hue_list_directory`

`hue_check_directory_exists`

`hue_download_file`

`hue_download_directory`

`hue_upload_file`