gemini-search-agent

A Gemini agent that turns plain-English log + product questions into Elasticsearch queries via the Elastic MCP server. Cites counts verbatim from the cluster. Apache 2.0.

Comment

Inspiration

It's 11pm. Someone pages you: "why is checkout slow?" You open Kibana, recall the index name, fight with field names, write a bool / must / range, discover the wrong field, fix it, run again, scroll through hits, count errors by hand. Twenty minutes later you have an answer the agent could have produced in seven seconds. That gap was the inspiration for gemini-search-agent.

What it does

gemini-search-agent treats every search question as a discover-then-query loop. You ask in plain English and the agent walks the Elastic MCP tools:

  1. list_indices to see what's on the cluster
  2. get_mappings to read the field types of the target index so the query targets fields that exist
  3. The right query shape — search (with a subset of the ES DSL: term, match, range, bool/must) for specific lookups, or count_errors as a fast path for log-level summaries

The answer is structured: a one-line direct answer, the exact tool + arguments used, 2-4 evidence bullets with counts copied verbatim from the cluster response, and a suggested follow-up.

How we built it

  • Google Cloud Agent Builder (ADK) for the agent framework. The whole agent fits in six lines of ADK: one LlmAgent, one McpToolset, a Gemini model, and a system prompt that defines the discover-then-query workflow.
  • Gemini 2.5 Flash on Vertex AI for reasoning.
  • Elastic MCP server for tools. The agent talks to the official @elastic/mcp-server-elasticsearch tool surface. A stub MCP server ships in the repo with a canned 482-document service-logs index plus a small products index so the demo runs without a Phoenix tenant. Set ES_URL and ES_API_KEY and the same agent code targets a real cluster via the official Docker image.
  • Streamlit for the dashboard.
  • Cloud Run for hosting.

Challenges we ran into

Elasticsearch DSL is rich. The stub deliberately implements only the slice the agent actually needs (term, match, range, bool/must) so the agent's tool calls drop in unchanged against a real cluster — but reviewers can see exactly what's implemented in _match_docs() rather than wondering what's going on inside.

Accomplishments that we're proud of

  • A real Vertex AI Gemini call returned the structured verdict: 81 total ERROR logs, search-svc the worst offender (27 errors), recommendation-svc 21, payment-svc 17, checkout-api 16. The agent picked the fast count_errors tool over a full search — exactly the right choice for that question.
  • Twelve passing tests cover stub responses + the agent wiring.
  • This is the fifth substantively-different MCP integration in this hackathon sibling family (Dynatrace, Arize Phoenix, MongoDB, RAG drift, Elastic). All five share the same LlmAgent + McpToolset shape; the MCP protocol carried the abstraction every time.

What we learned

When the user's question maps to a domain-specific summary, a tool that returns that summary directly beats a full search. Adding count_errors alongside search saved both tokens and latency.

What's next for gemini-search-agent

  • A "diff" tool that takes two time windows and reports which errors are new vs. carryover.
  • ECS-aware field auto-completion via get_mappings introspection.
  • A Kibana-style timeline visualization in the dashboard.

Built With

  • agent-development-kit
  • elastic
  • elastic-mcp
  • elasticsearch
  • gemini
  • gemini-2.5
  • google-cloud-agent-builder
  • mcp
  • model-context-protocol
  • python
  • streamlit
  • vertex-ai
Share this project:

Updates