clickmax-payments-dashboard-analysis

As tools abaixo aparecem com os nomes que o MCP da Clickmax registra. Se o seu cliente de IA prefixar nomes de tool (mcp__<servidor>__, mcp_<servidor>_, ou outro), use o nome já prefixado que aparecer na sua lista de tools.

When this applies

Use this skill for payment dashboard browsing and seller revenue analysis: headline KPIs, my-sales queries, external sales charts, and the recoverable-revenue reading (how much money is still winnable back across failed, canceled, refunded, pending, and abandoned-cart cohorts).

Not this skill:

• detailed refund operations -> clickmax-transaction-operations
• customer subscription lifecycle mutation -> clickmax-seller-subscriptions
• why sales are failing, grouped by reason with the recoverable value per reason -> clickmax-failure-diagnosis

Key assumptions

• dashboard_my_sales splits into rows and KPIs: dashboard_my_sales_aggregations returns the KPI object alone, and dashboard_my_sales with includeAggregations: false returns the rows alone. Asking for both when you need one costs ~15 full scans for nothing.
• external sales are a separate surface and should not be merged blindly into native sales conclusions
• recovery_recoverable_revenue is the cheap aggregate for "how much can I recover" — it returns deduplicated buckets (failed, canceled, refunded, pixPending, boletoPending, cartAbandonment) plus reason/stage breakdowns, without paginating rows; prefer it over paging dashboard_my_sales just to re-sum recoverable money
• the my-sales aggregations (totalNumberOfSalesPaid/Failed/Canceled/Refunded) count only the workspace's own sales as seller, matching what the sales screen shows; sales where the workspace is affiliate or coproducer are not in these totals.
• KPI values are cached briefly per (workspace + filters), so a sale made seconds ago can be in the rows before it is in the totals. Do not reconcile a row-level count against the KPI object in the same breath.