Run your tool yourself when it depends on keys, data or machines that must stay with you. Let BlueBear run it when you would rather hand over the code and keep only the job of maintaining it. Either way, BlueBear checks payment, counts each use and issues the receipt. What changes is who holds the keys, who answers when it breaks, speed, running cost and one line on the receipt.
The problem
You own a company that maintains a database of medical device codes. You are ready to list your lookup tool for AI helpers. The publishing details ask one question you did not expect: who runs it?
Your developer says "it depends". She could keep running it on your machines, as she does now. Or she could hand the code to BlueBear and let them run a copy. She starts talking about latency and uptime and keys. You want to know three things. Who is on the hook when it is down at three in the morning? Who holds your passwords? What does it cost you?
She searched "hosted mcp server vs self hosted" and "mcp server hosting" and found advice about servers, not about your business. So the form sits unfinished.
Hosting is what lets a buyer's helper reach your tool at all. Cloudflare's engineers put it this way when they launched hosted tools in March 2025.
"Remote MCP support is like the transition from desktop software to web-based software."
Your question is not whether to host. It is who operates it, and who answers for it.
Why this keeps happening
Most tools that AI helpers call speak MCP, a standard way for AI helpers to use tools. Running such a tool for outside callers is called remote mcp server hosting, and the technical guides treat it as a purely technical choice. It is not. It is a choice about custody, accountability and cost, and each answer shows up on the receipt a buyer keeps.
Here are the two choices side by side, in business terms.
| What differs | You run it | BlueBear runs it |
|---|---|---|
| Who runs the tool | Your developer, on your machines, behind BlueBear's checkpoint | BlueBear, from code and settings you supply |
| Speed | One extra hop to your machines, wherever they are | Checkpoint and tool sit together; fewer hops per call |
| Who holds your keys | You; the keys to whatever sits behind your tool never leave your systems | BlueBear stores the keys the copy needs |
| Who answers when it breaks | You; a down tool is a failed job on your receipt | BlueBear for keeping it running; you for the code |
| Running cost | Your hosting bill, whatever the traffic | No machines of your own; the cost sits inside BlueBear's margin |
| What the receipt says | Run by you, plus the address that was called | Run by BlueBear, plus the version that ran |
| Best for | Private data, licensed keys, tools already in production, special machines | Public-data tools, small tools, first listings, teams with no one on call |
Uptime is the trade you are making when you run it yourself. One independent probe of the official tool registry in July 2026 put it bluntly.
"Roughly one in six "live" MCP servers is not."
Health AI, MCP Queen: State of the MCP Ecosystem (July 2026)
The same probe found about half the listed tools can only run by installing code on the buyer's own machine. Neither choice here asks a buyer to do that.
The cost of getting this wrong runs both ways. Choose to run it yourself with nobody on call, and every outage becomes a refunded job and an unhappy buyer. Hand over a tool whose data licence forbids sharing the key with a third party, and you have broken your own contract.
One more thing your developer may raise. There is a technical debate about "mcp gateway vs mcp proxy", sometimes written as "mcp proxy server vs mcp gateway". For you it comes down to one sentence. A proxy passes calls along. BlueBear's checkpoint checks payment and budget, counts the use and signs the receipt before it passes anything along. That is why your tool should accept calls only from the checkpoint. A back door skips the count.
How to fix it
Answer these six questions in order. The first yes decides it.
- Does your tool use a key you are not allowed to share? Yes: run it yourself, and say so in your disclosures. Some data licences forbid handing keys to a third party.
- Is the tool already serving other customers from your machines? Yes: run it yourself, so one deployment serves everyone. Put the checkpoint's pass check in front of the marketplace traffic.
- Is there someone to answer when it is down at three in the morning? No: let BlueBear run it, or accept that failed jobs appear on your receipts and get refunded.
- Is speed part of the product? A checker called many times per document wants the fewest hops. Let BlueBear run it, unless your machines are closer to your buyers.
- Is the traffic unknown? Start with BlueBear running a first listing. Move to your own machines once you know the shape of the traffic.
- Must the buyer's data never leave their own systems? Then neither choice fits. Some buyers in healthcare and finance need the tool to run inside their own walls. That mode exists in BlueBear's design, but the pilot does not set it up for you. If your tool can be installed that way, say so in your disclosures.
Whichever you choose, write down who holds which keys and who gets the call. Buyers will ask, and your answer is what their security review is graded on.
What BlueBear's marketplace does about it
Both choices go through the same path. A buyer's helper calls BlueBear's checkpoint. The checkpoint confirms the buyer paid and the call is within their budget, counts the use, and passes the call to your tool with a short-lived pass. Your tool answers. A signed receipt goes back to the buyer, and one earnings line is written for you. Buyers pay in credits, one credit is one US dollar, and payouts to you are made by hand during the pilot.
If you run the tool, your one obligation is to accept calls that carry BlueBear's pass, or that arrive through the checkpoint. The pass ties the call to the buyer, your tool's version, the allowed action, a usage limit and an expiry. Your tool can tell who is calling and under what limit without ever holding a buyer's secret. If BlueBear runs the tool, the same check happens in front of the copy BlueBear operates.
A security reviewer may worry that a copy BlueBear runs with your keys is just a relay that could pass a buyer's login onward. It is not. The buyer's pass stops at the checkpoint. Your tool gets a short-lived pass minted for it, never the buyer's login. Any access to the buyer's own systems is granted by that buyer, for that buyer, and can be switched off.
The receipt is the same signed record in both cases: the tool and version, the buyer, the action, the cost and the outcome. Only the line about where it ran differs. Buyers read that line to know where their request data went. Their security team treats a tool you run as an outside processor. That is not a mark against you; it is a disclosure you should be ready to back up.
Where the tool runs is written into your listing's description, so changing it later is a new version. Buyers who pinned the old version keep it until they move. During the pilot BlueBear makes that change on your behalf, since publishing is by invitation and there is no dashboard you operate. There is no ranking, and no difference in how the two choices are shown to buyers beyond that one line.
What to do next
Go through the six questions with your developer this week and write down the answer in one sentence: who runs it, who holds which keys, who gets the call. Add that sentence to your disclosures. It is one of the eight things BlueBear needs from you to list your tool.
If you run it yourself, read the one mistake to avoid at this boundary, which is passing a buyer's credentials through your tool. Then read what sits between a buyer's helper and your tool for the questions buyers will ask. If a buyer needs the tool inside their own walls, the buyer's view of the same decision explains what they are weighing.
When you have chosen, apply to publish on BlueBear. Publishing is by invitation, and a person will review your details before anything goes live.
Questions people actually search for
- should i host my tool myself or let bluebear
The hosted mcp server vs self hosted question comes down to custody and duty. Run it yourself when it depends on keys you may not share, data that must stay with you, or a system that already serves other customers. Let BlueBear run it when the tool uses public data, is small, is your first listing, or when nobody on your team wants the pager. Both choices pass the same payment check and produce the same signed receipt.
- who holds my passwords if bluebear runs my tool
If you run the tool, the keys to whatever sits behind it never leave your systems. BlueBear's checkpoint forwards a short-lived pass, not a buyer's secret, and your tool checks that pass. If BlueBear runs the tool, you hand over the code and the keys it needs, and BlueBear stores them for that copy. In neither case does a buyer receive a key to your tool, and in neither case do you receive a buyer's passwords. Buyers grant narrow, revocable access from their side.
- does it change the receipt if i host the tool
Only one part. A receipt is a signed record of one job that the buyer keeps and that your earnings line is drawn from. Both choices record the tool and version, the buyer, the action, the cost and the outcome. If you run the tool, the receipt says so and names the address the checkpoint called. If BlueBear runs it, the receipt says that and gives the version that ran. Buyers read that line to know where their request data went.
- can i switch hosting later
Yes, as a new version of your listing, because where the tool runs is part of the listing's description. Buyers and workflows that pinned the earlier version keep it until they move. During the pilot BlueBear makes the change on your behalf, since publishing is by invitation and there is no dashboard you operate. A common path is to start with BlueBear running a first listing, then move to your own machines once you know how much traffic to expect.