MCP Server Pricing: Which SaaS Vendors Charge Agents to Read Your Own Data

A commercially distributed Slack app that Slack has not approved for its Marketplace can read 15 messages a minute from your channel history. An app your own team builds can read at least 50,000 in the same minute. That gap, more than any published fee, is how MCP server pricing really works in 2026: the toll is charged on who is asking for your data, not on the data itself.

The short answer: most SaaS vendors do not charge your agent a fee to reach your data. They charge it in throughput instead. Agents the vendor has not approved, or that serve many customers from one app, get far less capacity than the vendor's own agent or an app your team builds in-house.

MCP server pricing rarely shows up as a price

The Model Context Protocol, or MCP, is the open standard that lets an AI agent call tools in another system through one common interface. Most large SaaS vendors now host an official MCP server. Which ones ship one, and with what write access, is mapped in our scored list of incumbent MCP servers.

Once the server exists, what does it cost an agent to read your data through it, compared with reading the same data in the vendor's own screens? For this review we read the developer documentation, rate limit pages and API terms of five vendors between 9 and 11 October 2026.

The categories are our framing. Examples are from vendor documentation, linked below.

The meter is the one buyers notice, because it lands on an invoice. I think the gate and the leash matter more. A gate makes a third-party agent too slow to be useful, which pushes you toward the vendor's own agent without a single price change.

Slack's agent data access rules: 15 messages a minute for apps it has not approved

Slack changed its limits on 29 May 2025. It moved two core reading methods, conversations.history and conversations.replies, from Tier 3 to Tier 1 for one class of app. Per the Slack developer changelog, the new limit is "1 request per minute" with a maximum of 15 objects per request.

The class matters more than the number. The cut applies "only to applications that are commercially distributed outside of the Marketplace", which Slack calls unlisted apps. Marketplace apps saw no change. Internal apps your own team builds are "limited to 50+ requests per minute" at up to 1,000 objects per request.

Who counts as approved, and what that does to throughput

The gap is three orders of magnitude. An internal app can read at least 50,000 messages a minute from channel history. An unlisted commercial app can read 15.

Pulling the last 10,000 messages from one busy channel takes an internal app 10 requests, well under a minute. The same pull takes an unlisted app 667 requests at one a minute, or roughly 11 hours. That arithmetic is ours, from Slack's published limits.

Slack states its reason plainly: to "prevent bulk data exfiltration by unvetted applications". Existing installations of unlisted apps kept their old limits, so the cut lands on new customers of a third-party agent, not old ones.

What Slack's API terms of service forbid even when the rate allows it

The rate limit came with a terms change. Slack's API terms, in the version effective 10 October 2025, say an app serving other organisations "may not" use API data "to train a large language model". It also may not "bulk export Slack message and file data" unless an additional agreement allows it.

The search route is tighter still. Through the Real-time Search API, a third-party provider "may not create persistent copies, archives, indexes or long-term data stores of other organisations' API Data". That clause rules out the usual architecture of enterprise search and agent products: copying your messages into their own index.

Slack's alternative is to query live. It made its MCP server and the Real-time Search API generally available on 17 February 2026. Slack's announcement cited "a 25x increase in both RTS queries and MCP tool calls" since an October limited release. Slack gives no baseline for that figure.

The MCP door has the same gate. Slack's MCP documentation says "unlisted apps are prohibited from using MCP", and MCP tool calls carry the same rate limits as the equivalent Web API methods. The search method itself allows "10+ requests per minute" for most teams, plus a user-level limit of 10 a minute.

Atlassian: SaaS API limits in points, and credits on agent context

Atlassian took a different route to the same place. From 2 March 2026 it began phased enforcement of points-based quotas on Jira and Confluence REST APIs, according to an Atlassian platform blog post dated 12 December 2025.

Under the model, "each request starts with a base cost of 1 point, and additional points are added for each object involved". Fetching one Jira issue costs 2 points. Looking up a group of 8 users costs 17, because identity objects cost 2 points each. Writes "are charged only the base cost".

The hourly quota is shared across every customer an app serves

