Call the manageBoostingPool MCP tool

Manage this workspace's boosting-pool membership. Four actions, three of which require the CALLING USER to be a workspace owner (Admin or Reachium Staff; the legacy client role also counts) - resolved from the connection's user or the signed-in dashboard user; a connection with no resolvable owner, or a non-owner user, is refused exactly like a non-owner member is refused in the app. (1) 'apply' (owner-only): request to join a public named/partner pool (pool_id) - a request only, subject to admin review. If this workspace was previously rejected from that pool, or the pool simply is not open for applications right now, apply refuses with the identical message either way (a rejection is never disclosed). A second apply while already pending or approved just returns the current status, not an error. (2) 'withdraw' (owner-only): retract a pending application (pool_id). (3) 'join': add this workspace's LinkedIn accounts (linkedin_account_ids) to a pool with daily_boost_limit per account (default 5 - how many posts each account likes plus comments per day). pool_type:'workspace' joins your own team's internal pool and needs no owner role. pool_type:'named' joins an approved partner pool (pool_id) and IS owner-only, checked after verifying this workspace is actually approved for that pool. Re-joining with an account already in the pool reactivates it and updates its daily_boost_limit, rather than duplicating it - this is the only assistant-accessible way to reactivate a deactivated membership; changing an existing membership's limit or active state WITHOUT touching which accounts are selected is app-only (the /content/posts boosting pool card). (4) 'leave' (owner-only): remove membership from a pool (pool_type, plus pool_id for a named pool); pass linkedin_account_id to remove just one account, or omit it to remove every one of this workspace's accounts from that pool. Leaving immediately stops those accounts from boosting there - no more likes or comments go out on that pool's members' posts from them. Pool membership counts are workspace-wide aggregates; another workspace's individual accounts are never visible or reachable from here. 'join' is a LAUNCH action and two-step: the first call returns a preview (pool, accounts, boosts per day) plus a confirm_token and joins nothing; after the user approves, repeat the identical call with confirm_token. Once joined, those accounts like and comment automatically with no further confirmation until they leave. apply, withdraw and leave have no confirm step.

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.