feat(server): add /healthz endpoint for container health checks

[saivedant169]

Fixes #2644

Summary

Adds a /healthz endpoint to the Toolbox HTTP server so container orchestrators (Kubernetes liveness/readiness probes, Docker HEALTHCHECK, Cloud Run startup probes) have a dedicated, lightweight path to hit. The response is HTTP 200 with a JSON body of {"status":"ok"}, so probes can check either the status code or the payload depending on their configuration.

Why a separate endpoint

The existing / handler is a landing page that returns a greeting string. Reusing it for health checks is fine today but couples probe behavior to a user-facing route, and the non-JSON body makes it awkward for tooling that parses health responses. Giving probes their own path follows the convention most Go services already use and keeps / free to evolve as a human-facing entry point.

Implementation

• Registered r.Get("/healthz", ...) in internal/server/server.go right after the default / handler, so it inherits the same CORS and host-check middleware already applied at the router level.
• Returns Content-Type: application/json with body {"status":"ok"}.
• No new dependencies.

Testing

Added TestHealthz in internal/server/server_test.go. It follows the same pattern as TestServe: spins up a real server on a free port, sends a GET to /healthz, and verifies the status code, the Content-Type header, and the JSON body. Runs on port 5004 to avoid collisions with other tests in the package.

$ go test ./internal/server/ -run "TestServe|TestHealthz" -count=1
ok  	github.com/googleapis/mcp-toolbox/internal/server	1.283s

$ go test ./internal/server/ -count=1
ok  	github.com/googleapis/mcp-toolbox/internal/server	2.220s

Also verified go vet ./internal/server/... and gofmt -l are clean.

[gemini-code-assist]

Code Review

This pull request introduces a new /healthz endpoint to the server for container orchestration health checks, along with a corresponding unit test. Feedback was provided regarding the placement of the endpoint on the main router, which may lead to 403 Forbidden errors if host-header validation is enabled and probes use IP addresses. Additionally, a race condition was identified in the test code where the error variable is shared across goroutines.

[gemini-code-assist]

The /healthz endpoint is registered on the main router, which is subject to the hostCheck middleware applied at line 417. In many containerized environments (like Kubernetes), health probes hit the endpoint using the Pod's IP address or localhost. If AllowedHosts is configured with specific domains, these probes will fail with a 403 Forbidden error, potentially causing deployment failures or restart loops. Consider registering health check endpoints on a router group that bypasses host header validation.

[gemini-code-assist]

There is a race condition in this test. The goroutine captures and modifies the err variable from the outer scope (declared at line 154), while the main goroutine reassigns the same variable at line 174 (resp, err := http.Get(url)). You should use a local variable within the goroutine to avoid this race.

	go func() {
		defer close(errCh)
		if err := s.Serve(ctx); err != nil {
			errCh <- err
		}
	}()

[saivedant169]

Pushed a fix for both items in commit 27d8d45.

1. /healthz and the host check: I went with the in-middleware bypass rather than a separate router group. The handler now short-circuits the host validation only for /healthz, so DNS rebinding protection still applies to every other path. A new TestHealthzBypassesHostCheck confirms /healthz returns 200 and / returns 403 when AllowedHosts does not include the request host.

2. Race on err: replaced the goroutine's reassignment with a shadowed serveErr local. Verified clean with go test -race.