A new approach to monitoring: how a model-agnostic MCP server uses AI to connect to OpenSearch and other APIs

March 31, 2025 | relevant products: COMMOC ,  LOMOC ,  SIEMOC ,  AIR

Imagine being able to control a monitoring system simply by voice – without complex queries, CLI commands or tool hopping. This is exactly what a newly developed, modular AI Monitoring Assistant based on an MCP server makes possible.

In modern IT infrastructures, the effective monitoring of complex systems is essential to minimise downtime, identify security risks at an early stage and optimise operational processes. The integration of artificial intelligence (AI) into monitoring promises not only a deeper insight into operating conditions, but also the possibility of processing recurring requests automatically or identifying complex relationships. The approach presented here relies on a model-agnostic AI Monitoring Assistant that uses a specially developed Model Context Protocol (MCP) server to provide a flexible and extensible architecture for AI-based monitoring – with an initial focus on OpenSearch and prospects for connecting other systems such as SSH, Grafana, Icinga or ElasticSearch.

What is the MCP server – and why is it exciting?

The Model Context Protocol (MCP) server is a smart intermediary between language models and monitoring systems such as OpenSearch, SSH, Grafana or Icinga.

You enter what you want to know – for example: ‘Show me all the indices that were changed yesterday’ – and the server translates this into suitable API or shell commands. The result: you get the relevant data directly – without having to manually type queries. The best part: the whole thing is model-agnostic. Whether it's OpenAI, Mistral, Llama or a local LLM (e.g. AIR), the MCP server works with them all. This keeps your monitoring architecture flexible, secure and future-proof.

How it works: tools, queries, responses

The MCP server uses a set of tools that define, like building blocks, what the system is allowed to execute. For OpenSearch, for example, these are REST requests like etc.

_search, _cat/indices, _cluster/health

The language model selects the appropriate tool based on your input, the server executes it – and returns the response to the model. The result: real AI-powered monitoring dialogues, with validated operations and controlled execution.

1. Background: Monitoring meets AI

Classic IT monitoring is based on dedicated tools, predefined rules and often also on a variety of heterogeneous data sources – from system metrics to logs and external APIs. With the increasing prevalence of machine learning and generative AI, new possibilities are emerging not only for collecting this data, but also for processing it intelligently. Language models can be used, for example, to interpret natural language queries and automatically transmit the appropriate queries to technical systems. This is precisely where the MCP server comes in.

2. The MCP server: architecture and functionality

The central element of the solution is a so-called Model Context Protocol (MCP) server. This acts as an intermediary between a language model – whether local or in the cloud – and a set of defined tools. These tools can represent any technical interface or command pattern, such as the REST API from OpenSearch or predefined commands on an SSH server.

Model-agnostic as a core principle

A central design goal of the MCP server was model-agnosticity. This means that the server works independently of the language model used. Whether an open-source model is executed locally or a cloud-based LLM is used, the MCP server can be used in both scenarios. This independence makes it possible to use the solution in different data protection and security contexts, including in isolated corporate networks or highly sensitive areas with strict compliance requirements.

How it works in detail

The MCP server is configured with a set of tools that serve as executable operations. In the case of OpenSearch, for example, this is a collection of permissible REST requests such as and others.

GET _cat/indices, POST _search, GET _cluster/health

A prompt addressed to the language model – such as: ‘Show me all indices that have been changed in the last 24 hours’ – is translated by the language model into a specific tool call that the MCP server executes. The result is then processed and passed back to the model to generate a linguistically interpreted response if necessary. The server thus forms the bridge between natural language and technical monitoring operations. To integrate the MCP server with a language model, an MCP client is needed (e.g. the free 5ire client). This is the user interface for receiving your natural language questions and commands. The MCP server, the eyes and ears of the AIOps solution, then collects facts and performs actions.

3. OpenSearch as an entry point

The first implementation of the MCP server focuses on integration with OpenSearch, a free and high-performance search and analysis platform for structured and unstructured data. Access is via the REST-based OpenSearch API, which is mapped by the MCP server's toolset. The same API can also be used in our OpenSearch-based log monitoring LOMOC. This integration makes it possible to execute complex search queries or metric evaluations in OpenSearch with simple language entries. Examples include:

  • Querying the cluster state
  • Searching logs for specific errors
  • Analysing the largest indices in the system
  • Determining the average response times for a period

This approach also allows less technically minded users to gain deeper insights into the monitoring backend – without in-depth knowledge of query DSL or API usage.

4. Extension to other systems: SSH, Grafana, Icinga

A key advantage of the MCP server is its modularity. The abstraction via tools makes it possible to integrate any other system. In the next development step, simple SSH commands were therefore also integrated as a toolset. Particular attention is paid to security: only so-called ‘safe commands’ such as htop, free -m, ps aux or df -h are allowed.

This integration opens up new possibilities:

  • Access to server metrics via SSH to analyse bottlenecks or load distribution
  • Analysis of running processes with conspicuous behaviour Combined evaluation of log files and system status

It is also conceivable to connect to visualisation systems such as Grafana or monitoring solutions such as Icinga2 or COMMOC. Here, too, communication takes place via defined API calls or secure commands that can be executed by the language model via MCP.

5. Security aspects and governance

