Add OpenSearch support

[LucasHild]

Add a new tool for querying OpenSearch. The tool is disabled by default and needs to be enabled using a flag.

I am using the /api/ds/query endpoint instead of /api/datasources/proxy/uid/{uid}/_msearch to support SigV4 signature for AWS.

---

Note

Medium Risk
Adds a new datasource-querying tool and wires it into the CLI/tool enablement path, plus expands the integration/e2e environment with an OpenSearch container and seeded data. Moderate risk due to new HTTP query path via Grafana /api/ds/query and additional CI infrastructure that could affect test stability.

Overview
Adds OpenSearch support via a new query_opensearch tool that queries OpenSearch through Grafana’s /api/ds/query (plugin backend) with time-range and limit handling, and registers it under a new opensearch tool category.

Updates server/CLI wiring and docs to expose --disable-opensearch and include OpenSearch in enabled-tools lists and capability descriptions.

Extends test infrastructure to provision an OpenSearch datasource, run an OpenSearch container with a seed script, and adds Go integration tests plus Python e2e tests that validate query_opensearch usage; CI workflows are updated accordingly.

^{Written by Cursor Bugbot for commit 2375189. This will update automatically on new commits. Configure here.}

[cla-assistant]

All committers have signed the CLA.

[cla-assistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[ioanarm]

Hello @LucasHild! Thanks for putting this together! We’re trying to avoid growing the MCP tool list when the use case is this close to what we already have. OpenSearch and Elasticsearch are similar under the hood (Lucene, comparable query styles), so query_opensearch and query_elasticsearch end up overlapping a lot, and we’d be maintaining two parallel paths long term.

Maybe we could consider extending query_elasticsearch with an opensearch path. Would you be open to try and extend query_elasticsearch tool instead? Shared bits (auth, limits, time range, document shape) can stay in one place and the request/response handling is the one that needs to diverge.

Thanks again! Happy to discuss more or have another look if you think this is something that you'd like to explore.