Retrieve dashboards with their widgets, pages, and user/group sharing settings. Dashboards are the primary visualization surface in Zabbix, containing pages with widgets that display graphs, maps, problems, and other monitoring data. Use the 'output' parameter to control which fields are returned and 'selectPages' / 'selectUsers' / 'selectUserGroups' in the filter to include related objects.

Retrieve dashboards that belong to templates. Template dashboards are defined on templates and automatically appear on hosts linked to those templates. This is useful for standardising monitoring views across many hosts. Filter by templateids to find dashboards belonging to specific templates, or by dashboardids for direct lookup.

Retrieve scheduled reports. Reports are generated from dashboards on a schedule and delivered to users or user groups via email or other media. Filter by reportids for direct lookup or by dashboardids to find all reports generated from specific dashboards.

Retrieve Zabbix server High Availability (HA) cluster nodes. Returns information about each node's status, address, last access time, and role (active / standby / stopped / unavailable). Use this to monitor the health of a Zabbix HA cluster. This is a read-only method; HA nodes are managed by the Zabbix server process, not via the API.

Retrieve historical item data (collected metric values). History stores every collected value and is the most granular data source in Zabbix. Always specify the 'history' parameter to select the correct data type (0=numeric float, 1=character/string, 2=log, 3=numeric unsigned, 4=text, 5=binary on 7.0+, 6=JSON on 8.0+; Zabbix assumes 3 when omitted). Use 'time_from' and 'time_till' (Unix timestamp, ISO 8601 or a relative time such as now-1h) to bound the time range. Combine with 'itemids' or 'hostids' to target specific metrics. For long time ranges, consider using trend.get instead as it returns aggregated min/avg/max values and is more efficient. With 'itemids' the newest values come first unless a sort is given, so 'limit' keeps the latest ones. Identifiers come first: an item ID cannot be derived from a host name or a metric name, it has to be looked up. Resolve it with item_get (hostids or a host filter plus search on key_ or name; output itemid, name, key_, value_type, units), then pass the IDs as 'itemids' and the item's value_type as 'history'. For one item known by host name and key, item_history_summary_get does the lookup itself and returns the values with min / avg / max in one call.

Retrieve trend data (hourly aggregated min/avg/max values). Trends are calculated from history and provide a compact, long-term view of metric behaviour. Each record covers a one-hour period and includes the minimum, average, and maximum values as well as the number of values collected. Use trends instead of history for time ranges spanning days or more to reduce data volume. Filter by 'itemids' and use 'time_from' / 'time_till' to bound the time range. The item IDs have to be looked up first with item_get (output itemid, name, key_, value_type, units); only numeric items (value_type 0 or 3) have trends. trend.get cannot sort: the hours come oldest first, so a 'limit' keeps the start of the period; bound the period with 'time_from' / 'time_till' instead.

Retrieve events generated by triggers, discovery rules, or autoregistration. Events form the full audit trail of state changes. For active/current problems only, prefer problem.get instead. Use event.get when you need the complete event history including resolved events, or when you need to correlate PROBLEM and OK events. Filter by 'source' (0=trigger, 1=discovery, 2=autoregistration, 3=internal) and 'object' to narrow results. Use 'time_from'/'time_till' for time-bounded queries and 'severity_min' to filter by importance. The newest events come first unless a sort is given, so 'limit' keeps the latest ones.

Low-level audit retrieval of unresolved Zabbix problems. Returns raw rows with numeric severities and Unix timestamps, no host name, no severity label. For an operator chat question ('what is wrong right now', 'active problems', 'current alerts', 'real problems') call problem_active_get instead -- it returns the same problems but with disabled-trigger/host noise dropped, host names attached, and human-readable time/severity, so the LLM does not have to post-process or chain three tools. Reach for problem_get only when you specifically need raw rows for a script, a bulk audit of every problem (including stale ones), or filters problem_active_get does not expose ('acknowledged', 'suppressed', 'recent', 'time_from', 'time_till'). For historical events (including resolved), use event.get instead. The newest problems come first unless a sort is given.

