Call the getBoostingPools MCP tool

List this workspace's boosting pools and its own membership state. Boosting pools are opt-in circles where member LinkedIn accounts automatically like and comment on each other's lead-magnet posts, helping them clear LinkedIn's engagement thresholds. Every workspace has its own internal pool (kind:'workspace', always available, your team only) plus zero or more named partner pools (kind:'pool') this workspace can see: joined (contributing accounts), approved (cleared to join but no accounts added yet), pending (application awaiting review), or available (a public pool you have not applied to). A pool this workspace was rejected from is omitted entirely. Returns members (this workspace's OWN memberships, each with linkedin_accounts identity, daily_boost_limit, boosts_today already used, and is_active), pools (the directory above, with member_count/my_account_count aggregates - rosters never cross a workspace boundary), and stats.boosts_received_today (this workspace's posts boosted today, scoped to pool_id if passed). Pass pool_type and/or pool_id to scope to one pool; omit both for everything. Manage membership with manageBoostingPool.

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.