MCP field guide / Elasticsearch
// mcp field guide · search / data
Same split as Postgres: Elastic's official server is read-only by design — five query tools, nothing that writes or deletes — so a guard there is near-ceremony. The danger lives in write-capable community servers, where delete_index is a DROP TABLE-class catastrophe and delete_by_query is an unbounded DELETE.
GUARD FIT · OFFICIAL (read-only)
WEAKFive query tools, nothing to mutate. Real risks are a huge query's cost/exfiltration — access scoping, not an approval prompt.
GUARD FIT · WRITE-CAPABLE SERVER
STRONGdelete_index (irreversible bulk loss), delete_by_query (unbounded), general_api_request (opaque) — hard-gate.
Overall fit: WEAK → STRONG — near-zero on the read-only official server, high on any deployment that enables index/document deletion.
Official — elastic/mcp-server-elasticsearch (Elastic, Apache-2.0). Read-only by design: five tools — list_indices, get_mappings, search, esql, get_shards — and no write or delete tool (confirmed against the README, not inferred). It is now deprecated, superseded by the Kibana-hosted Agent Builder MCP endpoint (whose write surface is whatever an operator builds).12 Write-capable — cr7258/elasticsearch-mcp-server (community, Python) adds the full lifecycle, including deletes, and ships a coarse DISABLE_HIGH_RISK_OPERATIONS kill switch.3
| Tier | Tools |
|---|---|
| read-only | Official: list_indices, get_mappings, search, esql, get_shards. Community: get_index, search_documents, get_document, get_cluster_health |
| mutating (community) | create_index, create_data_stream, index_document, put_alias |
| destructive (community) | delete_index (drops an entire index), delete_by_query (unbounded conditional delete), delete_document, delete_data_stream, delete_alias; general_api_request (arbitrary REST — read or write) |
The two sharp edges (community server): delete_index is irreversible bulk data loss short of a snapshot restore — a DROP TABLE-class catastrophe. delete_by_query is the classic "the WHERE clause was wrong" incident — an unbounded conditional delete. And general_api_request is opaque: the guard can't statically know if a given call reads or destroys, so it should default to deny/approve.
Conversational log analysis. Run ES|QL and Query DSL over log indices — "what errored in the last hour?" — no DSL to hand-write.
Schema discovery. list_indices + get_mappings to learn an unfamiliar cluster before querying.
Index lifecycle (community only). Create indices/data streams, bulk-index documents, clean up test indices — the operations with real blast radius.
Official read-only server → weak. Like a read-only DB connection — nothing to compensate or undo. The real risks are exfiltration and cost (a huge query), better handled by query limits and access scoping than an approval prompt. We'll say so.
Write-capable server → strong, and this is the honest core. delete_index belongs behind mandatory approval with an impact diff, reported honestly as irreversible (no compensation short of a snapshot restore the MCP layer doesn't provide). delete_by_query's approval should surface the match count before commit. Creates (index_document/create_index) are compensable-in-principle (delete the just-created object via the captured id) — but an overwrite or alias re-point may lose prior state. general_api_request defaults to deny.
Classify by operation, mirror the database framing: the guard's leverage tracks the write surface — near-zero on read-only, high the moment index/document deletion is enabled. Compensation is not undo: a dropped index's data is gone unless you snapshotted first.
ChronoMCP classifies by operation — reads flow, and delete_index/delete_by_query/opaque API calls wait for a human with an honest irreversibility flag.
Profiles describe third-party software from its public sources; ChronoMCP is not affiliated with Elastic, and the write-capable server is an independent community project. The official server's read-only design and the community delete tools are verified from source; the Agent Builder endpoint's write surface depends on operator-built tools. Risk groupings are our classification. Sources current as of Aug 2026 — check the source links.