ESQueryStudio Unifies Elasticsearch Operations: Six Query Modes, MCP for AI Clients, and a Spring Boot / Chrome Dual Transport
Spring Boot teams can drop a separate Kibana deployment and ship a full ES query workbench inside their own application, inheriting the host's authentication, navigation, and audit hooks. At the same time, AI agents gain a governed, read-scoped path into Elasticsearch via MCP, so Claude, Cursor, or an in-page agent can debug relevance or slow queries without being handed broad write credentials.
ESQueryStudio attacks the fragmentation of Elasticsearch tooling. Instead of separate pages for DSL, SQL, Explain, and profile, it keeps one shared query context across six modes: DSL builder with raw editor, ES-SQL, Lucene, sandbox, PIT deep pagination, and a SQL⇄DSL bridge. Switching modes never clears an in-progress query, and history, drafts, and deep links all live on the same context. A semantic layer reads live index metadata — field types, analyzers, sortability, cluster version — to drive autocomplete, value enumeration, and pre-execution lint that catch mistakes like sorting a text field without `.keyword`.
The relevance lab shares that same context, exposing BM25 factor trees, per-clause hit matrices, boost tuning, and profile flame graphs that pinpoint whether a slow query is spending time in rewrite, build_scorer, or next_doc. The console ships two ways from one Vue codebase: server mode embeds in a Spring Boot app and reuses the host's login, menus, and page-level permissions; browser mode runs inside a Chrome MV3 extension and connects directly to Elasticsearch, with honest capability boundaries (no fake RED, interrupted migrations flagged, service worker continues monitoring after tab close). A parity check script fails CI if a backend endpoint lacks a frontend browser implementation.
Newly added MCP support exposes 19 tools across three surfaces: server mode via JSON-RPC on `/mcp`, a pure-frontend `window.ESQueryStudioMCP`, and a local Node stdio bridge. All share one tool contract, default to read-only, and let admins issue per-connection keys with quotas, rotation, and write-scoped permissions. AI clients can read mapping first, run profile searches, and explain slow queries without ever touching production write access.
Unifying query modes under one shared context solves a real friction point: translating between DSL, SQL, and explain output no longer requires copying JSON or re-building a condition tree, which is where most ES console errors come from.
The browser-mode capability honesty is a notable design stance. Instead of pretending a restricted account has full visibility, the console shows empty detail and flags interrupted migrations, preventing operators from acting on fabricated RED status.
Bringing MCP into an ES console is more than a wrapper; it enforces governance at the tool layer. Read-only defaults, per-connection permissions, and write-tool OFF by default are the kind of guardrails that make AI agents safe to run against production clusters without a human approving every query.
Embedding the console into Spring Boot via SPI rather than hardcoding host business fields is the right boundary; it keeps the platform reusable while letting each deployment own branding, auth, connection sources, and audit trails.
The CI-driven browser parity check turns a common drift problem into a build failure, which is a more reliable enforcement mechanism than documentation or code review.
The two comments both come from the author and drill into the MCP layer's architecture and security posture. MCP is framed as a single 19-tool contract carried over three transports, with tests guarding against capability drift. Permissions are enforced at the connection and tool level — not through prompts — with per-identity keys, read-only defaults, and fail-closed write paths. The version layer and browser/Node modes round out the picture, showing the design prioritizes strict defaults and explicit authorization over convenience.
Recently patched in MCP: three access surfaces — server /mcp, browser window.ESQueryStudioMCP, local Node stdio — sharing 19 tools; read-only by default, authorized per connection, Claude Desktop / Cursor can query ES directly. The MCP deep-dive is updated in the article (visible once the review passes), docs: https://github.com/dengmeiluan/esquerystudio/blob/main/docs/mcp.md
One more implementation layer: MCP is not 'just add an endpoint' — it's the same 19-tool contract aligned across three transports: server /mcp, in-page window.ESQueryStudioMCP, local Node stdio. The repo includes server/frontend/docs contract alignment tests (with negative controls) to prevent capability drift. Permissions are clamped by 'connection × tool': keys are issued per login user/role, connection-level read/write (QA/UAT writable, production read-only), tool whitelist, rpm/day/month quotas, rotation/revocation; plaintext appears only once in the creation response, storage keeps only SHA-256. Raw REST also classifies read/write: GET/HEAD read-only, POST query APIs read-only, write APIs and unknown POST/PUT/DELETE fail closed — a valid key doesn't automatically open writes. The version layer walks EsIndexAdmin: SQL, explain, update paths auto-rollback for ES 6/7/8/9; browser mode is zero-port and write tools are off by default; local Node connects directly to ES, so Claude Desktop / Cursor don't need to start Spring Boot. The management surface lives in Dev Tools → MCP panel, issuing keys and showing tools/call request counts and quotas. Deep usage for AI: fetch es_get_mapping/settings first, then generate DSL, lint/explain before execution; slow queries use list_tasks + profile + explain_doc; production read-only, QA writable relies on connection-level permissions, not prompt constraints.