AICEBERG: A Novel Agentic AI Framework for Autonomous Radio Monitoring, Compliance and Governance Based on LLM, MCP, and SCPI in Smart Cities

Highlights

What are the main findings?

• An Agentic AI architecture integrating LLM, MCP, and SCPI enables secure natural language-driven control of RF spectrum analyzers.
• A dual-server design (execution + safety validation) ensures deterministic hardware interaction while maintaining operational security and parameter compliance.

What are the implications of the main findings?

• The proposed approach reduces human dependency and technical expertise requirements in urban RF spectrum monitoring.
• The architecture supports scalable deployment in distributed smart city infrastructures for autonomous and secure electromagnetic surveillance.

Abstract

Urban radio spectrum monitoring is becoming increasingly complex due to the rapid growth of wireless devices, unauthorized emissions, and dynamic electromagnetic environments in smart cities. Traditional spectrum analysis approaches, based on manual operation or static detection techniques, are no longer sufficient to ensure scalable, autonomous, and secure monitoring. The convergence of two emergent technologies—Large Language Models (LLMs) and the Model Context Protocol (MCP)—facilitates a fundamental shift in radio monitoring. We define this as the AICEBERG paradigm: a novel, stratified architecture where a high-level, intelligent agentic interface (the peak) abstracts the underlying complexity of SCPI-driven hardware integration and radio governance protocols (the foundational base). This autonomous framework provides the necessary objective rigor to audit the stochastic ‘ocean of electromagnetic waves’ characteristic of modern smart cities, ensuring a stable platform for regulatory enforcement amidst high-density signal interference. The proposed system implements a three-layer processing flow, enabling high-level natural language commands to be translated into validated and secure hardware actions on RF spectrum analyzers. A dual-server design separates operational execution from safety validation, ensuring controlled SCPI command handling, parameter verification, and instrument health monitoring. Experimental validation demonstrates the feasibility of autonomous measurement execution. The results show that the proposed architecture reduces human dependency, enhances reproducibility and lowers the expertise barrier required for RF spectrum surveillance. To the best of our knowledge, AICEBERG represents one of the first integrated frameworks to bridge LLMs with SCPI-compliant hardware through the MCP for autonomous radio governance.

1. Introduction

In the context of the development of smart cities, monitoring and efficient management of spectral resources becomes an essential component for ensuring the quality of communication services and reducing radio interference [1]. From a radio spectrum perspective, contemporary urban environments are characterized by hyper-connectivity and spectral congestion, driven by a massive density of heterogeneous devices spanning multiple generations and technological standards. To this complexity are added unintentional parasitic emissions, unauthorized intentional interference, and sophisticated cyber-electronic warfare threats targeting critical radio infrastructure [2]. When analyzed alongside the stringent requirements of 6G, specifically extreme speed, hyper-low latency, dynamic resource management, and native AI integration, it becomes evident that a paradigm shift in radio monitoring, auditing, and governance is mandatory [3]. Conventional methodologies, despite high-performance hardware and expert human intervention, are proving increasingly inadequate to meet the efficiency and scalability demands of next-generation smart cities.

Traditionally, radio spectrum analysis has been performed manually or with expensive dedicated equipment, requiring human presence and subjective interpretation. This approach is limited in the current context of smart cities, which require autonomous, scalable solutions integrated into distributed sensor networks. Classical methods of detecting radio signals in the electromagnetic spectrum, such as energy detection, matched filtering, and cyclostationary detection, have been the basis of spectral surveillance systems for decades [4,5,6,7,8,9]. Overall, classical methods remain relevant due to their maturity, but require adaptations to cope with modern spectral dynamics in urban environments. Their performance decreases in scenarios with intense RF traffic or unauthorized emissions, and the need for human intervention and technological limitations make them difficult to adapt for automatic and real-time monitoring.

Automated radio spectrum monitoring is an active research area at the intersection of radio engineering, signal analysis, and the development of smart AI solutions for urban environments. Advances in machine learning (ML) and deep learning (DL) have led to the development of modern spectral analysis methods that can overcome the limitations of classical approaches [10]. Algorithms such as k-Nearest Neighbors, Support Vector Machines, or Random Forest can learn to identify complex spectral patterns, using features such as band shape, power distribution, or subtle cyclical relationships [11,12,13]. In addition, deep learning models such as convolutional networks (CNN) or recurrent networks (RNN) can directly process the spectrogram or raw amplitude vectors, automatically extracting relevant features and providing increased robustness to noise and temporal variations [14,15]. However, modern methods involve high training data requirements, increased computational resources, and require careful validation to avoid overfitting. Thus, to be able to address these aspects of spectrum sensing in the urban environment, a solution is needed that allows for high-precision measurements and that is oriented towards distributed systems with urban relevance.

For the automated radio spectrum monitoring, the field instrumentation, such as spectrum analyzers and signal analyzers, are typically controlled via the Standard Commands for Programmable Instruments (SCPI) protocol. SCPI provides a standardized, text-based command hierarchy that enables deterministic remote control of measurement equipment. Although robust and widely adopted, SCPI-based automation requires detailed knowledge of instrument command trees, manual scripting, and explicit parameter management [16]. This approach introduces rigidity, limits scalability, and makes dynamic measurements difficult, especially in distributed or adaptive monitoring environments.