The use of generative AI in productive monitoring processes requires strict security and governance mechanisms. To prevent dangerous or potentially harmful commands from being executed, the MCP server implements a whitelisting logic that only allows explicitly approved tools to be executed. Any attempts to initiate unauthorised actions are detected and prevented.

In addition, the system can be operated in isolated networks, for example by combining it with locally running language models and restrictively configured toolsets. This also enables operation in environments with high data protection, compliance and operational stability requirements.

6. Real-world use cases

The practical usability of the AI Monitoring Assistant is demonstrated in a variety of application scenarios. The following are some exemplary use cases: Real-time incident analysis: When unusual behaviour patterns or system failures occur, an operator can use the language model to formulate queries immediately, e.g. ‘What errors occurred in cluster X in the last 30 minutes?’ The model translates the request into OpenSearch or SSH commands, delivers the results and, if necessary, a linguistic interpretation. Proactive capacity planning: Based on historical load values and memory usage, simple entries such as ‘Show me when memory usage was over 90% in the last 7 days’ can be used to initiate informed planning. Monitor dashboards by voice: Integration with visualisation tools such as Grafana also simplifies dashboard interaction. For example: ‘Show me the CPU dashboard for server web01 for yesterday’. Compliance checks and operating figures: Using SSH- or API-based tools, audit data can be regularly queried, system statuses documented and vulnerabilities communicated – also in natural language.

How our AI Monitoring Assistant repaired a LOMOC cluster

The initial question was why one of our LOMOC clusters was showing a yellow health status. Before we got into the details of the problem, we had the AI assistants analyse the cluster architecture:

‘Please list the nodes in my cluster.’

In the next step, we wanted to know from the AI assistant what data is stored and indexed in this cluster:

‘what indices does it have’

In answering this question, our AI assistant has already independently found out that the cluster is in ‘yellow’ status.

We ask again for the cluster status in more detail.

‘Can you check the health of lomoc cluster?’

We find this interesting – and start our ‘5-why’ approach to root cause analysis with the following why question:

‘why are there unassigned shards?’

We'll dispense with further why questions and get straight to the point – we want the problem solved:

‘what requests should I send to fix this?’

Our AI assistant automatically deduces from our question that we want to repair the cluster and offers to check the cluster status for a solution to the problem from now on.

We only address his question indirectly – but implement his suggestion:

‘I have done this now, is the health better?’

The AI Monitoring Assistant detects an improvement – the measure seems to be working.

The assistant knows that the solution may take a little longer and offers to monitor the processing.

We ask after some time:

„can you check again?"

The AI Monitoring Assistant detects an improvement – the measure seems to be working.

The assistant knows that the solution may take a little longer and offers to monitor the process.

We check up on the solution after a while:

‘Can you check again?’

The AI Monitoring Assistant has detected that the cluster is functioning correctly and kindly provides us with a summary of the initial situation: only 56.7% active shards – now 100%. It's that simple.

7. Future prospects and further development

The system presented here lays the foundation for a new class of intelligent monitoring assistants that impress with their modularity, model diagnostics and security. In the future, there will be a multitude of possibilities for expansion:

  • Integration into SIEM and SOAR platforms for automated alarm reactions
  • Self-service interfaces for non-tech users, e.g. helpdesk teams or specialist departments
  • Explainable AI (XAI) for a transparent explanation of why a certain monitoring decision or evaluation was made
  • Training of domain-specific models for particularly critical infrastructures (KRITIS)

Combining it with event correlation and AIOps platforms also opens up new horizons for autonomous operational processes and predictive error avoidance.

8. Cyber risks of MCP clients and MCP servers – and why European solutions are crucial

The operation of MCP clients and MCP servers opens up new attack surfaces within modern IT infrastructures. Since these components act as intermediaries between language models and productive systems, there is a significant cyber risk if they are misconfigured or if access control or logging is insufficient. A compromised MCP client could transmit manipulated input to a language model or trigger unauthorised actions via the server. Similarly, an insecure MCP server can be used to abuse internal APIs or command line tools with malicious queries.

It is particularly critical if these components are operated via cloud solutions or APIs whose infrastructure is located outside Europe. This increases the risk of access by third countries, insufficient encryption or state surveillance. In security-critical areas such as critical infrastructure, government agencies or finance, such scenarios are not acceptable.

The use of European MCP clients and MCP servers – developed, operated and hosted within the EU – therefore provides a significantly better security foundation. They are subject to European legislation, enable a comprehensible security architecture and avoid dependencies on extra-territorial service providers. For European infrastructures, this is not only a strategic advantage, but also an essential prerequisite for resilient, trustworthy AI integration.

Conclusion

The MCP server currently under development will provide a robust, secure and extensible infrastructure for integrating language models into technical monitoring. The ability to formulate system queries in natural language and to convert them into specific monitoring actions marks a decisive advance in human-machine interaction. Thanks to its openness to a wide range of tools – from OpenSearch to SSH to Grafana, LOMOC, COMMOC, SIEMOC – and model diagnostics, the system provides an ideal basis for scalable, AI-supported monitoring architectures of the next generation.

Want to try it out?

Then talk to our experts. Whether you need a proof of concept, integration into existing systems or an extension to your infrastructure – we will show you how to reach the next level of monitoring with an MCP server and how to use COMMOC, LOMOC and SIEMOC to create the perfect basis for your AIOps strategy.