The default tier is the part buyers should read twice. Per Atlassian's rate limiting documentation, a Tier 1 app "shares a single 65,000 point hourly quota across all tenants". When it runs out, "all requests are denied until the next hourly reset" with "no gradual throttling".

Consider a third-party agent product with 200 Jira customers on the default tier. Split evenly, each customer gets about 325 points an hour, enough to read roughly 160 issues. That split is our illustration; real traffic is never even.

Tier 2 gives each customer its own pool, sized by plan and seat count, and is granted after Atlassian reviews the app's usage. Standard sites get 100,000 points plus 10 per user, Premium 130,000 plus 20, and Enterprise 150,000 plus 30, capped at 500,000 an hour.

The rule covers Forge, Connect and OAuth 2.0 apps. "API token-based traffic is not affected by this change". So an admin's personal-token script avoids the quota a commercial OAuth agent must live inside.

Rovo credits meter agent reads, not writes

The second Atlassian toll sits on its own MCP server. Atlassian's Rovo usage limits page says credits are consumed "when enriched context is returned" through the Atlassian Rovo MCP server. The pricing table applies from 31 August 2026.

Write operations "such as updating a Jira work item" are free, and so is looking up a single work item or page. Cross-product search and context calls cost 1 to 10 Rovo credits in the "vast majority" of cases.

Jira plans include 25, 70 or 150 credits per user per month on Standard, Premium and Enterprise. Extra usage bills at $0.01 per credit from 3 December 2026, and it is enabled by default.

Take a 100-seat Premium Jira site. That is 7,000 pooled credits a month, or 700 enriched calls at the top of the 1 to 10 range. A single agent summarising a project board several times a day could plausibly use that. Each call past the pool then costs up to $0.10.

I read the free-writes rule as a design choice, not an accident. It rewards agents that act inside Jira and charges agents that mine Jira for context to use elsewhere. That is exactly the line a vendor protecting a workflow position would draw, as argued in the comparison of data moats and workflow moats.

Microsoft: a per-call meter on ERP data, and one meter removed

Microsoft is the one vendor in this review that prices MCP access as a line item. Its Dynamics 365 ERP MCP server page says agents built on clients other than Copilot Studio incur "one copilot credit per 10 tool calls to the server (or 0.1 credits per tool call)".

The page calls this "an incremental charge by Microsoft for the execution of the MCP server". It sits on top of the language model cost, which the agent client bills separately. Users on Dynamics 365 Finance Premium or Supply Chain Management Premium are exempt.

Copilot Studio is not automatically the cheaper route

Copilot Studio agents pay no separate execution charge. Their tool calls align with the "Agent Action" feature, which "bills at a fixed rate per tool call" covering orchestration and execution together. Microsoft's Copilot Studio billing page lists an agent action at 5 Copilot Credits.

So a buyer comparing routes should not assume the in-house agent wins on price. A third-party agent pays 0.1 credits per ERP call plus its own model cost. A Copilot Studio agent pays a bundled 5 credits per action, unless the user holds a Microsoft 365 Copilot licence, in which case Microsoft says the calls "don't incur additional credit consumption".

The bundled route is free for customers already paying for Copilot seats and metered for everyone else.

Teams export used to be metered, and is not any more

Microsoft also gives this post its clearest counter-example. Microsoft Graph once charged per message for Teams export and change-notification APIs. Its metered API list now states that "starting August 25, 2025, the Teams APIs are no longer metered, and no billing configuration is required".

One metered Graph API remains in that list: assigning a sensitivity label to a SharePoint or OneDrive file costs $0.00185 per API call. A toll on bulk reading of chat data was removed. Tolls are not a one-way ratchet.

HubSpot and Zendesk: paid SaaS API limits that skip third-party agents

Both sell extra API capacity as an add-on, with a catch for agent products built by someone else.

HubSpot

HubSpot's API usage guidelines give privately distributed apps a shared daily limit of 250,000 requests on Free and Starter, 625,000 on Professional and 1,000,000 on Enterprise. An API Limit Increase adds 1,000,000 a day per purchase, up to two purchases.

