Polar MCP by usefulapi

Most tools map to distinct Polar resources and actions, and the descriptions clarify boundaries well. However, polar_get_customer_state and polar_get_customer_state_by_external_id are near-duplicates differing only by lookup key, and polar_get_customer vs. customer state has some overlap.

Every tool follows a predictable polar_ + verb_noun snake_case pattern (polar_list_*, polar_get_*, polar_create_*, polar_cancel_*, polar_redeliver_*). The convention is applied consistently across all 26 tools.

26 tools is slightly high, but the Polar billing domain covers many distinct resources such as products, subscriptions, orders, refunds, benefits, meters, events and webhooks. Each tool maps to a separate API endpoint, so the count is reasonable rather than excessive.

The surface is heavily read-oriented and misses core lifecycle operations: no create/update/delete for products, benefits, discounts, meters, customers or webhook endpoints, no event ingestion tool, and no get_refund or webhook endpoint management. These gaps would block common administrative workflows.