Blotato MCP (2026): Same Plan, Two Entrances — and the Vendor Tells You They Do Not Show the Same Numbers

Four scheduling vendors grew the same child query this month. Type any of blotato, metricool, zernio or post bridge into Google and the autocomplete offers you mcp for all four. That is not four coincidences; that is a category discovering a protocol at the same time.

The interesting part is not the protocol. It is that a product now has two front doors, and almost nobody checks whether they open onto the same room. We pulled Blotato's first-party MCP material on 2026-09-21 — its llms.txt, which self-dates to 2026-09-17, and its machine-readable rate card at pricing.md. The vendor answers that question itself, in a sentence most people will scroll past.

What the MCP server actually is

Stated first-party, checked 2026-09-21: one hosted endpoint at mcp.blotato.com/mcp, streamable HTTP, nothing to self-host, exposing 36 tools across 9 publishing platforms. The REST base sits separately at backend.blotato.com/v2 behind a blotato-api-key header. Eighteen client applications are individually documented, and the vendor notes that every one of them connects to the same endpoint and receives the same 36 tools — "Only the authentication method and the place you paste the URL differ."

The tools group like this: accounts (3), credits (2), publishing (3), analytics (2), comments (3), messages and DMs (5), DM automations (8), content extraction (2), videos and images (3), content calendar (4), media upload (1). Worth noticing what that shape tells you — eight of the thirty-six tools are DM automation, which is a newer product line bolted onto a publishing pipe, and it covers only Instagram and Facebook.

Coverage is not uniform and the vendor says so: publishing and scheduling reach nine platforms; analytics reach eight, with LinkedIn returning no metrics yet; comments, messaging and DM automation reach Instagram and Facebook only. If your agent plan assumed "read the comments on all my posts", two platforms is the real number.

The sentence that justifies this whole article

From the vendor's own rate card, on the difference between what the REST reference and the MCP reference document:

"Note that the MCP tools reference currently documents a narrower filter on top-posts (X, Instagram, Facebook, Threads, Bluesky); where the two references differ, cite the one matching the surface you are describing."

Read that again. Analytics is sold as eight platforms. The MCP tools reference documents five for that particular call. And the vendor's instruction is not "we will reconcile these" — it is cite whichever surface you are on. This is the clearest written admission we have collected that the plan you bought and the capability your agent sees are documented separately and can disagree. It is the same finding we reached the long way round in the piece on what MCP servers actually expose versus what the plan page says, except here the vendor states it outright.

This is not a scandal — a documentation lag is an ordinary thing. It is a planning fact. If you build an agent workflow against a capability you read on a pricing card, the card is not the contract; the tool reference for your entrance is.

No free tier, and the reason is mechanical

The other thing the pricing page does not make obvious. Verbatim, from the vendor's FAQ: "Is there a free tier for the API or MCP? No. The 7-day trial excludes API and MCP access; generating an API key starts the paid Starter subscription."

And the mechanism, from the rate card:

"MCP authenticates with the same API key as the REST API, so MCP is unavailable during the free trial for the same reason the API is: generating the key ends the trial."

So the trial is real, it grants 60 AI credits, and it is structurally unavailable to the exact user who came here. The moment you take the step required to try MCP, you are a paying customer — even with trial days remaining. The vendor says so plainly and recommends subscribing rather than trialling. We covered the adjacent trial mechanics in which gates stay shut while you are testing it, and the tier arithmetic in the discount-code piece that turns into a pack-versus-upgrade calculation.

The plans themselves, verified 2026-09-21: Starter $29/month with 20 connected accounts and 1,250 credits; Creator $97 with 40 accounts and 5,000 credits; Agency $499 with 28,000 credits. All three include full API and MCP access with the same endpoints and tools — there is no separate API tier and no API add-on, which is genuinely unusual in this category and worth crediting.

Two quota systems stack, and the second one is invisible

Everyone shopping an agent integration checks rate limits. Almost nobody checks the other ceiling. Both are published first-party:

• Request-level limits, per endpoint: POST /posts at 30 requests per minute, GET /posts at 60, GET /comments at 60, POST /comments at 30.
• Daily posting caps the vendor enforces on top of the platforms' own, and it says outright that its caps are the stricter ones: Instagram 50 posts per account per 24 hours where Meta's API allows 100; LinkedIn 50 per profile and 50 per company Page; Facebook 25 per Page; Pinterest 10 pins a day; TikTok 3 accounts × 10 posts a day on Starter; YouTube 10 uploads per channel on Starter and 25 on Creator. No vendor cap at all on X, Threads or Bluesky.

Two of those deserve a second look. The TikTok line is not a posting cap so much as an account cap in disguise — on Starter you may connect 20 accounts, and at most three of them can be TikTok. And the YouTube line, 10 on Starter rising to 25 on Creator, is the cleanest possible proof that this ceiling is a vendor throttle, not a platform rule. YouTube does not raise your upload allowance because you paid a third party more. When a limit moves with a subscription tier, it belongs to the subscription.

Rate limits tell you how fast your agent may ask. Daily caps tell you how much it may actually do. Only one of those is usually on the page you read before buying.

The failure mode to design for before you ship anything

One more line from the API reference, and it is the one that will bite an unattended agent: publishing is asynchronous, POST /posts returns a submission id, and the vendor writes that this id is "a submission receipt and not proof of publication." You poll until a terminal status of published or failed. Then: "Failures are usually permanent, so read errorMessage rather than retrying."

That is unusually honest, and it names the category's oldest complaint. Scheduled posts that quietly never go out, with no error surfaced, is the single most repeated grievance across review sites and open-source issue trackers alike — closed and open source, cheap and expensive, all failing in the same place. An agent that treats a 200 response as "posted" will reproduce that experience perfectly. Build the poll.

Where does our own work sit in this? Different shelf, honestly. NoobClaw is a desktop application: you log into your own accounts in a local fingerprint browser, no passwords are handed to anyone, each account generates its own content rather than copies, and a human review step stays in the loop. That trades the elegance of one endpoint for not depending on a vendor's daily cap or a platform app review. Which shape is right depends on whether your bottleneck is integration work or account-level control — we laid out both in the MCP server round-up.

FAQ

Can I try Blotato MCP for free?

No. The vendor states that the 7-day trial excludes API and MCP access, and explains the mechanism: MCP authenticates with the same key as the REST API, so generating that key immediately ends the trial and starts the paid Starter subscription even with days remaining. Its own documentation recommends subscribing rather than trialling if you are an API or MCP user.

Does the MCP server expose everything the web app does?

Not identically, and the vendor says so. Its rate card notes that the MCP tools reference currently documents a narrower platform filter on the top-posts analytics call than the REST reference does, and tells readers to cite whichever surface they are describing. Publishing coverage is nine platforms; analytics is eight over REST with LinkedIn returning nothing; comments, messaging and DM automation are Instagram and Facebook only.

Why do four scheduling vendors suddenly have an mcp keyword?

Because the autocomplete reflects what people type, and enough people are now trying to drive publishing from an agent that the protocol has become a shopping criterion rather than a feature. We checked first-party MCP documentation for one of those four vendors today and did not verify the others, so treat the pattern as a search-demand observation rather than a claim about anyone else's product.

What to do with this: before wiring any agent to any publishing MCP, write down three numbers from the tool reference for your entrance, not the pricing card — how many requests per minute the publish call allows, how many posts per day the vendor itself caps on your busiest platform, and which platforms that specific analytics tool actually returns. If those three are not published anywhere, that absence is your answer.