MCP vs REST: When to Ship a Server Instead of an SDK

MCP and REST can read the same nutrition catalog. They are not the same product, and on this API they are not the same subscription. REST is how an application you wrote asks for foods. MCP is how an assistant the person is already talking to asks for foods. Shipping one and pretending it is the other wastes the integration.

The same catalog, a different caller

A REST search is your code. You choose the query, you store the food_id, you scale the grams, you render the diary. The model, if you use one, is behind your UI.

An MCP search is the assistant's code. The person says "log 180 g of grilled chicken and 200 g of rice." The client calls search_foods and calculate_portion if the tool descriptions are doing their job. You do not write that sequence. You write the tools, then you watch whether the model uses them. That second problem is tool design, and it does not exist for a normal REST app.

Use REST when you are building a tracker, a menu, a label, or anything another customer pays you for. Use MCP when the person wants the catalog inside Claude, Claude Code, or Cursor, for themselves. The connect steps are in the client article. The product page is the MCP page.

What the MCP plan is not allowed to do

An MCP subscription can call the MCP tools. It cannot call REST search, food detail, calc, or vision. Those routes return 403. Account, billing, and auth still work, so the person can open the dashboard and manage the key.

The other direction matches. A Free, Basic, Core, Plus, or Custom key does not have MCP access. Plus is not a bundle that includes the MCP server. If you need both an app and an assistant, they are two plans, on purpose. One shared plan would let a commercial app ride a personal assistant subscription, or let an assistant subscription drain a commercial quota. The rate limit is per user. Mixing those audiences in one bucket makes the cap meaningless. The bucket itself is described in Rate Limiting an MCP Server.

Commercial use, meaning resale, embedding the data in a product someone else pays for, or walking the catalog, is a REST conversation, not an MCP header. The MCP guard rejects X-API-Usage-Type: commercial before it spends a rate-limit token.

A task, both ways

"Find Greek yogurt and show calories per 100 g."

REST, which your app runs:

curl "https://<api-origin>/api/v1/search/foods?q=greek+yogurt&limit=5" \
  -H "X-API-Key: YOUR_KEY"

That sample is 2 lines. Your app still has to parse JSON, pick a row, and store the id. The sample is not the whole app.

MCP, which the assistant runs after you connect it:

{
  "mcpServers": {
    "calorie-api": {
      "url": "https://<api-origin>/mcp",
      "headers": { "X-API-Key": "YOUR_KEY" }
    }
  }
}

That sample is 8 lines. It does not search for yogurt. It gives the assistant a tool that can. Counting these two samples against each other is not a benchmark of engineering time. It is the size of the two snippets on this page: 2 lines of curl, 8 lines of client config. The work that remains is different. REST work is in your codebase. MCP work is in the tool schema and in whether the model calls it.

Claude.ai does not use the JSON above. It uses the URL and the sign-in screen. The header form is Claude Code and Cursor.

Billing shape

Tool calls are stored as /api/v1/mcp/<tool name>. A search and a portion are two rows. initialize is not a row. You can see which tool the assistant used without guessing from a single /mcp counter.

Prices for the MCP plan are on MCP pricing: $29 per month, or $228 per year. The trial is 7 days and requires a card. Those are list prices, not a discount invented for this article. REST plans stay on the main pricing page and are not repeated here so the two catalogs of plans do not get mixed.

When REST is the wrong extra

Do not wrap the MCP server in your backend so your mobile app can call it. You would be paying for a tool schema your app does not need, and the MCP plan would 403 the REST calls you actually wanted. Call the REST endpoints. Do not wrap REST in a toy MCP server for a mobile app either, unless an assistant is the interface. A server that exists so a model can call it is a good server. A server that exists so you can say MCP in a pitch is a second client you now have to authenticate, limit, and explain. The build notes for a real one are in How to Build a Remote MCP Server in Python. The auth notes are in the authentication article.

Which call is which

For an application, the authenticated routes are ordinary HTTP.

• Name search: GET /api/v1/search/foods
• Barcode: GET /api/v1/search/barcode/{upc}
• Portions, recipes, and targets: the /api/v1/calc routes
• A photo from your app: the vision route, on a plan that includes it

The MCP tools cover the same jobs with different names: search_foods, lookup_barcode (argument upc), calculate_portion, calculate_recipe, calculate_macro_targets, analyze_food_photo. suggest_foods is the short prefix list. get_food_nutrition is one id. You do not get a new catalog by calling the tool. You get a schema a model can fill in.

An MCP key that calls GET /api/v1/search/foods is refused. The 403 says the plan provides MCP access only, not the REST API, and it points at the MCP docs and the REST pricing page. That sentence is the product boundary. It is not a bug in the key.

Metering follows the tool name. A search stored as /api/v1/mcp/search_foods and a portion stored as /api/v1/mcp/calculate_portion are two calls against the 10,000 per month, or against the trial's 200 total. The handshake is not one of them. If your assistant logs one meal as search plus portion plus a second search because it did not keep the id, that is three calls. The rate-limit article explains the shared minute bucket. The fix is the tool description that says to reuse food_id, not a higher cap.

A short way to choose

If a person is talking to Claude and wants the catalog in that conversation, give them the MCP URL and the MCP plan. If you are shipping a screen that searches foods, call REST from your server and use a REST plan. If you need both, buy both. Do not point the app at /mcp and parse tool JSON. Do not point the assistant at your private REST wrapper and hope the model fills in headers it cannot see.

The MCP plan's public price is $29 a month or $228 a year, with a 7-day card-required trial. Those figures are the price page, not a quote from a call we timed. Annual is $120 less than twelve monthly payments, which is arithmetic on those two prices: 29 times 12 is 348, and 348 minus 228 is 120. It is not a measured saving from a customer cohort.

REST remains the right call for a barcode scanner in your own app, a recipe importer, or a menu you render. GET /api/v1/search/barcode/{upc} returns the row to your code. lookup_barcode returns it to the model. Same lookup service, different caller, different plan. Pick the caller you actually have.

A REST integration lives in your repository: request, parse, store, render. You can test it without a model. An MCP integration lives in the tool list the model sees. You test it by watching tool calls, which is why the tool-design article refuses to publish an accuracy score it does not have. Budget time for that watching. The JSON config is the small part. The part that fails is a description that says "find foods" on both search and suggest, so the model stops on the one that has no macros.

If a vendor pitch says "we have MCP" and the server is a stdio process on a laptop, that is not this product. A remote server is an HTTPS URL, a credential, and a plan. A local server is a process your editor starts. Both can speak the protocol. Only the remote one is something you can hand to Claude.ai. Build the remote one when the assistant is not on the same machine as the code. The Python article in this series is that build. This article is the decision in front of it.

Related

• How to Build a Remote MCP Server in Python
• Authenticating a Remote MCP Server with API Keys
• MCP docs
• MCP pricing