The add-on "does not increase the limits" of apps using OAuth that are "distributed via the HubSpot marketplace". Those apps get 110 requests every 10 seconds per installing account. Capacity you buy goes to your private integrations, not to a third-party marketplace agent.

HubSpot's MCP documentation states no rate limit at all. It does say the server "is based on the CRM search API", which HubSpot separately describes as having limits "stricter than the general limits". We could not confirm whether MCP calls draw on that search budget, and HubSpot does not say.

Zendesk

Zendesk publishes per-plan limits in its rate limits reference: 200 requests a minute on Suite Team, 400 on Growth and Professional, 700 on Enterprise and 2,500 on Enterprise Plus. A High Volume API add-on raises eligible plans to 2,500 requests per minute, with a minimum of 10 agent seats.

The export path is the narrow one. Incremental export endpoints, which pull everything that changed, are limited to 10 requests a minute, or 30 with the add-on. Zendesk's pricing for the add-on is not on its public rate limit pages.

Neither vendor discriminates by who built the agent the way Slack does. But both put the cheap capacity on the private, customer-built path.

Agent data access compared across five SaaS vendors

Every cell is the vendor's own published rule, read between 9 and 11 October 2026.

"None found" means the pages we read did not contain such a rule. It does not mean the vendor's master agreement has none.

Your own code, running under your own credentials, gets the most capacity at the lowest price. A third-party agent serving many customers from one app gets the least. The vendor's own agent usually sits in between or above, often bundled into a licence you already pay for.

So a third-party agent can look cheaper per seat and still lose, because it reaches your data through the narrowest door. Why that depth of access decides who wins is covered in the analysis of integration depth as an AI moat.

Where this argument is weakest

Calling these tolls implies rent extraction. That is not the only honest reading.

Rate limits protect shared infrastructure and your data

Slack's stated reason, preventing bulk exfiltration by unvetted apps, is a real security concern. A commercial agent that can pull 50,000 messages a minute from every customer is also an attractive target. Atlassian's shared pool exists partly so one noisy app cannot degrade the platform for everyone.

I accept most of that. Where I part company is on the asymmetry. If bulk reading were the risk, it would be risky for the vendor's own agents and for Marketplace partners too. A limit that applies by commercial relationship rather than by behaviour is a commercial limit, whatever else it also does.

The documentation is not the whole contract

This review reads public pages, and enterprise agreements can override all of it. Slack's terms allow bulk export under "an additional agreement", Atlassian grants Tier 2 after review, and Zendesk offers capacity above 2,500 requests a minute with prior written consent. A large customer may never feel these limits.

The sample is also small. Five vendors were chosen because their rules are documented clearly, not because they are representative. Salesforce's developer limits page refused our automated requests, so it is absent rather than graded.

And one vendor moved the other way. Microsoft removed Teams metering in August 2025. Concluding that tolls only ever tighten would overfit to a short window.

API terms of service clauses to negotiate before you sign

None of these rules appear in a demo. Most of them can be addressed in a contract, if you raise them before signature rather than at renewal. The broader set of clauses a finance team should push for is in the CFO's guide to AI contract clauses.

The second row is the one I would fight hardest for. Slack's terms change landed on customers who had already built on the old rules. A notice period and an exit right turn a unilateral change into a negotiation.

Ask anyway. A refusal tells you how much of the vendor's agent strategy depends on keeping your data behind its own interface. Switching costs of this kind are mapped in the post on AI model switching costs and lock-in.

Identity is the last check. The generous limits above mostly go to apps running as your own users or internal integrations. Whether an agent should run under a person's identity or its own is worked through in agent credentials versus user impersonation.

Frequently asked questions

Where to start

List every agent or AI product your team has connected to Slack, Jira, HubSpot, Zendesk or Dynamics. For each one, find out whether it reaches your data as an internal app, a Marketplace-approved app, or an unlisted commercial app. The third group can lose performance without notice.

Then put one question to each vendor's account team in writing before your next renewal: will named third-party agents get the same API limits on your tenant as an internal app? The answer tells you more about the vendor's agent strategy than its keynote did.

Related reading