Skip to main content
Glama
uyuni-project

Uyuni MCP Server

Official
by uyuni-project
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
UYUNI_PASSNoUyuni password for local deployments (not required for OAuth setups)
UYUNI_USERNoUyuni credentials for local deployments (not required for OAuth setups)
UYUNI_SERVERYesBasic API parameters: Uyuni server address and port (e.g., 192.168.1.124:8443)
UYUNI_MCP_HOSTNoHost to bind when using HTTP transport127.0.0.1
UYUNI_MCP_PORTNoPort to bind when using HTTP transport8080
UYUNI_AUTH_SERVERNoOAuth 2.0 authorization server URL
UYUNI_SSH_PRIV_KEYNoRequired to bootstrap new systems via the add_system tool. SSH private key as a single-line string with \n for newlines.
UYUNI_MCP_LOG_LEVELNoLogging level: DEBUG, INFO, WARNING, ERROR, CRITICAL. Defaults to 'INFO'.INFO
UYUNI_MCP_TRANSPORTNoSet the transport protocol. Can be 'stdio' (default) or 'http'.stdio
UYUNI_MCP_PUBLIC_URLNoFinal public URL to advertise (e.g., http://127.0.0.1:8080)
UYUNI_MCP_SSL_VERIFYNoSet to 'false' to disable SSL certificate verification. Defaults to 'true'.true
UYUNI_MCP_LOG_FILE_PATHNoPath for the server log file. Defaults to logging to the console.
UYUNI_SSH_PRIV_KEY_PASSNoPassphrase for the SSH private key (if any).
UYUNI_MCP_WRITE_TOOLS_ENABLEDNoSet to 'true' to enable tools that perform write actions (e.g., POST requests). Defaults to 'false'.false

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": true
}
logging
{}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
extensions
{
  "io.modelcontextprotocol/ui": {}
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
list_systemsA
List active systems in Uyuni.
Inputs: optional `limit`, `offset`.
`limit` is capped at 500.
Returns: `items` with active systems (`system_name`, `system_id`) and `meta`.
Note: use `system_id` for other system tools.
get_system_detailsA

Get details for one system.

Inputs: system_identifier (system_name or system_id). Name not found: resolve with find_systems_by_name, then pass system_id. Returns: system_id, system_name, last_boot, uuid, cpu, network, installed_products. Use system_id when possible.

get_system_event_historyA

List events for one system.

Inputs: system_identifier (system_name or system_id); optional offset, limit, earliest_date. Name not found: resolve with find_systems_by_name, then pass system_id. Returns: newest-first event list with id, history_type, status, summary, completed. Use get_system_event_details for one event.

get_system_event_detailsA

Get one event detail.

Inputs: system_identifier (system_name or system_id), event_id. Name not found: resolve with find_systems_by_name, then pass system_id. Returns: event object including status, timestamps, result fields, and optional additional_info. event_id should come from get_system_event_history.

find_systems_by_nameA

Find systems by hostname.

Inputs: name; optional limit, offset. Use this first when user input is a partial hostname. If multiple systems match, ask the user to choose one system_id. limit is capped at 500. Returns: items with matching systems (system_name, system_id) and meta.

find_systems_by_ipA

Find systems by IP address.

Inputs: ip_address; optional limit, offset. limit is capped at 500. Returns: items with matching systems (system_name, system_id, ip) and meta.

get_system_updatesA

Get pending updates for one system.

Inputs: system_identifier (system_name or system_id; prefer system_id). Name not found: resolve with find_systems_by_name, then pass system_id. Best for compact default update view. Returns: compact update list plus counts and meta. Default behavior omits CVEs for lower token usage. For pagination and CVE expansion, use query_system_updates.

summarize_system_updatesA

Summarize pending updates for one system.

Inputs: system_identifier (system_name or system_id); optional advisory_types. Name not found: resolve with find_systems_by_name, then pass system_id. Best for counts only. advisory_types accepts: Security Advisory, Product Enhancement Advisory, Bug Fix Advisory. Returns: update counts and meta.

query_system_updatesA

Query pending updates for one system.

Inputs: system_identifier (system_name or system_id); optional limit, offset, include_cves, advisory_types. Name not found: resolve with find_systems_by_name, then pass system_id. Best for pagination and optional CVE expansion. Pagination behavior: limit <= 0 returns no items (counts still available); positive limit is capped at 200. Returns: updates with pending updates for the system and meta.

check_all_systems_for_updatesA

Check all active systems for pending updates.

Inputs: optional include_updates, include_cves, system_limit, system_offset, updates_per_system. Best for fleet scan; set include_updates=true to include per-system update items. system_limit is capped at 200 for response paging. Returns: items with systems that have pending updates (plus optional update details) and meta.

summarize_fleet_updatesA

Summarize fleet update status.

Inputs: optional system_limit, system_offset. system_limit is capped at 200. Returns: paged list of systems with update counts in items and meta.

list_systems_needing_update_for_cveA

List systems affected by a CVE.

Inputs: cve_identifier; optional limit, offset. limit is capped at 500. Returns: items with unique affected systems (system_id, system_name) and meta.

list_systems_needing_rebootA

List systems that require reboot.

Inputs: optional limit, offset. limit is capped at 500. Returns: items with systems requiring reboot (system_id, system_name, reboot_status) and meta.

list_all_scheduled_actionsA

Query scheduled actions.

Inputs: optional limit, offset, action_types, scheduler. action_types and scheduler are optional exact-match filters; prefer values from meta.observed_action_types and meta.observed_schedulers. limit is capped at 500; use meta.next_offset to page. Returns: items with scheduled actions and meta.

list_activation_keysA

List activation keys available to the current user.

Inputs: none. Returns: list of objects with key and description.

get_unscheduled_errataA

List unscheduled errata for one system.

Inputs: system_id. This tool accepts numeric system_id only. Returns: errata list for that system.

list_system_groupsA

List system groups.

Inputs: none. Returns: list with id, name, description, and system_count.

list_group_systemsA

List systems in one group.

Inputs: group_name. Returns: list of system_id and system_name.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4/5.0

Scored across 18 tools

Disambiguation4/5

The tools have overlapping purposes, especially around updates (multiple tools for checking updates on individual systems and fleet), but descriptions clearly differentiate them by context (compact vs paginated, fleet vs individual). Some ambiguity remains for agents unfamiliar with the specific use cases.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., find_systems_by_name, get_system_details, list_systems, summarize_fleet_updates). No deviations or mixed conventions.

Tool Count5/5

18 tools is well-scoped for the domain of system management (systems, groups, updates, events, actions, activation keys). Each tool serves a clear purpose without unnecessary duplication.

Completeness3/5

The tool set covers reading and querying (systems, updates, events, groups, activation keys) comprehensively, but lacks tools for performing actions (e.g., applying updates, rebooting, modifying groups). This may be intentional for a read-only server, but it leaves gaps for full lifecycle management.

Maintenance

ActivityActive
ResponsivenessUnresponsive

Resources