Elasticsearch

@elasticsearch list all indices in the cluster that start with 'logs-' and show their health status

Found 12 indices matching pattern 'logs-*'. Health breakdown: 9 green (logs-app-2024-01, logs-app-2024-02, logs-nginx-2024-01, logs-nginx-2024-02, logs-api-2024-01, logs-api-2024-02, logs-worker-2024-01, logs-worker-2024-02, logs-auth-2024-01), 2 yellow (logs-app-2024-03, logs-nginx-2024-03), 1 red (logs-api-2024-03). Yellow indices have unassigned replica shards. Red index logs-api-2024-03 has unassigned primary shards and requires immediate attention.

This example shows the MCP's ability to filter indices by pattern and surface cluster health at a glance. Requires API key with monitor_cluster privilege. Health status reflects cluster state at query time — yellow/red indices may indicate configuration issues or node failures that need investigation.

@elasticsearch get the schema for the 'user-events-2024' index and explain what fields are available for filtering

The user-events-2024 index has 18 mapped fields. Key filterable fields: 'user_id' (keyword), 'event_type' (keyword), 'timestamp' (date), 'session_id' (keyword), 'device_type' (keyword), 'geo.country' (keyword), 'geo.city' (text with keyword subfield). Numeric fields: 'duration_ms' (long), 'response_code' (integer). The 'metadata' field is a nested object with dynamic mapping. Text fields 'user_agent' and 'referrer' are analyzed for full-text search but also have .keyword subfields for exact matching and aggregations.

This example demonstrates schema introspection — essential before writing queries. Understanding field types (keyword vs text, nested objects) determines which query syntax works. Requires read privilege on the target index. Schema complexity grows with dynamic mappings; this output simplifies the actual mapping structure for readability.

@elasticsearch query the 'api-logs-2024-01' index for all 5xx errors in the last 24 hours, group by endpoint, and show me the top 5 failing routes

Queried api-logs-2024-01 with filters: response_code >= 500, timestamp >= now-24h. Found 1,847 error documents. Top 5 failing endpoints: /api/v2/orders/sync (612 errors, mostly 503 Service Unavailable), /api/v1/payments/process (401 errors, mix of 500 and 504), /api/v2/inventory/update (298 errors, all 502 Bad Gateway), /api/v1/users/profile (276 errors, 500 Internal Server Error), /api/v2/search (260 errors, 503). The /orders/sync spike started 6 hours ago and correlates with increased request volume.

This example pairs Elasticsearch's aggregation power with AI synthesis to surface actionable insights from raw logs. The MCP executes the query; the AI interprets patterns and correlates timing. Requires read access to the index. Large time ranges or high-cardinality aggregations may hit query timeouts or memory limits — narrow your time window if queries fail.

When Elasticsearch MCP beats grep for post-mortems

A 6-person engineering team runs a post-mortem after a 2am outage. They need to correlate error spikes across three services, filter by timestamp windows, and export findings to a shared doc. The Elasticsearch MCP is the right call here because it surfaces index schemas first—so the team knows which fields exist before writing queries—then lets them iterate on filters without switching to Kibana. The query tool handles time ranges and pagination natively, which matters when you're scanning 40k log entries. The trade-off: if your logs live in CloudWatch or Datadog instead of self-hosted Elasticsearch, this MCP won't help. But for teams already running their own ELK stack, this turns Switchy into a collaborative query builder that keeps context in the workspace instead of lost in browser tabs.

Why this MCP works for support teams under 10 people

A 4-person support team indexes their help articles, past tickets, and internal runbooks in Elasticsearch. During a customer call, they need to pull up the exact article that solved a similar issue last quarter. The Elasticsearch MCP wins here because the List Indices tool shows all knowledge bases at a glance, and the Query Index tool lets them filter by tags, dates, or keywords without memorizing DSL syntax. The schema tool is less critical in this scenario but useful when onboarding new hires who don't know which fields are searchable. The boundary: if your knowledge base is in Notion or Zendesk, those native integrations will be faster. But if you've already invested in Elasticsearch for full-text search across unstructured docs, this MCP turns Switchy into a shared search interface that the whole team can query together.

When Elasticsearch MCP replaces ad-hoc SQL for event logs

A 3-person product team tracks user events in Elasticsearch—signups, feature clicks, checkout flows. They meet weekly to review funnel drop-offs and need to slice data by cohort, date range, and event type. The Elasticsearch MCP is the right tool because it exposes the index schema upfront, so the PM knows which event properties are indexed, then lets the team write queries collaboratively in Switchy instead of passing SQL snippets in Slack. The query tool's pagination support matters when scanning 100k events per week. The catch: if your events are in Mixpanel or Amplitude, those tools have better funnel visualizations. But for teams that pipe raw events into Elasticsearch and want to explore data without a BI tool, this MCP turns Switchy into a lightweight analytics workspace where queries and findings live in the same thread.