Retrieve network maps (sysmaps). Maps provide a visual topology view of your infrastructure, showing hosts, host groups, triggers, and the connections between them. Maps can contain elements (hosts, groups, images, triggers) and links (connections with status indicators). Use 'selectElements' and 'selectLinks' in the filter to include map structure details.

Retrieve tasks. Tasks are internal Zabbix work items such as diagnostic data collection requests or item value checks. Use this to monitor the status of previously created tasks.

Retrieve SLA definitions. SLAs measure service availability against defined targets (e.g. 99.9% uptime). Each SLA has a schedule, SLO (Service Level Objective) percentage, and is linked to services via service tags. Use selectServiceTags, selectExcludedDowntimes, and selectSchedule in extra_params to include related objects.

Get SLA Service Level Indicator (SLI) data — the actual calculated availability percentages for services covered by an SLA. Returns period-by-period SLI values showing whether the SLO target was met. Required: 'slaid'. Optionally filter by 'serviceids' and time range with 'period_from'/'period_to', or ask for a number of 'periods'.

Retrieve business services: the service tree whose status is computed from problems matched by problem tags and propagated along parent / child links (algorithm, weight, propagation_rule), with SLAs attached via service tags. Filter by serviceids, parentids (deep_parentids=true for the whole subtree), childids, tags, problem_tags or slaids. Use selectParents, selectChildren, selectTags, selectProblemTags, selectProblemEvents, selectStatusRules and selectStatusTimeline in extra_params to include related data. Before Zabbix 6.0 services were trigger-based (triggerid, goodsla, showsla) and the SLA lived here; since 6.0 the SLA is sla_get / sla_getsli.

Retrieve hosts. Hosts are the core monitored entities in Zabbix - they represent servers, VMs, network devices, or any other resource you monitor. Each host belongs to one or more host groups, can be linked to templates, and contains items, triggers, and graphs that define what is monitored and how.

Retrieve host groups. Host groups are used to logically organize hosts and to control access permissions. Every host must belong to at least one host group. Groups can also be used to filter when retrieving hosts, items, triggers, etc.

Retrieve host interfaces. Each host can have multiple interfaces (agent, SNMP, JMX, IPMI) that define how Zabbix connects to the host for data collection. Items are bound to specific interfaces.

Retrieve items. Items are the individual data collection points in Zabbix - each item gathers a specific metric from a host (CPU usage, memory, disk space, etc.). Items belong to hosts and are bound to a host interface. Trigger expressions reference items by their keys to define alerting conditions.

