Think inside your AI world.

Elasticsearch through Unl

Elasticsearch's MCP server will report shard status down to the individual replica. Whether that state clears an index for a launch is your bar to set - a search that returns results isn't the same as an index that has fully recovered.

Elasticsearch through Unl reads index health and shard state against the go-live threshold you have ratified, so 'is this index healthy enough to serve the launch?' comes back on-track-or-not with the condition it hasn't met.

What Elasticsearch holds

Query Elasticsearch's MCP server about an index and it reports:

  • index list with health status and document counts
  • field mappings for a given index
  • search results via Query DSL, including highlighting
  • ES|QL query execution
  • shard-level status across all or specific indices

What the naked read gives you

Elasticsearch's MCP server lists every index with its health colour and document count, hands back the field mappings, runs the Query DSL search, and reports shard status down to the individual replica. It is a complete, accurate picture of cluster state - it just does not say whether that state is good enough to put in front of users.

The frame judges the data it is given; it does not verify the source’s accuracy.

What changes when Elasticsearch is read measured

A search infrastructure lead at a retail platform ratified a go-live rule in Unl: the product index only takes live traffic once every shard reports green and the document count sits within one percent of the source catalogue, because a red shard during last year's sale silently dropped a fifth of listings from search results for six hours.

'Is this index healthy enough to serve the launch?' returns, measured: not yet - the shard read shows one unassigned replica shard on products-2026, and index health is yellow rather than green. Elasticsearch supplied the shard status; your ratified rule supplied the go-live bar.

And back again

Once the replica reassigns, Elasticsearch through Unl picks up the recovered shard state next time it checks; the ratified go-live rule then clears the index for launch, and this page is what changes - not a new one.

The answer comes back measured against what you already decided, and why.

The lane is live and open to this tool today: one box, paste anything. If it speaks MCP, Unl can reach it. Readings arrive unprompted, the data beside the criterion; Unl is a courier, not a warehouse, and keeps only your keys and the frame.

Questions people ask

What has to happen before this index goes live?

The unassigned shard reassigning and index health turning green. The same ratified go-live rule reads the recovered shard state and clears the index for launch.

How do I connect Elasticsearch to Claude?

Deploy Elastic's official MCP server (elastic/mcp-server-elasticsearch) against your cluster, or point Claude at Elastic's hosted MCP endpoint with your cluster credentials - Unl's reads travel through whichever route you pick.

Does Unl write to my index?

No. Unl calls Elasticsearch's list_indices, get_mappings, search, and get_shards tools to see current state; it issues no index or write requests. Any shard reassignment, your cluster handles on its own.

What this is

Think inside your AI world — you stay in command

Unlimitless (Unl to friends) holds what you've settled, reads what your tools are showing, and catches what's changed out in the world — and hands your AI whatever bears on the work, the moment it's needed, without you asking. The right thing, in front of the model, unprompted, with you in command of the call. So you keep moving toward what you set out to build, on top of everything you've already decided.

It plugs into Claude, Claude Code, ChatGPT and Cursor as an MCP connector. Quick to connect, in a couple of steps.

Unlimitless is open now to invited Alpha. Apply for the Beta waitlist to come in ahead of the full launch:

Alpha is invite-only · free at launch.