LABSCO SUMMARY

Every mutation here hands back a request id rather than an outcome, which makes get_request_tasks the tool the rest of the surface is built around.

Starting a service is the easy half; knowing which host refused is the half that costs an afternoon, and get_request_tasks is the only place that answers it, filtering to FAILED or excluding COMPLETED so the exceptions surface without the full task list. The metrics side is deliberately strict in the same way: query_ambari_metrics accepts exact metric names only, so list_ambari_metric_apps, list_ambari_metrics_metadata and list_common_metrics_catalog are not conveniences but the required first step. Before wiring it in, note that get_current_alerts is a backward-compatible wrapper that get_alerts_history has replaced, and dump_configurations has absorbed the older configuration tools, so anything written against those older names is aiming at a surface that has already moved.

What it is

A server over Ambari's REST API and Ambari Metrics, exposing 30 tools across cluster and service state, service and host-component lifecycle, request tracking down to per-host tasks, alerts, users, configuration introspection and time-series metrics.

What you get

Cluster and service state in one read: get_cluster_info returns the cluster name, version, provisioning state and security type; get_cluster_services lists services with their current state; get_service_status, get_service_details and get_service_components return one service's state, configuration availability, component category, host assignments and instance counts.
Lifecycle control per service, per cluster and per host component: start_service, stop_service and restart_service act on a named service; start_all_services, stop_all_services and restart_all_services act on the whole cluster, matching Start All and Stop All in the Ambari web UI; start_host_component, stop_host_component and restart_host_component act on one component on one host and skip a component already in the target state.
Following an operation once it starts: lifecycle calls return request information, get_active_requests lists what is IN_PROGRESS or PENDING, get_request_status returns progress percentage and timing for a request_id, and get_request_tasks breaks the same request down host by host with a host_filter and a status_filter that also accepts exclusions written as not:COMPLETED.
Configuration read without opening the UI: dump_configurations filters by config_type or by service, and takes include_values, summarize, limit and max_chars so a wide read can be bounded before it is returned.
Alerts current and historical from one tool: get_alerts_history serves the cluster, a service or a host, switches between live and history by mode, and filters on alert state, definition_name and maintenance_state within a from_timestamp and to_timestamp window, paged by page_size and start_page.
Metrics resolved by exact name: list_ambari_metric_apps discovers the AMS appIds, list_ambari_metrics_metadata and list_common_metrics_catalog turn a search term into the exact metric names the query tool demands, query_ambari_metrics fetches the series with temporal_aggregator, temporal_granularity, precision and max_points, and hdfs_dfadmin_report renders a DFSAdmin-style capacity and DataNode report out of those metrics.
Hosts and users: list_hosts returns the registered hosts, get_host_details returns hardware specification, state, metrics and components for one host or for all of them, and list_users with get_user cover the Ambari user records.
get_prompt_template returns the maintained English prompt template, in full or one section at a time.

Requirements

An Ambari cluster you can reach over its REST API. The metrics tools read from the Ambari Metrics service, and hdfs_dfadmin_report builds its capacity report out of those metrics rather than from HDFS directly.

Setup effort

One command plus credentials — uvx mcp-ambari-api, then supply credentials

See installation options

USE CASES

Bringing a cluster back up after a maintenance window

Start everything in one call, then watch the request it created rather than guessing from service state.

start_all_servicesget_active_requestsget_request_statusget_cluster_services

Working out why one service will not come up

Read the service's state and where its components live, drill into the failed tasks host by host, then restart only the component that failed.

get_service_statusget_service_componentsget_request_tasksrestart_host_component

Answering what a service is actually configured with

Pull the configuration for one service with values included, bounded so a wide read does not return more than you can use.

dump_configurationsget_service_details

Establishing whether an alert is new or has been firing all week

Read the alert history for the host or service over a window, then look at what the host itself reports.

get_alerts_historyget_host_detailslist_hosts

Charting a metric you can only name approximately

Find the appId, resolve the search term into the exact metric name the query tool insists on, then pull the series.

list_ambari_metric_appslist_ambari_metrics_metadatalist_common_metrics_catalogquery_ambari_metrics

Checking HDFS capacity before a large ingest

Produce the DataNode and capacity picture from the metrics already being collected, over a lookback window you choose.

hdfs_dfadmin_reportlist_hosts

30 tools

Counted once with only startup setup. Other versions, modes or optional credentials may expose a different list.

`dump_configurations`

Unified configuration introspection tool (supersedes get_configurations & list_configurations & dump_all_configurations).

`get_alerts_history`

Retrieve current alerts or alert history from Ambari cluster.

[Tool Role]: Unified tool for retrieving both current/active alert status and historical alert events from Ambari cluster

[Core Functions]:

Current mode: Retrieve current alerts for entire cluster, specific service, or specific host
History mode: Retrieve alert history for entire cluster, specific service, or specific host
Support filtering by alert state (CRITICAL, WARNING, OK, UNKNOWN)
Support filtering by definition name
Current mode: Support filtering by maintenance state (ON, OFF)
History mode: Support filtering by time range with from_timestamp/to_timestamp
Support different output formats (detailed, summary, compact, groupedSummary for current)
History mode: Provide pagination support for large datasets
Provide current time context for LLM natural language time calculations

[Required Usage Scenarios]:

