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.
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.
- 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.
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.
One command plus a key — uvx mcp-ambari-api, then supply credentials