Stripe documented an analytics path through its MCP server that lets an agent query aggregated account data instead of walking individual API objects one at a time. Two tools sit behind it. The stripe_analytics tool handles Stripe-defined metric queries such as monthly recurring revenue and gross volume, template runs for subscription and billing metrics like churn rate and subscriber counts with breakdowns by product or price, and SQL queries against the reporting tables for custom analysis. The stripe_report tool searches available financial report types and creates report runs for balance, payouts, activity, tax and Revenue Recognition.
The design decision is aggregation as the interface. An agent asking for MRR does not iterate subscriptions, which removes the failure mode where a summary is assembled from a partial page of objects and quietly differs from the vendor's own number. Exposing SQL against reporting tables goes further: the agent gets the same query surface a finance analyst uses, rather than a curated subset chosen for chat.
Turning a product's internal state into an addressable surface is the same move as WorkOS Management MCP making SaaS admin state agent-addressable, and the governance question it raises is the one collected in the MCP hub: what scope the token behind that query carries.
This is product documentation describing tools and report types; it does not publish the permission scopes an agent needs or how query cost is bounded. The condition to watch is whether read scopes for reporting tables are separable from write access to the account, because a financial analytics tool is only safe to hand an agent if the same credential cannot move money.