Feature Request: Expose last_alert payload in get_alert_group response

Summary

The Grafana OnCall API already returns a last_alert object (including full payload) inside the alert group response, but the Go client's AlertGroup struct doesn't map it — so get_alert_group silently drops it today.

The Fix

1. Add last_alert to the AlertGroup struct in amixr-api-go-client:

type AlertGroup struct {
    // existing fields ...
    LastAlert *Alert `json:"last_alert,omitempty"`
}

2. Expose it in get_alert_group as opt-in to avoid polluting MCP context by default:

type GetAlertGroupParams struct {
    AlertGroupID           string `json:"alertGroupId" jsonschema:"required,description=The ID of the alert group to retrieve"`
    IncludeLastAlertPayload bool  `json:"includeLastAlertPayload,omitempty" jsonschema:"description=If true, includes the full payload of the last alert in the group"`
}

Motivation

Alert payloads contain stable fingerprints that an AI agent can use to correlate recurring alerts across different alert group IDs:

Source	Field	Example
Sentry	payload.data.event.hashes[0]	"66b46acbdeae7d18599d803d44d7c10f"
groundcover / Grafana Alertmanager	payload.alerts[0].fingerprint	"912a47a2bcc2c22e"

Today the agent sees only alerts_count: 1 with no way to reach the payload in a single call. With this fix, one get_alert_group call returns the fingerprint needed for correlation — no additional tool required.

The includeLastAlertPayload flag is intentional: a Sentry alert payload can exceed 10KB (full stacktrace, 50+ module versions, request headers). Opt-in avoids polluting the MCP context when the payload isn't needed.

Related

• #748 — update_incident
• #813 — update_alert_group
• Follow-up: a list_alerts tool (with field selection) will be proposed separately for cases where the full alert history of a group is needed