In parallel, recent advances in Large Language Models (LLMs) have demonstrated remarkable capabilities in natural language understanding, structured output generation, and tool invocation. Modern LLM-based systems can translate high-level semantic instructions into structured machine-readable actions, opening new possibilities for human–machine interaction [17,18]. However, while LLMs have been extensively explored for conversational artificial intelligence (AI), code generation, and data analysis, their integration with physical hardware control remains largely underexplored, particularly in safety-critical instrumentation environments.

A key challenge in combining LLM reasoning with hardware control lies in ensuring safety and execution reliability. Generative AI systems inherently produce probabilistic outputs, whereas instrument control requires strict parameter validation, bounded operational domains, and predictable behavior. Without proper architectural separation between semantic reasoning and low-level execution, the risk of misconfiguration, unsafe commands, or unintended hardware states becomes non-negligible.

To address these limitations, this paper proposes a structured, multi-layer architecture that integrates a Large Language Model with a Model Context Protocol (MCP) framework for deterministic SCPI-based instrument control, called AICEBERG—Agentic AI Compliance Engine for Band Enforcement and Radio Governance, as seen in Figure 1.

Figure 1. The AICEBERG paradigm for autonomous radio governance.

The architecture separates semantic reasoning from hardware execution by introducing dedicated MCP servers that encapsulate executable tools, contextual resources, and safety constraints. The system is designed to support controlled natural language interaction while enforcing strict schema validation and operational boundaries prior to hardware execution. The peak (LLM-driven interface) provides high-level reasoning, while the submerged foundation (SCPI-compliant engine) handles the technical complexity of hardware interaction. The MCP bridge acts as the critical link, enabling the system to navigate and audit the stochastic ‘electromagnetic ocean’ of smart city environments.

AICEBERG represents a hierarchical radio governance architecture that operates with an Agentic AI, using native advanced processing through LLM for continuous analysis of spectral data flows, validating the Compliance of signals with the regulations imposed by the National Authority for Management and Regulation in Communications (ANCOM) [19] and the International Telecommunication Union, having, as its core, a processing Engine based on MCP orchestration, explicitly focused on the RF radio frequency spectrum Band, capable of active detection and automatic reporting of deviations from licensing conditions; Enforcement, operating directly in the physical environment through a Radio spectrum analyzer, with the ultimate goal of regulated and optimized management of spectral resources; Governance, in accordance with the national regulatory framework.

Unlike classical SCPI scripting approaches, which require manual coding and domain expertise [16], and unlike ML/DL spectrum classifiers, which operate on pre-captured data without hardware control capabilities [10,14,15], AICEBERG uniquely bridges the semantic reasoning layer of LLMs with deterministic, safety-validated hardware execution via MCP. To the best of our knowledge, AICEBERG is the first framework to operationalize the full pipeline from natural language intent to physical spectrum measurement within a formally validated, hardware-loop agentic architecture.

The structure of the paper is as follows: in Section 2, we present the relevant information about SCPI, LLM, and MCP that was used for the implemented experiment, followed by the system architecture in Section 3. Experimental results are discussed in Section 4, and the resulting discussions, from the perspective of advantages and limitations, are presented in Section 5. The conclusions and future directions are presented in Section 6.

2. Background and Enabling Technologies

2.1. Standard Commands for Programmable Instruments (SCPI)

The Standard Commands for Programmable Instruments (SCPI) is an industry standard used for controlling and configuring programmable measuring instruments. The protocol is based on ASCII commands organized hierarchically, in the form of a command tree, which reflects the internal functional structure of the equipment. SCPI is independent of the physical transport interface, and can be used via GPIB, USBTMC, Ethernet or other communication media. The fundamental principle of SCPI consists of directly mapping the configuration parameters of the instrument to deterministic text commands [20].

The major advantage of SCPI lies in the determinism of execution: for a valid command, the instrument will always produce the same effect on the internal configuration. In addition, standardization allows interoperability between equipment from different manufacturers. However, this model has significant limitations in the context of advanced automation. SCPI does not provide a higher semantic level; there are no native mechanisms for interpreting measurement objectives or for contextual validation of command sequences. Control is strictly command-centric, and the responsibility for logical correctness and parameter safety lies entirely with the external application.

In complex applications, such as distributed spectral monitoring or adaptive reconfiguration of measurement parameters, the direct use of SCPI requires the development of rigid scripts which are difficult to scale and generalize. Therefore, SCPI provides a robust and deterministic execution mechanism, but requires an additional layer of abstraction for integration into an intelligent and safe automatic control system.

2.2. Large Language Models (LLM)

Large Language Models (LLM) are artificial intelligence systems trained on large volumes of textual data, capable of generating and interpreting natural language with a high degree of contextual coherence. In the context of the proposed architecture, the LLM is not used for text generation, but for mapping an intention expressed in natural language into a structured and formal representation. An important evolution of these models is the tool invocation mechanism, through which the model generates outputs in structured formats [21,22]. In this way, the output of the LLM does not consist of a directly executable command, but a deterministic selection of a predefined function, together with validated parameters. This approach reduces the variability associated with probabilistic generation and allows the integration of the model into a controlled execution flow.

However, LLMs remain probabilistic systems and their use in hardware control applications requires additional constraint and validation mechanisms. Without explicit limitations, models can produce inconsistent results or interpret technical instructions ambiguously. For this reason, in the proposed architecture, the LLM is restricted to a finite set of formally defined tools and does not have direct access to the generation of SCPI commands. The role of the LLM is exclusively semantic: interpreting the user intent, extracting relevant parameters, normalizing units, and selecting the appropriate function [23]. The physical execution remains entirely deterministic and separate from the generative layer. This delimitation allows combining the flexibility of natural language interaction with the strict safety and predictability requirements of instrumental control. Consequently, the LLM does not replace traditional control mechanisms, but acts as a top layer of semantic abstraction, facilitating human–machine interaction without compromising the integrity of the hardware execution.