Retrieve triggers. Triggers define conditions (expressions) that evaluate item values and determine when a problem exists. Each trigger references one or more items via an expression like 'last(/host/key) > 90'. Triggers have severity levels (0-5) and generate events when their state changes. The expression comes in the form the update tool takes, functions written out and user macros kept ('avg(/host/key,10m)>{$MAX}'; Zabbix 5.4 and later, before that Zabbix's own expansion). extra_params expandExpression: true asks Zabbix for its own expansion instead, with every user macro replaced by its current value: for reading, never for sending back (the trigger would lose its macros); false returns the stored form with function IDs.

Retrieve graphs. Graphs provide visual representations of item data over time. Each graph contains one or more graph items (data series) that reference Zabbix items. Graphs belong to hosts or templates.

Retrieve graph items (read-only). Graph items are the individual data series within a graph. Each graph item links a Zabbix item to a graph, specifying color, draw style, sort order, and Y-axis side.

Retrieve templates. Templates are reusable sets of items, triggers, graphs, and discovery rules that can be linked to one or more hosts. When a template is linked to a host, all of its entities are automatically applied to that host. Templates belong to template groups and can be nested (linked to other templates).

Retrieve template groups. Template groups organize templates in the same way that host groups organize hosts. They are used for access control and logical grouping.

Retrieve Low-Level Discovery (LLD) rules. LLD rules automatically discover entities on a host (filesystems, network interfaces, SNMP OIDs, etc.) and create items, triggers, and graphs from prototypes for each discovered entity. LLD rules are special items that return JSON describing the discovered entities.

Retrieve item prototypes. Item prototypes are templates used by LLD rules to create real items for each discovered entity. For example, a filesystem discovery rule uses an item prototype to create disk space items for each discovered mount point.

Retrieve trigger prototypes. Trigger prototypes are used by LLD rules to create real triggers for each discovered entity. Their expressions reference item prototypes and use LLD macros. The expression comes in the form the update tool takes, functions written out and user macros kept ('avg(/host/key,10m)>{$MAX}'; Zabbix 5.4 and later, before that Zabbix's own expansion). extra_params expandExpression: true asks Zabbix for its own expansion instead, with every user macro replaced by its current value: for reading, never for sending back (the trigger would lose its macros); false returns the stored form with function IDs.

Retrieve graph prototypes. Graph prototypes are used by LLD rules to create real graphs for each discovered entity, visualizing data from item prototypes.

Retrieve host prototypes. Host prototypes are used by LLD rules to automatically create new hosts for each discovered entity (e.g., VMware VMs discovered on a hypervisor). Each host prototype defines the groups, templates, and interfaces for the discovered hosts.

Retrieve LLD rule prototypes (Zabbix 7.4+). LLD rule prototypes allow discovery rules to be created on hosts that are themselves discovered by a parent LLD rule, enabling multi-level (nested) discovery.

Retrieve user macros. User macros are custom variables ({$MACRO}) that can be defined globally or on individual hosts/templates. They are used in item keys, trigger expressions, and other places to make configuration reusable and environment-specific. Host-level macros override global macros of the same name.

Retrieve value maps. Value maps translate numeric item values into human-readable strings (e.g., 0 -> 'Down', 1 -> 'Up'). They are defined on hosts or templates and referenced by items for display purposes.

Retrieve maintenance periods. Maintenance windows suppress problem notifications and optionally pause data collection for specified hosts or host groups during scheduled downtime (e.g., patching windows).

Retrieve event correlations. Correlations define rules for automatically closing related problem events. For example, a correlation can close all 'service down' problems when a 'service up' event is received. Deprecated since Zabbix 8.0 in favour of complex event processing (ceprule_get); it still works there.

Retrieve network discovery rules. Network discovery rules define IP ranges and checks (SNMP, agent, ICMP, etc.) used to automatically find new hosts on the network. Discovered hosts and services are stored as dhost/dservice objects.

Retrieve discovery checks (read-only). Discovery checks are the individual tests (SNMP, agent, ICMP ping, TCP port, etc.) defined within a network discovery rule. Each discovery rule contains one or more checks.

Retrieve discovered hosts (read-only). Discovered hosts are hosts found by network discovery rules. Each discovered host may have one or more discovered services (dservice) representing the checks that succeeded.

Retrieve discovered services (read-only). Discovered services represent individual checks (ports, protocols) that responded on a discovered host. They belong to discovered hosts (dhost) and are created by network discovery rules (drule).

Retrieve web scenarios (HTTP tests). Web scenarios perform multi-step HTTP checks against web applications, verifying availability, response time, and expected content. Each scenario contains ordered steps and automatically creates web-monitoring items on the host.

Export Zabbix configuration as YAML, XML, or JSON. Use this to back up or transfer hosts, templates, and other objects between Zabbix instances. Params: {"format": "yaml"|"xml"|"json", "options": {"hosts": ["id"], "templates": ["id"], "host_groups": ["id"], ...}}. Option keys: host_groups, hosts, images, maps, mediaTypes, template_groups, templates, and on Zabbix 8.0+ also dashboards and global_regexes.

Compare import data with existing Zabbix configuration without applying changes. Returns a diff showing what would be created, updated, or deleted. Useful for dry-run validation before an actual import.

Retrieve actions that define automated responses to Zabbix events. Actions tie conditions (e.g. trigger severity, host group membership) to operations (e.g. send message, execute script, close problem). Filter by event source to narrow results: 0=trigger, 1=discovery, 2=autoregistration, 3=internal, 4=service. Use selectOperations, selectRecoveryOperations, selectUpdateOperations in the output to include the full operation definitions.

Retrieve the alert log -- a read-only record of every notification and remote command Zabbix has executed as a result of actions. Each alert entry contains delivery status, retry count, error text (if failed), and the message body. Use time_from/time_till to scope by time window. Great for diagnosing 'why didn't I get notified?' issues. The newest alerts come first unless a sort is given.

Retrieve notification media types configured in Zabbix. Media types define how notifications are delivered: Email, SMS, webhook (Slack, PagerDuty, Teams, etc.), or custom scripts. Each media type has its own set of parameters such as SMTP settings, webhook URL, or script path. Use this to list available notification channels or diagnose delivery configuration.

Retrieve global scripts configured in Zabbix. Scripts can be executed on hosts manually or as action operations. Types include custom script (0), IPMI (1), SSH (2), Telnet (3), webhook (5). Each script has a scope (action operation, manual host action, manual event action) and host group permissions. Use groupids/hostids to find scripts available for specific targets.

Get scripts available for the given events. Returns a mapping of event IDs to the scripts that can be executed in each event's context. Useful for building dynamic script menus in event detail views.

Get scripts available for the given hosts. Returns a mapping of host IDs to the scripts that can be executed on each host. Takes into account host group permissions and script scope. Useful for building dynamic script menus in host detail views.

Retrieve Zabbix user accounts. Each user has a username, role, assigned user groups, and optionally configured media (notification addresses). Use selectMedias, selectUsrgrps, selectRole in the output to include related objects. Filter by usrgrpids to find members of a specific group, or by mediatypeids to find users reachable via a particular notification channel.

Check whether a session is still valid. Returns the authenticated user's details if so. Requires auth_sessionid to be set to a session id (typically from a prior user.login); the configured server credentials (api_token or username/password) cannot validate against the session table.

Retrieve user groups. User groups are the primary mechanism for assigning permissions in Zabbix -- each group has a set of host group permissions (read, read-write, deny) and frontend/API access settings. Use selectRights to see the permission mappings, selectUsers to include group members, and selectTagFilters for tag-based permissions.

Retrieve configured user directories (LDAP or SAML identity providers). User directories enable centralized authentication and automatic user provisioning from external identity stores. Each directory defines connection parameters, attribute mappings, and user group assignments.

Retrieve user roles. Roles define what a user can do in Zabbix via granular RBAC rules: which UI sections are visible, which API methods are allowed, and what actions (acknowledge, close, suppress) are permitted. Built-in roles: Super admin (type=3), Admin (type=2), User (type=1), Guest (type=4). Use selectRules to include the full permission rule set for each role.

Retrieve API tokens. Tokens provide persistent authentication for scripts, integrations, and service accounts without requiring user.login sessions. Each token is bound to a specific user and inherits that user's permissions. Tokens have optional expiry dates and can be enabled or disabled independently.

Get the global authentication settings. Returns the server-wide configuration for authentication methods: internal auth, LDAP defaults, SAML settings, HTTP authentication, password complexity requirements, login attempt limits, and MFA enforcement. This is a singleton object -- there are no IDs to filter by.

Get autoregistration settings. Returns the global configuration for automatic host registration: the PSK identity and key used for encrypted autoregistration, and the TLS accept mode. This is a singleton object with no filtering options.

Retrieve icon maps used on network maps. Icon maps automatically assign icons to map elements based on host inventory field values. For example, map a host's 'type' inventory field so that routers, switches, and servers each display a distinct icon. Use selectMappings to include the mapping rules in the response.

Retrieve images stored in Zabbix. Images are used as icons for map elements and as backgrounds for network maps. Two types exist: 1 = icon, 2 = background. By default the image data (base64-encoded) is included in the response; use 'output' to limit returned fields if you only need metadata.

Get global Zabbix server settings. Returns the singleton settings object containing: default theme, server name, frontend URL, alert notification timeout, severity name overrides, severity colors, custom color settings, login and session parameters, and various other global defaults. No filtering options -- returns the full object.

Retrieve global regular expressions. These named regexp objects are reusable across Zabbix -- referenced in LLD (Low-Level Discovery) rules to filter discovered entities, in trigger expressions, and elsewhere. Each regexp can contain multiple test expressions with different match types (character string included, result is TRUE/FALSE, etc.). Use selectExpressions to include the test expressions.

Retrieve registered frontend modules. Modules extend the Zabbix web interface with custom pages, dashboard widgets, or other UI components. Each module has a status (enabled/disabled) and metadata about its ID, relative path, and configuration.

Retrieve event connectors. Connectors stream Zabbix events to external systems in real time, enabling SIEM integration, custom event pipelines, and third-party alerting. Each connector defines a URL endpoint, data format, authentication, and filtering rules for which events to forward.

Retrieve audit log entries (read-only). The audit log records every configuration change and login/logout event in Zabbix, including who made the change, when, what object was affected, and the old/new values. Essential for security auditing, compliance, and forensic investigation. Use time_from/time_till to limit the time window and userids to focus on a specific user's activity. Results can be large -- always use limit or time filters. The newest entries come first unless a sort is given, so 'limit' keeps the latest ones.

Get housekeeping settings. Returns the global configuration that controls automatic cleanup of old data: history storage period, trend storage period, event and alert retention, session cleanup interval, and audit log retention. This is a singleton object.

Retrieve Zabbix proxies. Proxies collect monitoring data on behalf of the Zabbix server, enabling distributed monitoring across network segments, firewalls, and geographic regions. Each proxy has a mode (0=active, 1=passive), connection settings, and a list of assigned hosts. Use selectHosts to include assigned hosts (extra_params), selectInterface for connection details on releases before 7.0.

Retrieve proxy groups. Proxy groups provide high availability and load balancing for data collection by grouping multiple proxies. Hosts assigned to a proxy group are automatically distributed among the group's proxies, and failover occurs if a proxy becomes unavailable. Use selectProxies to include the group's member proxies.

Retrieve multi-factor authentication methods configured in Zabbix. MFA methods define the second factor required at login: TOTP (time-based one-time password via apps like Google Authenticator) or Duo Universal Prompt. MFA methods are assigned to user groups to enforce per-group MFA requirements. Use this to audit which MFA methods are available and their configuration.

Retrieve CEP rules (Zabbix 8.0+ complex event processing): the rules that match incoming problem events by name, tags, severity, host, host group or time period, collect them in a time or count window (window_type 0 none, 1 simple window, 2 cause / symptom, 3 simple window once, 4 pattern match) and run operations on them (close, discard, set or change severity, suppress, add / set / rename / remove tags, copy as a new event, close the window). Use selectFilter, selectWindow and selectOperations in extra_params for the full rule; 'error' carries the server's last processing error. Zabbix 8.0 deprecates event correlation (correlation_*) in favour of these rules.

Retrieve the dashboards a host has through its linked templates (Zabbix 7.0+): one record per host and template dashboard with hostid, dashboardid, name, display_period, auto_start and the templateid it comes from. 'hostids' is required. Use selectPages in extra_params for the pages and widgets as resolved for that host. For the template dashboards themselves use templatedashboard_get, for global dashboards dashboard_get. Not documented in the API reference.

Retrieve OpenTelemetry (OTel) APM traces (Zabbix 8.0+): one record per trace, with the service_name and span_name of its root span, duration in nanoseconds (from the start of its first span to the end of its last), status_code, span_count, error_count, has_root_span, resource and span attributes. time_from and time_till are required and bound the start of the trace: of its root span or, for a trace whose root span is not stored (has_root_span 0), of its earliest span. Filter by traceids, resource_attributes / span_attributes conditions, or min_duration / max_duration. Page with limit and offset. Use apmspan_get for the spans of a trace and apmlog_get for its log records. For a user who is not Super admin the result is limited to the data whose resource attributes match an APM filter of one of the user's groups (usergroup 'apm_filters').

Retrieve OpenTelemetry (OTel) APM spans (Zabbix 8.0+): the individual operations inside traces, with parent_spanid, span_kind, duration in nanoseconds, status, events and links. time_from and time_till are required and bound the span start. Filter by traceids (all spans of a trace), spanids, parent_spanids, attribute conditions or duration. Page with limit and offset. For a user who is not Super admin the result is limited to the data whose resource attributes match an APM filter of one of the user's groups (usergroup 'apm_filters').

Retrieve OpenTelemetry (OTel) APM log records (Zabbix 8.0+): logs with severity_text, severity_number, body, service_name, and the trace / span they were produced in. time_from and time_till are required. Filter by traceids, spanids, trace flags (with_flags_on / with_flags_off, sum of flag values), severity_numbers (0 to 24, through extra_params) or resource / scope / log attribute conditions. Page with limit and offset. For a user who is not Super admin the result is limited to the data whose resource attributes match an APM filter of one of the user's groups (usergroup 'apm_filters').

Retrieve OpenTelemetry (OTel) APM metric data points (Zabbix 8.0+): metrics by type (0 gauge, 1 sum, 2 histogram, 3 exponential histogram) with metric_name, unit, service_name, value fields and attributes. time_from and time_till are required. Filter by types, flags (with_flags_on / with_flags_off) or resource / scope / data point attribute conditions. Page with limit and offset. For Zabbix item history use history_get instead. For a user who is not Super admin the result is limited to the data whose resource attributes match an APM filter of one of the user's groups (usergroup 'apm_filters').

Retrieve paired mobile devices (Zabbix 8.0+): the Zabbix mobile app installations that users onboarded, with the owning userid, device name, status, activated_at and lastaccess. Filter by deviceids, userids, roleids or usrgrpids. Use device_offboard to revoke a device.

Retrieve information about a Zabbix server instance (Zabbix 8.0+): its serverid and lastaccess, the time of its last update to the database (for an HA cluster the active node's). serverid is required: the server's UUIDv7, returned as 'serverid' by settings_get (8.0+) and shown in the frontend under Reports / System information. For the API version use apiinfo_version, for HA nodes hanode_get, for queue and status health_check.

Return the version of the Zabbix API, which is the version of the Zabbix frontend (e.g. '7.4.14'). Takes no parameters. Use it to pick version-specific tools and parameters; health_check reports the same version for every configured server at once.

Check the health of the MCP server and its connections to Zabbix servers. Returns the connectivity status of each configured Zabbix server.

Render a Zabbix graph as a PNG image. Returns a base64-encoded data URI that multimodal AI models can display and interpret directly. Use graph_get to find graph IDs first.

Detect anomalous hosts by comparing metric values across a host group. Uses z-score analysis on trend data to find hosts that deviate significantly from the group average. Requires at least 2 hosts with data.

Needs identifiers resolved beforehand: a host group ID (hostgroup_get) or a host ID (host_get), and an item key that exists on those hosts (item_get).

Forecast when a metric will reach a threshold using linear regression on historical trend data. Returns predicted date, daily growth rate, and R-squared confidence. Useful for capacity planning (disk, CPU, memory).

Needs identifiers resolved beforehand: the host ID (host_get) and the key of a numeric item that exists on that host (item_get with hostids).

Find items whose current lastvalue is above or below a numeric threshold.

Fetches all items matching the query via item.get, filters client-side by lastvalue, and returns sorted results. Non-numeric lastvalues are skipped. Replaces manual item_get + float(lastvalue) post-processing.

Typical uses:

• SNAT pool utilization above 50%: search={"key_": ".usage"}, lastvalue_ge=50

• Interface discard counter above 0: search={"key_": "discards"}, lastvalue_gt=0

• Disk usage near capacity: search={"key_": "pused"}, lastvalue_ge=80

Which key carries a metric depends on the templates in use (memory may be 'vm.memory.utilization', 'vm.memory.size[pused]' or 'vm.memory.size[pavailable]'; a disk has one 'vfs.fs.size[,pused]' item per filesystem). A key fragment must come from the items that exist: when it is not known, look first with item_get (search on name or key_, output itemid, name, key_, units, value_type) and use the key_ it returns. The threshold is compared with lastvalue as stored, so check 'units' (a percentage versus bytes).

Returns {"scanned": N, "matched": M, "returned": R, "items": [...]} sorted by lastvalue. matched = total passing threshold; returned = items included (may be less if result_limit set).

Real, actionable problems right now -- the PRIMARY tool for an LLM asked "what is wrong on the Zabbix server?".

Returns only problems where BOTH the trigger AND the host are enabled, with severity Warning (2) or above. Skips the noise that problem_get would return: stale alerts on disabled triggers, problems on hosts that were taken out of monitoring but not deleted, and Information / Not classified events that operators do not act on.

Each problem comes back with the host name, severity_label ("warning", "high", "disaster", ...), and time rendered as a human-readable UTC string. Use this whenever the operator asks "active problems", "current issues", "what is firing", "real problems", or "skip disabled".

For an unfiltered raw view (e.g. to also see stale problems), use problem_get instead.

Returns {"problems": [...], "count": N, "filtered_out": M} where filtered_out = problems dropped due to disabled trigger/host.

Single-call host status: identity + interfaces + monitored-state + active problems (severity Warning+, with disabled-trigger/host filtered out) + last 8 item values, in one self-contained JSON payload.

Use this whenever an operator asks 'what is the status of ?' or 'what is wrong on ?'. Replaces the typical 3-4 tool chain (host_get + hostinterface_get + problem_get + item_get) so a one-shot LLM prompt can answer without follow-up tool calls.

Host group health roll-up: member-host counts (total / enabled / with-problems) + active-problem severity breakdown + top-N most-problematic hosts inside the group, in one call.

Use this for 'how is the doing?' / 'give me a daily health report for ' style prompts. Replaces hostgroup_get + host_get(groupids=) + problem_get(hostids=) chain.

Requires the group: pass its exact name as 'group' (no lookup needed) or its ID as 'groupid'. Without either the call is refused; for all groups at once use infrastructure_summary_get.

Whole-Zabbix dashboard summary: host / item / trigger / template counts + active-problem severity breakdown + top-N most-problematic hosts, in a single call.

Use this for 'show me the overall status' / 'is everything OK?' / 'how many problems do we have right now?' style first-look prompts. Replaces five separate count + filter calls and the LLM correlation step that local models often get wrong.

Item metadata + last-N data points + min/max/avg statistics, in one call.

Use this for 'what was the average load on over the last hour?' / 'show me memory usage trend on '. Replaces the item_get + history_get + manual statistics loop the LLM has to write to answer trend questions.

Requires the item: its ID, or the host name together with the exact item key. The key is not derivable from the question ('memory usage' may be vm.memory.utilization, vm.memory.size[pused], ...): when it is not known, call item_get first (hostids or host filter, search on name or key_, output itemid, name, key_, units, value_type) and pass the itemid it returns.

Generate a PDF report from Zabbix monitoring data. Supported report types: availability (SLA/uptime), capacity_host (CPU/memory/disk), capacity_network (bandwidth/traffic), backup (daily success/fail matrix).

Returns a link, not the document, so a multi-megabyte PDF never enters the conversation: always a zabbix://reports/<id> MCP resource, and - when the operator configured a public address for this server - a download_url any browser can open. Give the user the download_url when it is there; when it is not, the response says why in download_url_unavailable and the resource link still holds the file. Links expire (an hour by default). Pass as_link: false for the old inline base64 data URI - only practical for small reports.

Two further deliveries exist when the operator enabled them: save_to_file: true writes the PDF into the server's configured report directory, and email_to: "ops@example.com" mails it as an attachment. Both answer with a short receipt (path / recipients / size) and are refused with a clear message when not configured.

Long-running (5-30 s typically). Clients that support the MCP tasks extension may invoke this with task: {ttl: 60000} to get a task handle and poll tasks/get instead of holding a single long HTTP request - useful when fronted by a proxy with short timeouts.