Going into Day 3, the Elasticsearch index was built and the data was in. The next job was connecting it to Gemini. That means building the Model Context Protocol (MCP) server — the bridge that lets the AI actually query the vault rather than just hallucinating an answer.

The hackathon requires using Elastic’s partner MCP. I’d assumed that meant using their pre-built Docker image and pointing it at my index. That assumption cost me most of the morning.

10:30 Starting with the official Elastic MCP server repo — cloning it into Cloud Shell before discovering the pre-built image wouldn’t play nicely with Cloud Run’s port requirements.

The approach: build a custom Python MCP server using FastMCP, containerise it with Docker, and deploy to Cloud Run. The code itself was straightforward — about 30 lines that initialise the server, connect to Elasticsearch, and expose a search_resources tool for Gemini to call.

The deployment was not straightforward.

This error means the container launched but never opened the door. Cloud Run sends health checks to port 8080. If nothing answers, it kills the revision. First instinct: the mcp.run() call wasn’t accepting host and port as arguments. The fix was switching from FastMCP’s internal runner to Uvicorn serving the app directly.

if __name__ == "__main__":
    import uvicorn
    port = int(os.environ.get("PORT", 8080))
    uvicorn.run(mcp.sse_app(), host="0.0.0.0", port=port)

That got the container running. Then the next problem showed up.

Every curl request to the deployed endpoint came back with the same response: Invalid Host header. The server was running. The port was open. But every incoming request was being rejected before it reached the MCP logic.

The fix wasn’t obvious. The clue came from reading the Cloud Run logs directly and then tracing back to the MCP SDK source code.

WARNING  Invalid Host header: localhost    transport_security.py:64
INFO:     136.110.41.56:0 - "GET /mcp HTTP/1.1" 421 Misdirected Request

The MCP Python SDK ships with a TransportSecurityMiddleware — a DNS rebinding protection layer that validates the Host header on every incoming request. By default it’s enabled, with an empty allowed-hosts list, which means it blocks everything that isn’t explicitly whitelisted.

When I added middleware to rewrite the host header to localhost, it got further — but FastMCP’s own transport security then rejected localhost because the server wasn’t configured to expect it. It was rejecting its own workaround.

from mcp.server.transport_security import TransportSecuritySettings

mcp = FastMCP(
    "GCSE-DT-Expert-Vault",
    host="0.0.0.0",
    transport_security=TransportSecuritySettings(
        enable_dns_rebinding_protection=False
    )
)

if __name__ == "__main__":
    import uvicorn
    port = int(os.environ.get("PORT", 8080))
    uvicorn.run(mcp.streamable_http_app(), host="0.0.0.0", port=port)

After redeployment, the server responded properly. The MCP protocol requires a session initialisation handshake before tool calls — once that was understood, testing was straightforward.

• Initialise session — POST to /mcp with the initialize method. Returns a session ID and server capabilities.

• List tools — POST with the session ID. Returns the search_resources tool with its full input schema.

• Call the tool — Send a query. The server hits Elasticsearch and returns extracted text from the indexed PDFs and PowerPoints.

The MCP server is live at its Cloud Run endpoint. The Elasticsearch index is connected. The tool is registered and callable. That’s the hard infrastructure done.

16:30 The moment the MCP server responded correctly — search_resources tool visible and the Elasticsearch connection confirmed live.

With the MCP server running, the next job was wiring it to Gemini via Google’s Agent Platform. This is where the day ended without a clean finish.

Tried three routes:

• MCP Server Registry UI — The Agent Platform has a registry where you can register MCP servers with a JSON tool spec. Hit a persistent “Request contains an invalid argument” error on save. The JSON format, region settings, and URL were all correct — the cause is still unclear.

• Agent Development Kit (ADK) — Google’s Python framework for building agents. The code connected to the MCP server correctly but failed on the Gemini model — the specific model IDs for Vertex AI differ from the API and the available models in the project weren’t immediately clear.

• Agent Garden / Agent Registry — Explored both. Agent Garden is a samples library, not a builder. Agent Registry requires an existing deployed agent endpoint to register against — which brings it back to needing the ADK route working first.