2.3. Model Context Protocol Architecture

The Model Context Protocol (MCP), an open-source standard released by Anthropic in November 2024 [24], is an interoperability-oriented protocol designed to standardize how a LLM interacts with external tools, services, and software applications. MCP defines a formal framework for exchanging structured messages (typically JSON-RPC messages), allowing a LLM to discover and manage external resources in a controlled manner. The main goal of MCP is to clearly separate the cognitive layer (AI model) from the operational layer (tools, databases, APIs, local systems, etc.), facilitating secure and scalable integration into agent-like architectures [25,26].

MCP operates in a client–server model, where the client is hosted by the AI model and the communication with external device or services are exposed through MCP servers. Let M be the formal system tuple of the MCP architecture:

$$\mathrm{{\rm M}}=⟨C,S,T,R,P,J⟩$$

(1)

where $C\in \left\{Claude\hspace{0.17em}Desktop\right\}$ represents the MCP client that hosts the LLM and initiates all tool-call requests, $S=\left\{s_1,s_{2,}\dots ,s_n\right\}$ is the finite set of MCP servers, each encapsulating a distinct operational domain, $T=\left\{t_1,t_{2,}\dots ,t_n\right\}$ is the set of executable tools, where each tool is a formally typed Python 3.13.5 function, $R=\left\{r_1,r_{2,}\dots ,r_n\right\}$ is the set of read-only resources, providing contextual data, accessible to the LLM, $P=\left\{p_1,p_{2,}\dots ,p_n\right\}$ is the set of prompt templates, and $J$ is the bi-directional communication function implementing JSON-RPC 2.0, carrying both tool-call requests $J_{req}$ and execution responses $J_{res}$.

The tool invocation follows the sequence expressed in Equation (2):

$$\mathrm{User}\hspace{0.17em}\mathrm{Input} P\stackrel{NLP}{\to }\mathrm{LLM}\stackrel{J_{req}}{\to }C\stackrel{route}{\to }{s}_i\stackrel{exec+R}{\to }{t}_j\stackrel{J_{res}}{\to }C\stackrel{format}{\to }\mathrm{LLM}\stackrel{NLP}{\to }\mathrm{Response} P$$

(2)

The command execution illustrates a closed-loop interaction between the user and the physical instrument. The process initiates with the semantic translation phase, where the LLM decodes the high-level natural language intent into a structured tool-call request $J_{req}$, effectively abstracting the complexity of the underlying communication protocols. This is followed by the orchestration phase, in which the MCP client manages the routing logic to the appropriate hardware interface, ensuring that the parameters generated by the model are correctly mapped to the instrument’s execution environment, $t_j$. Finally, the system completes the loop through a contextualization phase: the raw output from the hardware, $J_{res}$, is returned to the model, which synthesizes the technical data into a human-interpretable response. This end-to-end flow ensures that complex hardware interactions are treated as an exchange of information, bridging the gap between human reasoning and machine-level execution [27].

The tool-call request message, $J_{req}$, is defined in Equation (3) and defines the communication interface between the probabilistic reasoning of the LLM and the deterministic execution of the hardware:

