When OceanBase on K8s Meets AI — A Deep Dive into the Design of okctl-mcp-server
Author: Li Ziyi, currently a second-year master’s student at Wuhan University, an OceanBase community contributor, and a SIG member. He is interested in AI, vector databases, cloud native, and other fields, and actively explores them.
Background
What Is okctl
okctl is the command-line management tool that pairs with ob-operator. Its full name is OceanBase Kubernetes Control Tool. It was born out of the 2024 Summer of Open Source program and provides cluster management, tenant resource management, backup policy resource management, component management, and more. It can also check and update local component versions and offers commands that suggest how to set up a cluster and its accompanying tenants. It is suited to resource management for OceanBase on K8s.
Why okctl-mcp-server Is Needed
The MCP (Model Context Protocol) was proposed by Anthropic to provide a unified, standardized, and secure way to connect AI with other data sources, allowing AI to integrate with file systems, databases, and various existing systems. The MCP protocol can serve as the “hands and feet” of large models, enhancing their capabilities.
2025 has been called the inaugural year of agents. The emergence of the MCP protocol has also prompted companies—including database vendors—to roll out their own MCP servers. That gave me the idea to implement an MCP server for okctl, as an attempt at applying AI to operations work.
Back to the point: why is okctl-mcp-server needed? In the AI era, with the rise of all kinds of AI IDEs, the barrier and cost of coding keep dropping, and projects can be built faster and faster. As a result, understanding your own goals, technology choices, and system architecture before starting a project becomes even more important.
For operating OceanBase on K8s today, there are mainly three approaches:
- The traditional approach of declaring resources via YAML to interact with K8s;
- Using OB-Dashboard (the accompanying management UI service) to operate through web pages;
- Using the okctl command-line tool, composing commands to carry out operations.
Each of these has its pros and cons. First, declaring resources via YAML to interact with K8s suits users who deeply understand both basic K8s operations and OceanBase’s various resource configurations. Second, OB-Dashboard, as the management tool atop ob-operator, lets you configure things through web pages, which is very well suited to fine-grained tuning and to enterprise operations staff who use ob-operator to manage clusters. Finally, there is okctl, originally designed to simplify the use of kubectl while also extending related functionality such as component installation and simple cluster setup.
But as we used it more, we found that with okctl, some common commands and simple configurations are used quite frequently in daily work, whereas some finer-grained configurations—such as tuning a cluster’s zone resources—require very complex combinations of command-line arguments. Users also have to read the docs corresponding to okctl’s help command, which is clearly unfriendly and a shortcoming of the tool.
So, is there a way to make fairly complex configurations simple to complete? Clearly, the MCP protocol can realize this vision. Our idea, then, is to use okctl-mcp-server configuration so that fairly complex resource operations can be described in natural language and handed off to AI. okctl serves as the foundation that provides the functionality, offering AI the ability to invoke it with a minimal amount of code, and it can also integrate with other MCP servers, enabling AI to carry out more complex workflows.
In addition, having helped build the OceanBase Cloud Native SIG for over a year, I’ve received a lot of help from the community, and I hope to give back by contributing my own efforts and making more attempts.
Below, I’ll walk through the specific design approach.
Design Approach
Module Analysis
The main modules are shown in the figure below:
Some of the functionality needs to mirror okctl’s implementation—that is, calling okctl commands underneath—which is fairly simple. Other functionality was written later, designed to give AI more cluster inspection capabilities. The code has already been merged into the mcp-oceanbase repository; for implementation details, refer to that repository: https://github.com/oceanbase/mcp-oceanbase
Example Scenarios
Create a cluster and check its status:
Connect to a specific tenant under a cluster and execute SQL statements:
Change a tenant’s password, create an empty standby tenant, and perform a primary-standby tenant switchover:
For this operation, you can see that when the tenant password change has not finished, it can wait for the tenant operation to complete and then try again.
Through these three simple operations, you can see that natural-language interaction makes operations that were originally complex very simple.
Other Optimizations
We also made several other optimizations for this project to provide users with a better experience.
First, after investigation we found that some MCP clients run into problems when too many MCP servers are loaded, and okctl-mcp-server alone provides over 30 tools—which is very unfavorable. We therefore need to give users a dynamic loading capability for flexible configuration, avoiding the problem of slow loading when there are too many tools. Users simply add the corresponding argument on the command line at startup to choose which modules to load.
Second, we optimized for long tasks. For each task, the processing flow is to first call the relevant tool, obtain status information, and hand it to the LLM for processing. But some operations—such as creating or modifying a cluster—take a long time, and a call made shortly afterward will obviously return a cluster status that doesn’t match expectations. The LLM repeatedly calls the show cluster and show tenant tool functions to check status, and the biggest problem with this constant calling is that it consumes a large amount of tokens, which is clearly meaningless.
To solve this problem, the simple workaround we came up with is to use polling for detection when performing operations like creating or modifying cluster resources, only returning to the LLM once the cluster’s status is running. This avoids meaningless token consumption, but the downside is that these two operations now take longer to respond.
Existing Problems
Having covered the advantages above, let’s discuss the shortcomings.
This tool currently has certain limitations. First, operations work has a higher cost than other tasks. And the LLM is a probabilistic model—tool invocation depends largely on the AI’s judgment, or you could even say on the LLM itself and on how the prompt is written. So even with learning and prompt optimization, we still cannot fully hand operations work over to AI; it can only serve as an assistant.
Closing Thoughts
This project is still being updated and iterated. The cluster connection feature is being refactored and will be implemented in okctl going forward.
I hope that, as LLMs keep developing and new technologies and interaction protocols emerge, we can arrive at better solutions and explore further along the path of AI-driven operations.
Finally, I hope the OceanBase community and the Cloud Native SIG keep getting better! If you’re also interested in this project, please follow the ob-operator and mcp-oceanbase repositories: https://github.com/oceanbase/mcp-oceanbase
Finally, I’d like to recommend the WeChat account “Lao Ji’s Tech Talk” run by Lao Ji, OceanBase’s open source lead. It continually publishes all kinds of technical content related to #databases, #AI, and #technical architecture. Anyone interested is welcome to follow!
“Lao Ji’s Tech Talk” not only aims to keep bringing you valuable technical content, but also hopes to contribute to the open source community together with everyone. If you appreciate the OceanBase open source community, please light up a little star ✨! Every Star you give is what motivates us.