Current mode: When users request current alerts, active alerts, or alert status
Current mode: When monitoring immediate cluster health
Current mode: When investigating current issues or troubleshooting active problems
History mode: When users request alert history, past alerts, or historical alert data
History mode: When monitoring alert trends or analyzing alert patterns
History mode: When investigating past alert incidents or troubleshooting
When users mention alert status, current problems, cluster health, alert events, alert timeline, or alert logs

Args: mode: "current" for active alerts, "history" for past events (default: "current") cluster_name: Name of cluster (uses default if not specified) service_name: Filter by specific service name (e.g., HDFS, YARN) host_name: Filter by specific host name state_filter: Filter by alert state (CRITICAL, WARNING, OK, UNKNOWN) definition_name: Filter by alert definition name maintenance_state: Filter by maintenance state (ON, OFF) - current mode only from_timestamp: Start timestamp in milliseconds (Unix epoch) - history mode only to_timestamp: End timestamp in milliseconds (Unix epoch) - history mode only include_time_context: Add current time information for LLM natural language processing limit: Maximum number of alert entries to return page_size: Number of entries per page (default: 100) - history mode only start_page: Starting page number (default: 0) - history mode only format: Output format - 'detailed', 'summary', 'compact', or 'groupedSummary' (current mode only)

Returns: Alert information (success: formatted alerts, failure: English error message)

INSTALLATION

Connect your client

Server setup

TERMINAL

uvx mcp-ambari-api

MCP Clients

Claude Desktop

CLAUDE DESKTOP · JSON

{
  "mcpServers": {
    "mcp-ambari-api": {
      "command": "uvx",
      "args": [
        "--python",
        "3.12",
        "mcp-ambari-api"
      ],
      "env": {
        "AMBARI_HOST": "localhost",
        "AMBARI_PORT": "7070",
        "AMBARI_USER": "admin",
        "AMBARI_PASS": "admin",
        "AMBARI_CLUSTER_NAME": "TEST-AMBARI",
        "MCP_LOG_LEVEL": "INFO"
      }
    }
  }
}

Any MCP client — stdio

ANY MCP CLIENT — STDIO · JSON

{
  "mcpServers": {
    "mcp-ambari-api": {
      "command": "uvx",
      "args": [
        "--python",
        "3.12",
        "mcp-ambari-api"
      ],
      "env": {
        "AMBARI_HOST": "host.docker.internal",
        "AMBARI_PORT": "8080",
        "AMBARI_USER": "admin",
        "AMBARI_PASS": "admin",
        "AMBARI_CLUSTER_NAME": "TEST-AMBARI",
        "MCP_LOG_LEVEL": "INFO"
      }
    }
  }
}

Any MCP client — HTTP

ANY MCP CLIENT — HTTP · JSON

{
  "mcpServers": {
    "mcp-ambari-api": {
      "type": "streamable-http",
      "url": "http://localhost:18001/mcp"
    }
  }
}

Clients spell the "type" value differently: Claude Code and VS Code use "http", Cline uses "streamableHttp", and Roo Code uses "streamable-http". Claude Desktop does not accept a URL entry in its config file.

Any MCP client — HTTP, token

ANY MCP CLIENT — HTTP, TOKEN · JSON

{
  "mcpServers": {
    "mcp-ambari-api": {
      "type": "streamable-http",
      "url": "http://localhost:18001/mcp",
      "headers": {
        "Authorization": "Bearer <YOUR_SECURE_SECRET_KEY>"
      }
    }
  }
}

Open WebUI

Settings → Tools → add the mcp-ambari-api tool address, e.g. http://localhost:8000/mcp-ambari-api

Ambari-API MCP

Every mutation here hands back a request id rather than an outcome, which makes get_request_tasks the tool the rest of the surface is built around.

What it is

What you get

Requirements

Setup effort

Bringing a cluster back up after a maintenance window

Working out why one service will not come up

Answering what a service is actually configured with

Establishing whether an alert is new or has been firing all week

Charting a metric you can only name approximately

Checking HDFS capacity before a large ingest

30 tools

dump_configurations

get_active_requests

get_alerts_history

get_cluster_info

get_cluster_services

get_current_alerts

get_host_details

get_prompt_template

get_request_status

get_request_tasks

get_service_components

get_service_details

get_service_status

get_user

hdfs_dfadmin_report

list_ambari_metric_apps

list_ambari_metrics_metadata

list_common_metrics_catalog

list_hosts

list_users

query_ambari_metrics

restart_all_services

restart_host_component

restart_service

start_all_services

start_host_component

start_service

stop_all_services

stop_host_component

stop_service

What to know first

Tools you get

Requires

Moderate Standing cost

Connect your client

Server setup

MCP Clients

Claude Desktop

Any MCP client — stdio

Any MCP client — HTTP

Any MCP client — HTTP, token

Open WebUI

Same category

Kafka MCP

Lumenore-MCP

WireBoard

Airflow 3 MCP Server

`dump_configurations`

`get_active_requests`

`get_alerts_history`

`get_cluster_info`

`get_cluster_services`

`get_current_alerts`

`get_host_details`

`get_prompt_template`

`get_request_status`

`get_request_tasks`

`get_service_components`

`get_service_details`

`get_service_status`

`get_user`

`hdfs_dfadmin_report`

`list_ambari_metric_apps`

`list_ambari_metrics_metadata`

`list_common_metrics_catalog`

`list_hosts`

`list_users`

`query_ambari_metrics`

`restart_all_services`

`restart_host_component`

`restart_service`

`start_all_services`

`start_host_component`

`start_service`

`stop_all_services`

`stop_host_component`

`stop_service`