$$J_{req}=\left\{\begin{array}{cc}\mathrm{method}:& tools\\ \mathrm{params}:& \left\{\begin{array}{c}\mathrm{name}:t_j\\ \mathrm{arguments}:{\mathrm{\Theta }}_j\end{array}\right.\end{array}\right.$$

(3)

where ${\mathrm{\Theta }}_j$ represents the parameter set for tool $t_j$. By using the $J_{req}$ structure, the system ensures that the LLM does not send raw SCPI commands, which could be erroneous, but calls predefined abstract functions. This structure allows for protocol-level validation before the message reaches the security layer, eliminating formatting errors and ensuring full interoperability between the different components of the framework.

3. System Architecture

This section presents the architectural design, implementation details, and operational methodology of the proposed LLM-orchestrated hardware control framework. The system integrates structured language model reasoning with deterministic SCPI-based instrument execution through a modular Agentic AI architecture built upon the Model Context Protocol (MCP).

3.1. Agentic AI Architectural Design

The system is implemented as a modular Agentic AI framework in which distinct MCP servers operate as specialized agents with clearly delimited responsibilities. Rather than relying on a single execution engine, the architecture distributes functionality across two independent components: an operational control (the tools server) agent and a supervisory safety agent (the safety and resources server).

The operational control agent is responsible for deterministic interaction with the RF spectrum analyzer. Its primary role is to map structured tool invocations to valid SCPI commands, manage USB communication, execute configuration or measurement queries, and parse instrument responses. Each hardware capability is encapsulated as a predefined tool with a strictly defined input schema. This ensures that every action executed on the instrument corresponds to a validated and formally described operation.

$$s_{tools}=⟨{ℂ}_{exec},{\mathrm{\Pi }}_{exec}⟩$$

(4)

where ${ℂ}_{exec}$ represents the permitted operational actions and ${\mathrm{\Pi }}_{exec}$ denotes the execution policy ensuring controlled and secure hardware access.

The supervisory agent introduces an independent safety validation layer. Before any SCPI command is generated, the requested parameters are evaluated against predefined operational constraints, including frequency limits, bandwidth boundaries, attenuation settings, and logical configuration dependencies. If the parameters fall outside the allowable operational domain, execution is halted and a structured error message is returned. By separating operational execution from safety validation, the architecture minimizes the risk of unsafe configurations and enhances system robustness.

$$s_{safety}=⟨{ℂ}_{valid},{\mathrm{\Sigma }}_{doc},{\mathrm{\Psi }}_{\sec },{\mathrm{\Pi }}_{valid}⟩$$

(5)

in which ${ℂ}_{valid}$ includes command validation and instrument health checking functions, ${\mathrm{\Sigma }}_{doc}$ comprises the authority radio regulations, official programming guide, and command reference resources, ${\mathrm{\Psi }}_{\sec }$ denotes the security-oriented prompt templates, and ${\mathrm{\Pi }}_{valid}$ defines the validation policy enforcing whitelist/blacklist control mechanisms.

This Agentic AI design mirrors principles commonly found in industrial supervisory control systems, where execution logic and protection logic are deliberately decoupled to increase reliability and modularity.

3.2. Command Validation Logic

Let $ℂ$ be a SCPI command and $W$ be the whitelist set, $B$ the blacklist set. The validation function $V:ℂ\to \left\{0,1\right\}$ is defined as:

$$V\left(ℂ\right)=\left\{\begin{array}{ll}0,\hfill & if\hspace{0.17em}\hspace{0.17em}ℂ\in B\hfill \\ 0,\hfill & if\hspace{0.17em}\neg \exists w\in W:\hspace{0.17em}\hspace{0.17em}w⊑ℂ\hfill \\ 0,\hfill & if\hspace{0.17em}\hspace{0.17em}\neg ValidateParams\left(ℂ\right)\hfill \\ 1,\hfill & otherwise\hfill \end{array}\right.$$

(6)

where $\neg$ is the “NOT” operator and $w⊑ℂ$ denotes that $w$ is a prefix of $ℂ$. The first condition verifies whether the SCPI command $ℂ$ belongs to the blacklist set $B$, in which case it is immediately rejected; then, if no prefix $w\in W$ exists such that $ℂ$ starts with an authorized whitelist prefix, the command is rejected under a default-deny policy, because the system only allows commands that start with user-authorized prefixes (e.g., :FREQ, :CALC, :TRAC, etc.). If the user or AI invents a non-existent command, it will not have a valid prefix and will be blocked. Next, the parameter validation function is evaluated, and if it returns False (e.g., due to out-of-range numerical values), the command is rejected; then, finally, if none of these conditions are triggered, the command is considered safe and execution permission is granted.

The parameter validation function is defined as:

$$ValidateParams\left(ℂ\right)=\forall p_i\in extract\left(ℂ\right),\hspace{0.17em}{p}_{\min ,i}\le p_i\le p_{\max ,i}$$

(7)

where $extract\left(ℂ\right)$ extracts numerical parameters from command $ℂ$, and $\left[p_{\min ,i},p_{\max ,i}\right]$ defines safe bounds for numerical value of $p_i$.

3.3. System Architecture Overview

The proposed framework was designed to enable controlled integration between Large Language Models and deterministic hardware instrumentation. The main objective of the architecture is to preserve the flexibility of natural language interaction while ensuring strict validation and reliable execution of SCPI-based commands. To achieve this, the system adopts a layered design that clearly separates semantic reasoning from hardware-level control.

At the highest level, the operational pipeline begins with a natural language instruction provided by the user. This instruction is processed by a Large Language Model operating in structured function-calling mode, generating a validated tool invocation encoded in JSON format. The generated parameters are subsequently verified against predefined safety constraints before being translated into SCPI commands and transmitted to the physical instrument. The instrument response is parsed and propagated back through the same structured layers to produce an interpretable result.

The complete command execution flow with validation is modeled as shown below.

In Algorithm 1, u is the raw natural language input provided by the user, $ℂ$ represents the synthesized SCPI command string generated by the LLM, v is the validation object returned by the safety server $s_{safety}$, containing the safety flag v.safe and the diagnostic v.warning, h is the hardware health status object, comprising the global state h.overall_health and specific diagnostic checks h.checks, r is the final execution result, e is the error message returned to the user in case of a security breach or hardware failure.

Algorithm 1: Secure Command Execution Protocol
Input:	Natural language command u
Output:	Execution result r or error e
1:	$ℂ$← LLM(u)
2:	$v \leftarrow s_{safety}.$validate_scpi_command($ℂ$)
3:	if v.safe = FALSE then
4:	e ← v.warning
5:	return e
6:	end if
7:	$h \leftarrow s_{safety}.$check_instrument_health()
8:	if h.overall_health ≠ HEALTHY then
9:	e ← h.checks
10:	return e
11:	end if
12:	$r \leftarrow s_{tools}.$execute_scpi_command($ℂ$)
13:	log($ℂ$, r, timestamp)
14:	return r

Formally, the process can be described as a sequence of transformations from user intent to hardware action, ensuring that generative reasoning is confined to semantic interpretation and never directly produces executable SCPI strings.

3.4. Latency Analysis Model

The latency analysis model is a formal framework used to decompose and quantify the total time required to execute an action within the proposed system, from the user’s intent to the final response of the instrument. In the context of an architecture that integrates a LLM with deterministic SCPI control, the total latency is no longer generated exclusively by the hardware, but becomes the cumulative result of several components. Latency analysis is essential because it allows the evaluation of the feasibility of the system in real applications, especially in continuous monitoring or adaptive control scenarios, where delays can affect the stability of measurements or responsiveness. The total system latency $L_{total}$ can be decomposed as:

$$L_{total}=L_{NL{P}_{in}}+L_{route}+L_{exec}+L_{comm}+L_{NL{P}_{out}}$$

(8)

where $L_{NL{P}_{in}}$ is the time for LLM to parse intent and generate the tool call, $L_{route}$ is MCP client routing decision time, $L_{exec}$ is the tool execution time on server, $L_{comm}=L_{send}+L_{recv}$ is the network latency, and $L_{NL{P}_{out}}$ is the time for LLM to generate natural language response.

4. Results

4.1. Experimental Framework for AI RF Monitoring

The experimental setup was composed of the spectrum analyzer connected to an ANT500 antenna (Great Scott Gadgets, Lakewood, CO, USA) for capturing RF signals from the ambient environment, interfaced with a PC that ran the LLM–MCP framework for the generation, validation, and controlled execution of SCPI commands. A picture of the experiment is shown in Figure 2a and equipment specifications are shown in Table 1.

Figure 2. (a) AICEBERG—implemented hardware system; (b) the three-layer architecture.

Table 1. Experimental hardware specification.

Component	Specification
Instrument	Siglent SSA3075X-Real Time Spectrum Analyzer
Frequency Range	9 kHz–7.5 GHz
Connection	USB (VISA)
Instrument	Antenna ANT500
Frequency Range	75 MHz–1 GHz
Host System	12th Gen Intel(R) Core(TM) i7-12700K (3.60 GHz), 128 GB
GPU	NVIDIA Quadro RTX 4000
OS	Windows 11 Pro
Python	3.13.5 with PyVISA 1.14.1 + FastMCP
LLM	Claude Anthropic [28]

The complete processing flow of the proposed system follows a three-layer architecture, which transforms a simple command from the user into an effective hardware action. At the first level, the LLM (in our experiment, Claude Sonnet 4.6.) interprets the user’s natural language, extracting the intent and relevant parameters for the requested operation. At the second level, the MCP ensures the correct invocation of the instruments, managing the routing and validation of calls to external functions, depending on the context and available capabilities. In the final layer, the SCPI protocol translates the validated commands into precise instructions for the hardware equipment Siglent SSA3075X-R 7.5GHz Real Time spectrum analyzer (Siglent Technologies, Shenzhen, China), executing specific measurements or configurations. The three-layer architecture of the implemented system is shown as a diagram in Figure 2b.

The two implemented servers are based on certain tools or resources, with well-defined roles, relevant for radio monitoring, compliance, and governance. The server architectures are detailed in Table 2 and Table 3.

Table 2. Tools server architecture.

Type	MCP Attributes	Responsibilities	Tools/Resources
Tools server		- Execution of SCPI commands - Direct hardware control - Save results	execute_scpi_command()
			set_marker()
			tune_to_frequency_peak()
	mcp.tool()		detect_and_save_peaks()
			enable_continuous_sweep
			………
			analyze_acpr_cnr()

Table 3. Safety server architecture.

Type	MCP Attributes	Responsibilities	Tools/Resources
Safety server		- SCPI command validation - Health monitoring - Safety checks - Access documentation	National table of frequency bands allocations SCPI Siglent programming guide
			validate_scpi_command()
	mcp.tool()		check_instrument_health()
	mcp.resource()		get_error_log()
	mcp.prompt()		check_safe_operation ()
			………
			validate_parameters_range()

The Tools server is responsible for the direct execution of SCPI commands and the actual control of the hardware, as well as for saving and analyzing the results obtained. In parallel, the Safety server ensures the validation of SCPI commands, monitoring the status of the instruments, performing safety checks and accessing relevant documentation. This separation between the execution and safety servers allows both automation and precise control of the hardware, and guarantees operation within safe parameters, reducing the risk of human error and dangerous operations.

4.2. Automated Executions

4.2.1. Nominal Command Execution

This experiment evaluates the nominal execution path of the secure command execution protocol when a valid request is provided. The safety module confirmed that the command belonged to the authorized whitelist and that all parameters were within operational limits. Additionally, the instrument health check returned a HEALTHY state. Consequently, the command was executed, and the response was logged as part of the audit trail. In Figure 3a, it is displayed as the answer provided by LLM. Also, with the response provided in the conversation, the desired changes provided in the request were automatically made on the spectrum analyzer. Figure 3b shows a screenshot of the spectrum analyzer after the request was made.

Figure 3. (a) Example response from Claude LLM for nominal command execution; (b) screenshot from the spectrum analyzer after the nominal command execution was provided.

For the answer provided, the diagram with the steps followed is shown in Figure 4.

Figure 4. The processing chart for nominal command execution.

The diagram describes the complete processing flow of the proposed system, in which the user request is initially analyzed at the LLM level for intent identification (in this case: FM band scanning, peak channel detection, and power determination), followed by the stage of selecting the appropriate software tool. The generated call is transmitted to the MCP client, where it is encapsulated in JSON-RPC format and routed to the server responsible for controlling the spectrum analyzer. The server executes the corresponding function through a sequence of SCPI commands sent to the spectrum analyzer (such as: setting the start and stop frequency, identifying the spectral maximum, querying the frequency and power level, refocusing the display). The measurement results are collected, structured into a standardized response, and retransmitted to the LLM model, which generates the final natural language response to the user, thus closing the automatic measurement loop. Table 4 summarizes the execution latency within this command.

Table 4. Latency analysis for nominal command execution.

Stage	Time (ms)
LLM Processing	540
MCP Overhead	30
SCPI/Hardware	260
Network	10
Total	840

4.2.2. Rejected Command Due to Validation Failure (Parameter Constraint Violation)

This scenario illustrates the behavior of the framework when the command violates the parameter constraints defined by Equation (8). Although the SCPI structure was syntactically valid, the validation function detected that one parameter exceeded the predefined operational bounds. As a result, the execution was aborted before reaching the hardware layer, and an explicit warning message was returned to the user. This demonstrates the enforcement of deterministic safety constraints independent of LLM probabilistic outputs. Moreover, after the warning was displayed, we gave the LLM the ability to fix the problem, allowing it to automatically correct the problem and stay within hardware limits, as seen in Figure 5.

Figure 5. Example response from Claude LLM for parameter constraint violation.

For the answer provided, the diagram with the steps followed is shown in Figure 6.

Figure 6. The processing chart for rejected command due to validation failure.

The diagram shows the complete processing flow for configuring the spectrum analyzer to a requested bandwidth of 8 GHz, highlighting the preventive validation and automatic correction mechanism. Initially, the user request is analyzed at the LLM level to extract the intent (“8 GHz span”). In the internal knowledge verification stage, the model identifies the hardware limit of the equipment (which is 7.5 GHz) and finds that it has been exceeded, triggering a two-phase strategy: validation by calling the specific function and conditional execution only if the parameters are safe. The call is routed through the MCP client to the safety server, where the validation logic checks the start frequency, stop frequency, and total span, generating a response and the list of non-conformities. Based on this result, the LLM applies a corrective decision: it explains the exceeding of the maximum limit and automatically adjusts the configuration to the maximum allowed value. The authorized SCPI commands are then sequentially executed, each passing through the whitelist/blacklist mechanism for hardware access control. Subsequently, the system interrogates the current configuration through SCPI query commands to confirm the set parameters. In the final stage, the LLM synthesizes the information received, explains the reason for the limitation, presents the configuration actually applied, and provides the user with a structured description of the spectral coverage, thus closing the validation–execution–feedback loop in a safe and autonomous operating framework. Table 5 summarizes the execution latency within this command.

Table 5. Latency analysis for rejected command due to validation failure.

Stage	Time (ms)
LLM Processing	460
Validation (Safety)	20
Command Execution	90
Query Current State	30
MCP Overhead	50
Total	650

4.2.3. Rejected Command Due to Blacklist Policy

In this experiment, the user attempted to trigger a command explicitly restricted by the security policy. The validation module identified the command as belonging to the blacklist set defined in the execution policy. According to the formal rule described in Equation (7), the command was immediately rejected, and no SCPI transmission occurred. This confirms that the framework prevents unauthorized or potentially destructive hardware operations. Such an example is shown in Figure 7.

Figure 7. Example response from Claude LLM for rejected command due to blacklist policy.

For the answer provided, the diagram with the steps followed is shown in Figure 8.

Figure 8. The processing chart for rejected command due to blacklist policy.

The diagram illustrates the mechanism for securely managing a request to save the analyzer configuration to internal memory, highlighting the interaction between the LLM model, the command control mechanism, and the hardware level. Initially, the user request is semantically interpreted at the LLM level. In the mapping stage to SCPI knowledge, the model identifies the command corresponding to saving the configuration to internal memory. The call is transmitted to the execution server via the MCP, where the security mechanism based on blacklist/whitelist validation intervenes. The command contains the prefix MMEM, which is explicitly included in the blacklist, since operations on the internal memory may affect the instrument file system or produce unwanted persistent changes. Then, the execution is blocked, and the server returns a response. Based on this result, the LLM activates the decision branch for rejected commands: it explains the reason for the blocking, identifies the risks associated with operations on the internal memory, and proposes a safe alternative solution. The alternative consists of extracting the current configuration through SCPI queries, followed by saving the parameters to an external file in JSON format. The configuration is thus serialized into a file containing both the frequency parameters and the SCPI commands required for subsequent restoration, and the file is made available to the user in downloadable form. After that, the LLM provides a structured explanation of the initial lock, describes the implemented alternative solution, and indicates how to restore the configuration later. Table 6 summarizes the execution latency within this command.

Table 6. Latency analysis for rejected command due to blacklist policy.

Stage	Time (ms)
LLM Processing	430
Security Validation	10
Get Config (SCPI)	30
Create JSON File	30
Present File	20
MCP Overhead	100
Total	620

4.2.4. Rejected Command Due to Syntax Parsing Failure

This experiment evaluates the system behavior when an invalid SCPI command is generated. The command failed syntactic validation during the parsing stage, prior to semantic or safety analysis. As defined in Equation (7), the validation function returned FALSE because the command structure did not conform to the expected SCPI grammar. Consequently, execution was blocked before reaching the hardware layer. This confirms that the framework enforces strict syntactic validation independently of parameter or policy checks. Such an example is shown in Figure 9.

Figure 9. Example response from Claude LLM for rejected command due to syntax parsing failure.

For the answer provided, the diagram with the steps followed is shown in Figure 10.

Figure 10. The processing chart for rejected command due to syntax parsing failure.

The diagram depicts the processing flow associated with an explicit request to execute an SCPI command (“ATW”) to query the attenuation level, highlighting the role of the whitelist-based validation mechanism in protecting the device. In the first stage, the user request is analyzed at the LLM level, where the intent and the specific command are identified. The model converts the expression into standard SCPI format, generating the query, and decides to use the specific function, without semantically validating the correctness of the command at this level. The call is transmitted via the MCP client to the execution server, where the two-stage security mechanism is applied: blacklist checking (for blocking of critical commands) and whitelist checking (strict control of authorized prefixes). Although the command is not included in the blacklist, it does not correspond to any of the prefixes defined in the whitelist, which leads to the explicit rejection of execution. Following the refusal, the LLM activates the authorization error handling branch: it explains the reason for the blocking, analyzes the semantic intent of the user (attenuation) and consults the SCPI knowledge base to identify valid commands associated with the desired function. Thus, correct alternatives are proposed. This scenario demonstrates the functioning of the whitelist-based control mechanism as an essential layer of security, preventing the execution of invalid or non-existent commands, even when they are explicitly formulated by the user. Table 7 summarizes the execution latency within this command.

Table 7. Latency analysis for rejected command due to syntax parsing failure.

Stage	Time (ms)
LLM Processing	150
MCP Validation	10
LLM Response Generation	380
MCP Overhead	10
Total	550

4.2.5. Rejected Command Due to Instrument Health Status

For this example, we disconnected the USB cable from the spectrum analyzer. This test evaluates the system behavior under degraded hardware conditions. Although the command satisfied syntactic and semantic validation requirements, the instrument health monitoring module reported a non-HEALTHY state. Consequently, the execution pipeline was interrupted prior to SCPI transmission, and an error message describing the detected condition was returned. This demonstrates that the proposed architecture enforces dynamic safety constraints in addition to static command validation. In Figure 11a, the LLM response in this situation is displayed. After the cable was reinserted, we repeated the request and the response provided was positive, as can be seen in Figure 11b.

Figure 11. (a) Example response from Claude LLM for rejected command due to instrument health status; (b) example response for valid command due to instrument health status.

For the answer provided, the diagram with the steps followed is shown in Figure 12.

Figure 12. The processing chart for rejected command due to instrument health status.

The diagram shows the complete processing flow of one request, which illustrates how the system manages a health check of the device and handles a critical USB connectivity failure. In the first stage, the request is semantically analyzed and the expression “check communication” is interpreted as a health check of the connection and the model selects the most appropriate instrument among those available. After that, the call is transmitted through the MCP client to the security server, where the execution of the verification function begins. Inside it, the PyVISA ResourceManager is initialized, and an attempt is made to open the USB resource based on the full address. In the hardware access phase, PyVISA queries the NI-VISA driver, enumerates available USB devices, and searches for an exact match. The process fails when the device is not found on the system. Possible causes include unplugging the USB cable, turning off the analyzer, hardware failure, or a problem with the VISA driver. The exception is caught at the safety server level, which classifies the overall status as “CRITICAL”. Upon receiving the response, the LLM signals the failure, explains the meaning of the VISA code in accessible language, and generates a structured set of troubleshooting steps. The flow demonstrates the clear separation of responsibilities between semantic interpretation of the request (LLM), technical execution and hardware interaction (safety server + PyVISA), and generation of decision support for the user. Table 8 summarizes the execution latency within this command.

Table 8. Latency analysis for rejected command due to instrument health status.

Stage	Time (ms)
LLM Processing	480
MCP Routing	10
PyVISA Error	40
Error Handling	30
MCP Overhead	10
Total	620

4.3. Quantitative Evaluation of LLM Intent Interpretation

To complement the qualitative scenario demonstrations in Section 4.2.1, Section 4.2.2, Section 4.2.3, Section 4.2.4 and Section 4.2.5, a structured quantitative evaluation was conducted to measure LLM intent interpretation accuracy and safety validation robustness. A test suite of 100 natural language commands, representative for the operational RF monitoring workflows, was designed. The evaluation metrics were: (1) correct tool selection rate—whether the LLM selected the intended tool from the available tool manifest; (2) parameter extraction accuracy—whether all extracted numerical parameters matched the ground-truth values within a tolerance of ±1 digit for frequency (Hz) and ±0.1 dB for power levels; (3) safety validation correctness—whether the Safety server correctly passed or rejected each command. The results are displayed in Table 9.

Table 9. Quantitative evaluation results.

Type	Task	Commands	Tool Selection Accuracy	Parameter Extraction Accuracy	Safety Validation Correctness
Tools server	Frequency configuration	8	100%	100%	100% pass
	Span/RBW/VBW setting	8	100%	100%	100% pass
	Marker placement	8	100%	100%	100% pass
	Power query	8	100%	100%	100% pass
	ACPR/CNR analysis	8	100%	100%	100% pass
	Configuration save/export	8	100%	N/A	100% pass
	Health monitoring	8	100%	N/A	100% pass
Safety server	Out-of-range parameters	11	N/A	N/A	100% rejected
	Blacklisted command families triggered	11	N/A	N/A	100% rejected
	Syntactically malformed SCPI commands	11	N/A	N/A	100% rejected
	Prompt injection attempts	11	N/A	N/A	100% rejected

Overall, for the tool server, the tool selection accuracy was 100%. Also, the safety server correctly rejected 100% of adversarial commands. All 11 prompt injection attempts produced tool-call outputs that were subsequently blocked by the whitelist/blacklist validation; none bypassed the MCP security layer. These results confirm that the architectural separation between LLM reasoning and hardware execution provides robust protection against both inadvertent misuse and deliberate adversarial inputs.

5. Discussion

The experiment demonstrates the feasibility of controlling hardware instrumentation through a natural language interface, using architecture based on the Model Context Protocol (MCP). The integration between the LLM, the MCP servers (tools + safety), the SCPI layer, and the physical hardware validates the possibility of building a layered system that combines semantic accessibility with robust security mechanisms.

The latency analysis highlights that the total response time for a typical query is approximately 850 ms, of which over 70% is attributed to LLM processing. The overhead introduced by the MCP is low (≈7%), and the actual SCPI/hardware execution represents less than 5% of the total latency. This result is important because it shows that the hardware does not cause analysis bottlenecks or slow down the response time. In reality, the semantic layer is the most computationally expensive. From the perspective of human–computer interaction, a latency of 850 ms falls into the acceptable category for interactive operations.

An essential aspect of the experiment is the security analysis. The implementation of a defense-in-depth model, with whitelist, blacklist, and parametric validations, significantly reduces the attack surface. Even in prompt injection or command confusion scenarios, dangerous commands are blocked at the MCP level, regardless of the LLM behavior. The theoretical probability of success of an attack becomes extremely low, which indicates that the architecture is suitable for use in environments where the integrity of configurations is critical. However, the dependence on the cloud introduces an operational vulnerability (the need for an internet connection), and possible supply chain attacks on the libraries used remain risks that must be managed through strict versioning and integrity checking.

In terms of scalability, the system is efficient for a single tool and can be extended to multiple devices by replicating the tools/safety pairs. However, the increase in the number of tools leads to increased complexity and the progressive occupation of the LLM context. Also, VISA connections are single-threaded, which limits concurrent execution. For enterprise or multi-user scenarios, a centralized gateway is required, with the additional cost of latency and a potential single point of failure.

Identified limitations include the need for manual whitelist maintenance (if different users have different opinions about what should be on the list) and the impossibility of offline use. Also, ambiguous commands or complex requests increase latency by requiring decomposition into multiple SCPI calls. Overall, the experiment confirms that the integration of NLP with hardware control is technically mature for use in education, exploratory research and interactive configuration.

Several integration frameworks exist for connecting software agents to external tools and hardware systems. Table 10 compares MCP against three representative alternatives across five criteria relevant to LLM-driven RF instrumentation: LLM-native integration, tool discovery mechanism, deterministic execution guarantee, a built-in safety/validation layer, and native support for hardware instrumentation control.

Table 10. Comparison of orchestration frameworks for LLM-driven hardware control.

Framework	LLM Native	Tool Discovery	Deterministic Execution	Safety/ Validation	Hardware Instrumentation
REST API [29]	No (custom)	No (manual)	Yes	No (custom)	Partial (custom)
ROS [30]	No (adapter needed)	Yes (topic/service)	Yes (real-time)	Partial (watchdog)	Yes
LangChain [31]	Yes	Partial	No (LLM dependent)	No	No
MCP (proposed)	Yes (native)	Yes (tool manifest)	Yes (server design)	Yes (dual-server)	Yes (SCPI/VISA)

REST APIs represent the most common approach for integration frameworks, but require custom endpoint development and lack a standardized tool-discovery mechanism. ROS is designed for robotic systems and is well-suited for multi-sensor real-time control, but is not natively LLM-aware and requires significant adaptation for natural language interfaces. LangChain lacks a standardized safety/validation layer, and it does not support hardware instrumentation control. MCP is the only framework satisfying all five criteria simultaneously.

6. Conclusions

This paper proposed and experimentally validated an Agentic AI architecture for natural language-driven hardware control in secure urban RF spectrum monitoring scenarios. By integrating a Large Language Model as a cognitive orchestration layer, the Model Context Protocol (MCP) as a structured invocation framework and SCPI as a deterministic hardware control interface, the system demonstrates a complete end-to-end pipeline from human intent to physical spectrum measurement.

The results highlight three major contributions. First, the proposed layered architecture successfully abstracts the complexity of RF instrumentation, enabling high-level natural language interaction with professional spectrum analyzers. Second, the separation between execution and validation/safety introduces a robust control mechanism that reduces operational risks and enforces secure hardware access. Third, the system shows strong potential for scalability and integration into distributed smart city sensor networks, where autonomous, remotely controlled RF monitoring is essential.

The integration of AI-driven orchestration significantly lowers the expertise barrier, allowing non-specialist operators to interact with complex RF equipment while maintaining technical rigor and operational safety.

While we acknowledge that extensive field testing in diverse and unpredictable urban RF environments remains essential, we propose AICEBERG, a pioneering semantic RF orchestrator that operationalizes the ‘Agentic-AI-in-the-Hardware-Loop (AAiHL)’ paradigm. The framework balances a streamlined Natural Language Processing (NLP) interface with autonomous, real-time, low-level hardware orchestration, providing a robust and objective foundation for autonomous radio governance within the complex, diverse, and stochastic spectral environments of modern smart cities.

Future work will focus on extending the architecture towards multi-node distributed on large-scale urban deployments, to further validate the system’s resilience against high-density spectral noise and to evaluate long-term stability in real smart city environments.