AI readiness
Engineers work through coding agents now, and an agent is only as good as the interfaces it has already seen. Everything here is one it has: open query languages, a published spec, and MCP servers on both the platform and the clusters themselves.
Three layers
Agent compatibility is mostly a property of open standards rather than a feature anyone builds. Two of these three layers were true before MCP existed, which is why there is nothing to install and no integration to wait for.
PromQL, OpenSearch DSL, PPL and SQL have been public and documented for years, so an agent writes working queries against your data on the first attempt. An in-house query language is the opposite: something you re-teach at the start of every session.
Every operation is in a published OpenAPI spec and a Terraform provider. Both are formats an agent reads unaided, which is why this worked before either MCP server existed.
Two MCP servers: one for the platform, one inside each cluster. The first manages clusters, members and invoices. The second searches your indices and reads their mappings.
The platform, as tools
The ClusterNest MCP server exposes the REST API's operations as tools. Paste the server URL and client ID into Claude, Claude Code, Codex or Cursor, log in through the browser once, and the client refreshes its own token from then on. There is no client secret and nothing to pre-register.
| Server URL | https://api.clusternest.com/mcp |
|---|---|
| OAuth client ID | mcp |
| Client secret | None. It is a public client. |
| Transport | Streamable HTTP |
| Cost | Included on every tier |
The cluster, as tools
OpenSearch ships an MCP server of its own inside the ML Commons plugin, and it is there on every version we run. Turn it on with a cluster setting, register the tools you want it to expose, and an agent can list indices, read mappings and search them without being handed a query language and left to construct HTTP calls.
It is off until you enable it, and the tools you register are the whole of what it offers. Connect it as a read-only user and it stays read-only.
$ PUT /_cluster/settings
{"persistent": {"plugins.ml_commons
.mcp_server_enabled": true}} 200 ok
$ POST /_plugins/_ml/mcp/tools/_register
ListIndexTool created
IndexMappingTool created
SearchIndexTool createdBoth at once
An agent can hold both connections in the same session. The platform server stands the cluster up and hands over the credentials; the cluster's own server answers questions about what is in it. The work that used to be a console tab, a terminal and a Dashboards window is one conversation.
The two servers see different things. The platform one receives the tool calls your agent makes, which are the same operations the REST API takes. The cluster one is part of your OpenSearch cluster and answers from the indices in it. Neither receives the conversation that produced the call.
$ claude "stand up a Standard cluster for
the checkout logs, then tell me which
indices are biggest"
clusternest create_opensearch_cluster
checkout-logs · standard creating
checkout-logs available
checkout-logs ListIndexTool
logs-2026.09.07 · 14.2 GB · green
logs-2026.09.06 · 13.8 GB · green
Cluster is up. Today's index is the
largest at 14.2 GB, and yesterday's is
within half a gigabyte of it.Boundaries
Giving an agent access to production infrastructure is a real decision, so the limits are worth stating plainly. They are the ones already enforced for people, applied to the same accounts.
The full account model, including what each organization role can do, is on security and compliance.
Ten days, one Basic cluster, no card. Long enough to connect a client, provision a cluster from a prompt and decide whether working this way suits your team.