Call the getAnalytics MCP tool

Aggregate campaign or content performance into a chart-shaped result over the last 7/30/90 days or all time. Two shapes: timeseries (one value per day for a metric) and funnel (campaign-only, stage-by-stage counts). Domain campaign accepts metrics requests_sent | connections_accepted | replies | positive_replies | meetings_booked; domain content accepts impressions | reactions | comments | engagement. Funnel is campaign-only and ignores metric. Its stage labels depend on the campaign type, so PASS campaign_id whenever the question is about ONE campaign (get it from getCampaigns first): outreach is leads, requests, accepted, replied, positive, booked; retargeting/re_engagement is enrolled, messaged, replied, positive, booked (no accepted stage); a pure-InMail campaign is sent, replied only. Without campaign_id, every campaign is aggregated in the outreach shape starting at requests, and a retargeting or InMail-only campaign contributes 0 to requests/accepted there while its replies and bookings still count. Returns content with series (timeseries) or stages (funnel) plus the window and labels; on surfaces that render cards also chart_artifact_id. Quote ONLY numbers from this result; never sum or estimate from getCampaigns.

Called through the Actions bridge: the response is that tool's own result, wrapped as { data: <tool result> } under HTTP 200. Billing, daily-cap, and confirm-step outcomes are embedded INSIDE data, never remapped to an HTTP status (see the templated /api/v1/actions/{toolName} operation above for the full protocol, and x-mcp-actions for this tool's machine-readable scope/cap/confirm_behavior fields). Authentication, request-shape, and optional idempotency-protocol failures still use their documented non-200 statuses.