Personal-Use MCP Versus Commercial API Licensing

"It is the same data, so why are there two plans?" is a fair question and it deserves a straight answer rather than a pricing page.

The short version: the two plans are shaped by who bears the cost of the traffic and who profits from the data. Those are genuinely different situations, and pricing them the same would mean either overcharging individuals or subsidising businesses.

The boundary, as plainly as we can put it

Personal use is you, using the tools in your own assistant, for your own food. Logging your meals. Planning your week. Working out the macros in your own dinner. The output is consumed by you.

Commercial use is anything where the data reaches other people through something you operate. An app, a website, a service, a client deliverable, a product with a price on it. The output is consumed by someone who came to you rather than to us.

The test that resolves nearly every edge case: does someone other than you rely on this data through something you provide? If yes, it is commercial, whether or not money changed hands for that specific interaction.

What each plan actually is

The MCP plan is $29 a month or $228 a year with a 7-day trial. Limits sized for one person: 20 calls a minute, 10,000 successful calls a month, 25 foods per search, 150 photo estimates a month and 20 a day. Trial limits are 5 a minute, 200 calls total which never reset, 10 results and 10 photos.

It calls MCP tools only. REST search, foods, calc and vision return 403. Account and billing pages work normally. A commercial usage header on an MCP key is rejected. Details on the MCP page and MCP pricing.

REST plans are a different surface for a different caller: HTTP endpoints, higher quotas, response caching on the upper tiers, more API keys, and commercial production use on the appropriate tier. Pricing has the tiers, and the licensing specifics are in the commercial licence guide.

Note that the MCP plan cannot call REST and REST plans do not include the MCP server. That surprises people, so it is worth stating both directions explicitly. They are separate products.

Why the limits are shaped this way rather than just being smaller

The MCP limits are not a shrunken commercial plan. They are sized around what one person's food logging looks like, which is a specific and quite unusual traffic shape.

A person logs a meal, which is a handful of calls, then does nothing for four hours. Bursty and tiny. A commercial app has many users, so its traffic is smooth, continuous and much larger, and it needs caching, higher concurrency and predictable throughput. Those are different engineering problems with different costs.

Twenty calls a minute is generous for a person and deliberately useless for a service. Ten thousand a month is more than a careful logger will use and nowhere near an app's needs. The shape is the product boundary, not a paywall placed inside one product. The reasoning in detail is in rate limiting an MCP server.

The four situations people get wrong

"I am a developer, so I am building something." Not necessarily. If you are logging your own lunch in Cursor because that is where you live, that is personal use. Being a programmer does not make your dinner commercial. What matters is whether the data reaches other people.

"It is free, so it is not commercial." It usually is. A free app with users, an internal tool at your employer, a free tier of a paid product, a public demo. In all of these, other people depend on the data through something you operate. No money needs to change hands for it to be commercial use. An employer's internal tool is commercial use by a business, which is exactly the case the commercial tier exists for.

"It is just a prototype." Prototyping against a personal plan while you are the only user is fine. The moment you show it to users, it is not a prototype in the sense that matters. Move before launch, not after. The transition is smoother than a retrofit, and REST is a different surface, so building on MCP and then porting is more work than starting on REST.

"I will cache the results, so I am only making a few calls." This is usually the most serious version. Bulk-retrieving data and storing it in your own database is not lighter use, it is redistribution, and it is the thing the limits and the anti-scraping measures exist to prevent. Call volume is not the point; what happens to the data afterwards is.

Why we refuse the commercial header rather than charge for it

A commercial usage header on an MCP key returns a 403 rather than a bill.

That is deliberate, and it is about honesty in both directions. A plan sized for one person cannot support a product: not the rate limit, not the quota, not the caching, not the support expectations. Letting someone launch on it would mean their product breaks at the worst possible moment, under load, in front of their users, and then it is our fault as much as theirs.

Refusing at the boundary is clearer than silently degrading. If you are building something, we would rather have the conversation before you launch.

What the boundary looks like in practice

Not a clause in a document, but observable behaviour you can check with a key in about a minute.

