ajeetraina777/sbx-dynatrace-kits repository overview

⁠Dynatrace kit for Docker Sandboxes

A standalone Docker Sandboxes⁠ kit (kind: mixin) that gives any sandbox agent access to Dynatrace⁠ - problems, security vulnerabilities, entities, logs, and DQL queries against Grail - through Dynatrace's hosted Remote MCP server, plus requests-based runbooks.

Source and full docs: https://github.com/ajeetraina/sbx-kits-dynatrace⁠

⁠Image tags

The MCP server is hosted by Dynatrace - nothing is installed in the sandbox, which reaches it over *.apps.dynatrace.com with the token injected on the wire. This is Dynatrace's recommended path for local-dev clients (VS Code, Claude Code, Cursor, ...).

⁠Quick start

Store a platform token once (keyed on the apps host), set your environment URL (see the repo's providers/remote.md), then launch:

sbx secret set-custom --host '*.apps.dynatrace.com' --env DT_PLATFORM_TOKEN --value "$DT_TOKEN"
sbx run --kit docker.io/ajeetraina777/sbx-dynatrace-kits:latest claude

No tag holds a token. The sbx proxy injects it from the stored secret, so the token never enters the sandbox. sbx run has no -e flag by design.

⁠How it works

The kit wires up the hosted Dynatrace Remote MCP server, sets DT_ENVIRONMENT, writes a portable MCP definition to ~/.dynatrace/mcp.json, and (best-effort) registers the server with the Claude agent. Dynatrace traffic is routed through the sbx proxy, which attaches the stored platform token (Authorization: Bearer) on the wire. It also ships runbooks (~/runbooks/run_dql.py, dynatrace_report.py) that query Dynatrace directly.

Per-target setup, validation, and the raw spec.yaml for each kit live on GitHub: https://github.com/ajeetraina/sbx-kits-dynatrace/tree/main/providers⁠