On this page
Remote vs Local MCP: What Actually Differs
Key Takeaway: Remote vs local MCP looks like an infrastructure preference and is really a constraint on where your team can work. A local server communicates over stdio on one machine, so it cannot reach browser-based clients — ChatGPT on the web, Claude on the web. That is a property of the transport, not a configuration you can change.
Every MCP server is one of two things. A local server runs as a process on your own machine and talks to a desktop application through standard input and output. A hosted or remote server runs somewhere else and talks over HTTP.
That distinction sounds like a devops detail. It determines which AI clients you can use, who holds your credentials, and what happens when a platform changes its API on a Tuesday.
Where Can Each One Actually Run?
This is the constraint most people meet first and the one least often mentioned in setup guides.
Client | Local (stdio) | Hosted (HTTP) |
|---|---|---|
Claude desktop app | Yes | Yes |
Claude on the web | No | Yes |
ChatGPT on the web | No | Yes |
Cursor / Windsurf | Yes | Yes |
Phone or tablet | No | Yes |
A colleague's machine | No | Yes |
A browser tab cannot spawn a process on your laptop, which is why the "no" rows are absolute rather than a limitation someone will fix.
For a solo analyst working in one desktop app, none of this matters. For a team where half the people live in ChatGPT on the web, it decides the question before any other consideration.
Who Holds the Credentials?
The second real difference, and the one security reviews focus on.
With a local server, credentials sit in a config file on your machine. Nothing leaves your laptop, which is genuinely attractive. It also means the credentials are only as protected as your laptop is, they are invisible to anyone auditing access, and when you leave the company nobody knows they existed.
With a hosted server, you complete an OAuth flow and the provider holds a token. That token is scoped to permissions you approved and revocable from the platform's own settings without involving the vendor. The trade is that a third party holds an access token, which is a legitimate thing for a security team to want to think about.
The July 2026 MCP specification made remote connections meaningfully stricter here: it mandates OAuth 2.1 with PKCE for remote servers and moved the protocol to a stateless request/response core. So a compliant hosted server authenticates the way ad platforms expect rather than holding a password — which, as covered in why AI tools get ad accounts banned, is the distinction that actually decides suspension risk.
Key Takeaway: "Local is more secure" is too simple. Local means fewer parties hold credentials; hosted means credentials are scoped, revocable and visible to whoever audits your access. Which is safer depends on whether your bigger risk is a third party or an unmanaged laptop.
What Maintenance Actually Costs
Underestimated, because it is invisible on day one.
Ad platform APIs change. Versions deprecate, fields get renamed, rate limits shift, OAuth scopes are revised. A hosted server absorbs that — the provider ships an update and you notice nothing. A self-hosted server means you notice by something breaking.
You also own deployment, updates, secrets rotation and API quotas. For an engineering team that already runs services, this is routine. For a marketing team without one, it is a dependency on whoever set it up still working there.
The honest version: self-hosting an open-source server is free in licence terms and not free in attention.
When Local Is the Right Answer
We sell a hosted server, so take this section as the part where we argue against ourselves.
Your security policy prohibits third-party token custody. Some organisations simply will not allow it. That ends the discussion, and self-hosting is the correct answer rather than a workaround.
You have engineering capacity and want control. If you already run services, self-hosting an open-source server is genuinely low friction and you get to modify it.
You are one person in one desktop client. The browser-client limitation costs you nothing, and there is no team to co-ordinate.
You want to inspect exactly what is sent. Local means you can read the code and watch the traffic. For evaluating a new category, that is a reasonable thing to want.
Honest limitation on hosted: You are trusting a vendor's uptime, their normalisation logic, and their handling of a token that can read — and often write to — your ad accounts. If that vendor has an outage, you have an outage. If they are acquired or shut down, you migrate. Those are real risks that self-hosting does not have, and no amount of convenience makes them disappear.
How to Decide in Three Questions
Where does your team work? If anyone needs browser-based clients or mobile, hosted is the only option. This overrides everything else.
Who maintains it in six months? If the honest answer is "whoever set it up, if they are still here", hosted removes a single point of failure that has nothing to do with technology.
What does your security policy allow? Ask before you evaluate, not after. If third-party token custody is prohibited, that decides it.
Most marketing teams land on hosted for the first reason, not the third. Most engineering-heavy teams land on local for the second.
Read this next → Best AI Tools to Manage Ad Campaigns
Where MCP sits among the other AI options — platform-native automation, bid tools and agentic platforms — and which category actually solves which problem.
What Should You Take from This?
Transport decides client support. Local stdio servers cannot reach browser-based clients or mobile, and that is structural.
"Local is safer" is incomplete. Local means fewer parties hold credentials; hosted means they are scoped, revocable and auditable.
The July 2026 spec mandates OAuth 2.1 with PKCE for remote servers, which is what ad platforms expect.
Self-hosting is free in licence and expensive in attention — you absorb every platform API change yourself.
Works Wherever Your Team Already Is
Brandlio is hosted, so it runs in Claude and ChatGPT on the web, on desktop, and on mobile — one OAuth flow per account, revocable from the platform's own settings. See pricing or connect your first account.
Frequently Asked Questions
What is the difference between a remote and a local MCP server?
A local server runs as a process on your own machine and communicates over standard input and output, so it only works with desktop applications. A remote or hosted server runs elsewhere and communicates over HTTP, so it works with browser-based clients, desktop apps and mobile alike.
Can I use a local MCP server with ChatGPT on the web?
No. A browser tab cannot spawn a process on your laptop, so stdio-based local servers are unreachable from web clients. This is a property of the transport rather than a configuration problem, and it is the constraint that decides the question for most teams.
Is a local MCP server more secure?
It is different rather than strictly safer. Local means credentials stay on your machine and no third party holds a token — but they are only as protected as that machine, invisible to access audits, and forgotten when someone leaves. Hosted means a vendor holds a scoped, revocable OAuth token that appears in your platform's connected-apps list.
What does the 2026 MCP spec change about remote servers?
The July 2026 specification mandates OAuth 2.1 with PKCE for remote connections and moves the protocol to a stateless request/response core. In practice a compliant hosted server authenticates the way ad platforms expect, rather than holding credentials, which is the distinction that matters for account safety.
How much maintenance does self-hosting involve?
More than it looks. Ad platform APIs deprecate versions, rename fields, change rate limits and revise OAuth scopes continuously. A hosted provider absorbs those changes; self-hosting means you discover them when something breaks. You also own deployment, updates, secrets rotation and API quotas.
When should I choose local?
When your security policy prohibits third-party token custody, when you have engineering capacity and want to inspect or modify the code, or when you are one person working in a single desktop client. In those cases self-hosting is the right answer rather than a compromise.
What is the main risk of a hosted server?
Vendor dependency. You rely on their uptime, their normalisation logic and their handling of a token that can read and often write to your ad accounts. An outage on their side is an outage on yours, and if they shut down you migrate. Self-hosting does not carry those risks.
Can I run both?
Yes, MCP clients support multiple servers. It is a reasonable way to evaluate, though running both permanently duplicates tools in the model's context and can make it less certain which to call. Most teams settle on one after a short comparison period.