An MCP key calling the MCP tools works. The same key calling REST search, foods, calc or vision gets a 403. The same key sending a commercial usage header gets a 403 with a message about commercial use. And the same key calling account, billing or authentication routes works normally, because you still need to manage your own subscription and rotate your own keys.

That last direction is the one worth noting, because a blanket block would be simpler to implement and would lock you out of your own billing page. The gate is on the data surfaces, not on your account.

Two consequences follow that surprise people:

A REST plan does not include the MCP server. The gate runs both ways. If you have a Plus plan for your app and you also want the tools in your own assistant, that is a separate subscription, because it is a separate product. Every non-MCP plan card on the pricing page says so.

Switching plans is a switch, not an addition. Moving from MCP to REST changes which surface your key can reach. Anything you built against the MCP tools does not carry over, because REST is a different interface. Build on the surface you intend to stay on.

If you outgrow personal use

The transition is deliberately undramatic. There is no negotiation and no bespoke process.

Pick a REST tier that covers your volume and, if you are shipping a paid product, the commercial licence that goes with it. Pricing has the tiers, with commercial production use on the appropriate tier, higher quotas, response caching on the upper tiers, and more API keys. The commercial licence guide is the document that covers what the licence permits.

Two practical notes. Do it before launch rather than after, because retrofitting a different interface under a shipped product is more work than starting there. And if your product will scan barcodes or estimate photos, check those specific capabilities against the tier you are choosing rather than assuming, since image endpoints in particular are gated separately.

If you are not sure

Two questions, and they are usually enough.

Who reads the numbers? Only you means personal. Anyone else through your thing means commercial.

If we turned your key off tomorrow, would someone other than you be affected? If yes, you need a plan with an SLA and commercial terms, because you have dependents.

That second question is the more useful of the two, because it reframes the issue as reliability rather than as permission. A personal plan carries no SLA and no commitment about response times, and that is appropriate for a food log, where if a lookup fails you try again in a minute. It is not appropriate for anything with users, and a plan with dependents needs the obligations that come with a commercial tier.

If both answers are still ambiguous, ask us before you build. Getting told "personal is fine" costs an email. Getting told "that was commercial" after launch costs a migration.

Why this is normal, not unusual

Personal-versus-commercial splits are standard across data licensing: financial data, mapping, imagery, professional datasets of every kind. They exist because the same bytes have very different value depending on whether one person reads them or ten thousand customers do, and because the support and reliability obligations differ enormously.

What is legitimately confusing about the MCP version is that the transport is new and the plan boundaries in the MCP ecosystem are not yet conventional. Some nutrition MCP servers are free with no stated commercial position at all, which is not the same as permission. And where a community wrapper is MIT-licensed, that licence covers its code and grants nothing about the data flowing through it. That distinction is covered in nutrition API vendors and MCP.

Connect it, if personal use is what you are doing

claude mcp add --transport http calorie-api \
  https://calorieapiadmin.com/mcp \
  --header "X-API-Key: YOUR_KEY"

{
  "mcpServers": {
    "calorie-api": {
      "url": "https://calorieapiadmin.com/mcp",
      "headers": { "X-API-Key": "YOUR_KEY" }
    }
  }
}

Claude Code and Cursor, with the header. Browser sign-in for Claude apps is off on this server until OAuth is enabled. The docs carry the full tool reference, and the MCP page the overview.

If what you are building is software rather than a habit, a REST plan is the right starting point and the commercial licence guide is the document to read.

What we have not measured

There are no measurements in this post, because it is about a policy rather than a system. The limits quoted are configured values, readable on MCP pricing and from the nutrition://limits resource on the server, and the 403 behaviour on the commercial header and on REST prefixes is behaviour you can verify in a minute with a key.

What we have not published is any data on how the boundary plays out in practice: how many accounts sit near the line, or how often the refusal is the wrong call. If the boundary turns out to be drawn in the wrong place, we would rather hear it than defend it.

Related

• What the MCP plan includes
• MCP pricing and the 7-day trial
• Tool reference
• REST plans
• Food database API licensing for a commercial mobile app
• Nutrition API vendors and MCP