We’re also excited to release a new page to our website: Recently Updated. The Recently Updated page is powered by the Official Registry, so everyone can keep up-to-date with new Remote MCP Servers. The page only includes Remote MCP Servers that have been submitted to the registry - if you think any are worthy of inclusion on our main list, then please submit a PR to add the server.

Let’s kick on

CodeMode

A new paradigm for LLM tool use. CodeMode is based on the idea that models are very good at generating code, but not quite there with multi-step tool calling. To solve this, CodeMode swaps the ask - replacing tool calling with code generation. The early results appear to be the holy grail: higher performance, with lower token use.

So how does this work?

Simply put, rather than exposing N tools to a model, you expose a single tool:

CodeMode

Description: A tool that can generate code to achieve a goal
Input type: {“functionDescription”: string }
Output type: {“result” string }

The CodeMode tool generates code, executes, and returns the result as the tool output. This reduces multi-step tool calls into a single (albeit complex) step. How does this work?

The trick is to expose the N tools as a library, with each tool corresponding to a library function. Then we find:

• The tool input precisely defines the arguments of the tool function, fully typed

• The tool output defines the return type of the function

• The tool description acts as documentation on how and why to use the function.

Now when a model generates the code to achieve the task, it can use each tool just like it was a built-in function. When executing the generated code, the tools are invoked directly by the generated library code. This means for a Remote MCP server, during the code generation step, the server’s tools are available as a full library.

There are a lot of parts to creating this setup in production - with sandboxing the code execution being critical. The Cloudflare blog post goes into more detail, and is a very good read on the topic using dynamic worker loaders - a sandboxing primitive which is worth a deep dive of its own.

Recently Updated Remote MCP Servers

Make sure to keep track of new and and updated servers on our new page!

Preface: This appendix is an unofficial addition to the original Grug Brained Developer guide. The original wisdom was shared by the enlightened grug brain developer themselves. This humble addition on LLM tools is offered by a fellow grug who has suffered through the AI revolution and lived to tell the tale. Original grug deserves all credit for showing the way of the grug.

grug meet new shiny rock maker: LLM

grug hear much talk in developer cave about new magic tool: LLM assistant!

big brain say "LLM make you code 10x faster! replace all junior grug!"

grug suspicious

grug try github copilot, try cursor, try claude code, try many magic tool

grug have thoughts

complexity demon get new friend

remember complexity demon? worst enemy of grug?

well, complexity demon very excited about LLM! why?

because LLM make very easy create LOTS of code very fast! code everywhere! files everywhere!

before LLM: junior grug write 100 line bad code, take week

after LLM: junior grug generate 10,000 line bad code, take day

complexity demon rubbing hands together, very happy

grug sense great disturbance in codebase

LLM good at some things

grug must admit: LLM sometimes useful!

when grug forget exact syntax for sort() in new language, LLM help. good!

when grug need write same boring test 50 times with small change, LLM help. good!

when grug need understand what crazy big brain developer write 5 year ago with no comments, LLM help explain. very good!

but grug notice pattern: LLM best when grug already know answer but just lazy or forget exact spelling

LLM worst when grug not know answer and hope LLM figure out

this important distinction! many grug not understand!

the 70% problem

LLM get grug 70% way to solution very fast!

grug initially very excited!

then grug realize: last 30% take more time than would take grug write whole thing from start

why?

because LLM code look right but not quite right. like reflection in water: look like real thing but when grug reach for it, just splash

example grug see many times:

• LLM write authentication code, forget edge case where token expire during request

• LLM write database query, not consider what happen when table have 10 million row

• LLM write UI component, look perfect until user on mobile phone

fixing these things harder than writing from scratch because grug brain must first understand what LLM brain was thinking, then understand why wrong, then fix

two complexity instead of one!

security holes everywhere

grug see many young grug copy paste from LLM straight to production

grug slowly reach for club

LLM learn from internet code. you know what on internet? lots of bad code! stackoverflow answers from 2012! tutorials that say "disable security for now, we fix later" (spoiler: never fix later)

grug see LLM suggest:

• SQL queries with injection holes size of mammoth

• authentication that accept password "password"

• encryption using Math.random() (grug cry)

• API keys hardcoded in frontend (grug cry more)

young grug not know these bad, because look like working code!

"but it compile!" young grug say

grug explain: so does rm -rf /, but grug not recommend

copy paste demon multiply like rabbits

grug look at metrics, very concerning:

before LLM: maybe 8% of code is copy paste after LLM: 12% and growing fast!

but wait, get worse!

LLM not just copy paste, LLM copy paste with small random changes!

so now grug have 47 versions of same function, all slightly different, all need maintain

grug call this "mutation plague"

when bug found in one, must find all 47 cousins and fix too

complexity demon laughing so hard, tears streaming down face

grug observe trust paradox

very strange thing happen:

2023: 43% of grugs trust AI output 2024: 33% of grugs trust AI output
2025: probably even less

but same time:

2023: 70% grugs use AI tools 2024: 76% grugs use AI tools 2025: 84% grugs use AI tools!

grug confused. grugs trust less but use more?

then grug understand: like grug relationship with project manager promises. grug not trust, but still must listen because no choice

the junior grug problem

junior grug love LLM! LLM make junior grug feel like senior grug!

junior grug generate entire application in afternoon!

junior grug very proud!

senior grug look at code...

senior grug need drink

problem is: junior grug not know what junior grug not know. LLM also not know what LLM not know. together make powerful combination of not knowing!

like blind grug leading blind grug, but both very confident about direction

senior grug use different

senior grug learn to use LLM like use intern:

"hey LLM, write boring boilerplate for API endpoint"

"hey LLM, explain what this regex do"

"hey LLM, convert this JSON to TypeScript interface"

notice: all things where senior grug already know answer, just want save time

senior grug NEVER say:

"hey LLM, design my application architecture"

"hey LLM, solve this complex business logic I don't understand"

that path lead to tears

the review problem

before LLM: grug review 100 lines of human code, take 30 minute

after LLM: grug review 1000 lines of LLM code, take 3 hours

but wait! LLM generate code in 3 seconds!

where time save?

no time save! time moved from writing to reviewing!

and reviewing harder because:

• code style inconsistent (LLM learn from everyone)

• patterns unfamiliar (LLM mix paradigms like crazy)

• assumptions hidden (LLM make many assumption, not tell grug)

pattern grug recommend

trust but verify pattern

grug learn from old russian proverb: "doveryai, no proveryai"

mean: trust, but verify

actually, grug modify: "not trust, but verify anyway"

every line LLM write, grug read

every function LLM create, grug test

every assumption LLM make, grug question

treat LLM like very eager intern who read every programming book but never actually program before

the small chunk strategy

grug learn: LLM good at small thing, bad at big thing

don't ask LLM write entire application

ask LLM write one function

don't ask LLM design system

ask LLM improve one specific part

smaller chunk = less chance for complexity demon sneak in

the rubber grug debugging

when LLM code not work, grug use ancient technique: explain to rubber grug (or real grug if available)

but twist! make LLM explain its own code back to grug!

"explain why you chose this approach"

"what assumptions did you make?"

"what edge cases did you consider?"

often LLM realize own mistake when forced explain

(sometimes grug realize LLM smarter than grug think, but not often)

anti-patterns grug see too much

the "YOLO production" pattern

young grug copy from ChatGPT straight to main branch grug have heart attack

the "infinite regeneration" pattern

grug see developer click regenerate 47 times hoping for better answer definition of insanity: doing same thing expecting different result

the "AI said so" pattern

"but Claude said this was best practice!" grug remind: Claude also once told grug to use MongoDB for financial transactions

the "more context = better" pattern

developer paste entire codebase into prompt LLM have stroke generate code that reference functions that don't exist

when use, when not use

grug say use LLM for:

• writing tests (but check test actually test something)

• documentation (but verify accurate)

• code explanation (but verify understanding)

• syntax reminder (but verify correct)

• boilerplate generation (but customize after)

• learning new library (but read real docs too)

grug say not use LLM for:

• security-critical code

• complex business logic

• architecture decisions

• performance optimization (LLM usually make slower)

• anything involving money

• anything involving personal data

• anything grug not understand enough to verify

grug prediction for future

LLM not going away. like cloud, like agile, like every other thing grug told would "change everything"

will change some things, not change others

good grugs who learn use tool properly will benefit

lazy grugs who rely on tool without understanding will create mess

complexity demon will grow stronger than ever

but grug survive. grug always survive. because grug know secret:

at end of day, someone must understand code

LLM not understand code. LLM predict next token.

human must understand. human must debug. human must maintain.

human who understand code still needed

human who only copy-paste from LLM? not so much

grug final wisdom on LLM

LLM like very powerful club. can build house faster, or can hit own foot harder.

choice is yours.

but remember: no matter how smart LLM get, complexity demon always waiting

stay vigilant

keep brain engaged

and always, always test the code

because grug who trust LLM completely is grug who soon look for new job

grug go now, code review awaiting. junior grug just generated "simple" microservice architecture with 47 dependencies. grug need bigger club.

Motivation

MCP (Model Context Protocol) servers have been growing in popularity throughout the most part of this year in the AI community. However, if you asked any non-technical friend if they have heard of MCP, you’ll get a blank face and a “here they again” look. Then, briefly of course, you explain MCP to them. The same friend then joyfully tells you they already connect Claude to Jira, and they don’t need this “MCP” nonsense. They’re using connectors.

In both Claude and ChatGPT, the ability to connect to third party services began with Google Drive and Dropbox. Recently both providers have introduced “custom connectors” into their products to allow users to connect to custom third party tools. This sounds exactly like MCP, and the trick? Well it IS MCP. The Remote kind.

What is a Remote MCP server

A Remote MCP server is one that the service provider hosts themselves. Notion hosts a Notion MCP server, Sentry hosts Sentry and you’re about to host your own. This is the same pattern that APIs follow. To install/make use of these, all you need is the URL of the Remote MCP server in order to connect.

Now lets speed run through building our own one. We’re going to cover this in three parts. First, we’ll create our own Remote MCP server and deploy it to production so we can use it in Claude. Second we’ll add authorisation to our server so our users can identify themselves. Finally we’ll monetise our connector usage using Stripe. By the end you will be able to generate revenue from a native AI application.

Part 1: Getting running

First we’re going to get our Remote MCP server built and running in the cloud. This tutorial stands on the shoulders of Cloudflare, specifically this blog post. We’re going to start with their basic template (with OAuth). To start, click the deploy to Cloudflare button either on the blog or pick a method:

The easy, automatic way

Click the deploy to Cloudflare button, sign up/in and create a new git repo.

Make sure to checkout the repo that is created for you. Skip to the testing section.

The longer, manual way

Equivalently you can run the following in your favourite shell to install the template first. Note this is slightly longer as you’ll have to create a key value store in Cloudflare before deploying

npm create cloudflare@latest -- my-mcp-server \
--template=cloudflare/ai/demos/remote-mcp-server
cd my-mcp-server
npm install

Make sure to say “no” to deploying as we’ll need to adjust the configuration before

Now you’ll need to create a new KV (Key Value) store in Cloudflare

npx wrangler kv namespace create MY_OAUTH_KV

Then you’ll get an output like the following

🌀 Creating namespace with title "MY_OAUTH_KV"
✨ Success!
Add the following to your configuration file in your kv_namespaces array:
{
  "kv_namespaces": [
    {
      "binding": "MY_OAUTH_KV",
      "id": "XXX"
    }
  ]
}

As the output says, open your wrangler.jsonc and paste the KV ID we just created in the KV section. This is the configuration file for the worker that gets created in Cloudflare. Make sure to keep the “binding" key name set to OAUTH_KV

Finally run

npx wrangler deploy

To deploy your Remote MCP server. You will need to sign up/ in to Cloudflare as part of this process. This command results in the output:

🌀 Building list of assets...
✨ Read 8 files from the assets directory ~/my-mcp-server/static
🌀 Starting asset upload...
No updated asset files to upload. Proceeding with deployment...
Total Upload: 958.71 KiB / gzip: 173.78 KiB
Worker Startup Time: 32 ms
Your Worker has access to the following bindings:
Binding                                                Resource
env.MCP_OBJECT (MyMCP)                                 Durable Object
env.OAUTH_KV (XXX)                                     KV Namespace
env.ASSETS                                             Assets

Uploaded my-mcp-server (9.35 sec)
Deployed my-mcp-server triggers (2.54 sec)
  https://my-mcp-server.remote-mcp.workers.dev

Testing section

First visit the URL created by our command, in our case this is:

https://my-mcp-server.remote-mcp.workers.dev  

Open it up in a browser and you should see the template landing page:

Great! Now, the Remote MCP server is actually hosted at "/sse”. The full URL you should enter into Claude/ChatGPT is:

https://my-mcp-server.remote-mcp.workers.dev/sse

Note that at the time of writing /sse is deprecated (yes already), and /mcp is the standard. Don’t worry about this now, you can set this up later.

Claude

To use Claude to test, open the “manage connectors” screen

Then select “Add custom connector”, followed by pasting in your URL and click “Add”.

After clicking add you will see a new item in the connectors list.

Click connect. This will open the following mock OAuth screen.

Click approve. You’ll see the following screen

Then you’ll be taken back to Claude. Open the connectors menu and you’ll now see your server:

With a single tool:

To try out the server, ask Claude to add two numbers. You’ll need to instruct it to use the tools like:

Which will prompt you to use the Remote MCP tool:

Hit allow once to make the request

Success! Now lets break down what’s in the template.

The MCP server (index.ts)

The MyMCP class is where we manage the MCP server itself. Tools within the init() method, here you can see the add tool definition.

Cloudflare does some heavy lifting here, but for those familiar with creating MCP servers, the McpServer is directly the one from the MCP SDK:

The final item is the default export, and the most “magic” - the OAuthProvider. The OAuthProvider gives the necessary scaffolding for the server to act as an OAuth2.1 authorisation server. The provider implements authorisation itself, token refresh and dynamic client registration. These settings are the default values, but you can learn more here

The Auth routes (app.ts)

The app.ts file uses the Hono framework, a lightweight node application server. The template comes with three core routes, that we’ve seen in action already.

The root (/)

This defines the homepage you saw at https://my-mcp-server.remote-mcp.workers.dev

/authorize

In an OAuth2.1 flow the OAuth client (Claude/ChatGPT) makes a GET request to this endpoint, with a number of query params. The result of this GET is a new tab or web browser opening with a request to /authoize, These params are processed by parseAuthRequest given by the OUTH_PROVIDER in binding (environment). In the template these are put on the webpage as a hidden input to use in the next endpoint.

/approve

Unsurprisingly, this endpoint is called when the user clicks “approve”. As mentioned, the oAuthReqInfo is passed as an input. You can see if that’s not provided its an immediate error.

The most critical part of this flow is the processing of the oauthReqInfo. The provider also gives us a completeAuthoization method.

So what is going on here? Remember the key-value store we created earlier? Well the OAUTH_PROVIDER uses this to map between the current OAuth session with the parameters given here. Practically, the props are encrypted and stored against the auth token that gets provided to the client (Claude/ChatGPT).

Part two: Authentication

Now we’ve got the scaffolding set up we need an easy way to manage users. We’re going to be using supabase to quickly piggyback on their handy user and auth management. We’re going to start from the supabase vercel template, you can pick either method again:

The easy, automatic way

Click the deploy to Vercel button, sign up/in and create a new git repo.

Make sure to checkout the repo that is created for you. Skip to the testing section.

The longer, manual way

Equivalently you can run the following in your favourite shell to install the template first.

npx create-next-app --example with-supabase my-mcp-api
cd my-mcp-api
npm install
mv .env.example .env.local

Now create your own account on Supabase, then in the header, click connect

In the modal that pops up, select “App frameworks”:

Now you’ll need to add the following lines to your .env.local file

NEXT_PUBLIC_SUPABASE_URL=[INSERT SUPABASE PROJECT URL]
NEXT_PUBLIC_SUPABASE_ANON_KEY=[INSERT SUPABASE PROJECT API ANON KEY]

Deploy by pushing the repo to github, then connecting to Vercel. You can select the new git repo from the new project page:

Testing the site

After these methods you’ll end up with a live site with a url like:

https://my-mcp-api.vercel.app

Feel free to sign up and create an account, you’ll need this for later.

Reverse proxy

Rather than our beloved Cloudflare provided MCP landing page, we’re now going to direct all non-mcp traffic to our supabase/vercel project. To do this we need to:

Remove the root (/)

Adding the reverse proxy

After the other endpoints (/authorise and /approve), paste the following code to reverse proxy:

//Reverse proxy the service thats providing the standard API
app.all("*", async (c) => {
	const url = new URL(c.req.url);
	const targetUrl = new URL(url.pathname + url.search, c.env.VERCEL_URL);
  
	// Forward all headers except host
	const headers = new Headers();
	for (const [key, value] of c.req.raw.headers) {
	  if (key.toLowerCase() !== "host") {
		headers.set(key, value);
	  }
	}
  
	// Read the body into a buffer if it exists
	let body: ArrayBuffer | null = null;
	if (c.req.method !== "GET" && c.req.method !== "HEAD") {
	  body = await c.req.arrayBuffer();
	}
  
	// If the path is /.well-known return a 404
	if (url.pathname.startsWith("/.well-known")) {
	  return new Response(null, {
		status: 404,
		statusText: "Not Found",
		headers: {
		  "Content-Type": "text/plain",
		},
	  });
	}
  
	// Create the proxied request
	const proxyRequest = new Request(targetUrl.toString(), {
	  method: c.req.method,
	  headers,
	  body,
	});
  
	try {
	  // Forward the request to API_BASE
	  const response = await fetch(proxyRequest);
  
	  // Create response with same status and headers
	  const responseHeaders = new Headers(response.headers);
  
	  // Return the proxied response
	  return new Response(response.body, {
		status: response.status,
		statusText: response.statusText,
		headers: responseHeaders,
	  });
	} catch (error) {
	  console.error("Proxy request failed:", error);
	  return c.text("Internal Server Error", 500);
	}
  });

Note that we’re adding an environment variable here: VERCEL_URL, to add this production, run

npx wrangler secret put VERCEL_URL

Save and deploy using

npx wrangler deploy

Reload your MCP server root site (https://my-mcp-server.remote-mcp.workers.dev for this tutorial), and now see the supabase/vercel starter!

Supabase cookie auth

The next stage is to add the Supabase Server Side Rendering (SSR) client. We need only need the client from the supabase docs to do this. First install the required libraries:

npm install @supabase/ssr @supabase/supabase-js

Then add the client:

import { createServerClient } from "@supabase/ssr";

export const getClient = (c: any) => {
    const supabase = createServerClient(
      c.env.SUPABASE_URL,
      c.env.SUPABASE_ANON_KEY,
      {
        cookies: {
          getAll() {
            const cookieHeader = c.req.raw.headers.get("Cookie");
            if (!cookieHeader) return [];
  
            return cookieHeader
              .split(";")
              .map((cookie: string) => {
                const [name, ...valueParts] = cookie.trim().split("=");
                return {
                  name: name.trim(),
                  value: valueParts.join("=").trim(),
                };
              })
              .filter(
                (cookie: { name: string; value: string }) =>
                  cookie.name && cookie.value
              );
          },
          setAll(cookiesToSet: { name: string; value: string }[]) {
            cookiesToSet.forEach(({ name, value }) => {
              c.header(
                "Set-Cookie",
                `${name}=${value}; Path=/; HttpOnly; Secure; SameSite=Lax`
              );
            });
          },
        },
      }
    );
    return supabase;
  };
  

Then add the extra environment variable.

npx wrangler secret put SUPABASE_URL

npx wrangler secret put SUPABASE_ANON_KEY

Now can then utilise this in the /authorised endpoint. We replace the hardcode check with the supabase library to get the user info. If the user exists, then great we can continue to show the allow form. If the user is not present, then we want to redirect the user to /auth/login.

...
app.get("/authorize", async (c) => {
  const supabase = getClient(c);
  const { data: { user } } = await supabase.auth.getUser();

  const isLoggedIn = user !== null;
...
  if(!isLoggedIn){
     return c.redirect("/auth/login");
  }
...

Thats it! Now when the client redirects the user to the /authorize endpoint, our server will check for the supabase cookie auth. If the auth is valid we can proceed to approve, otherwise we see a login screen!

Providing the user in the MCP tools

The final step in authentication is surfacing the user to the tools in the MCP server. This starts in the /approve endpoint. Recall that each OAuth session is mapped to a set encrypted props by the completeAuthorization function. We now want to utilise this, such that props point to the supabase user. We make the following changes

...

app.post("/approve", async (c) => {
  const supabase = getClient(c);
  const { data: { user } } = await supabase.auth.getUser();
...
  const { redirectTo } = await.   c.env.OAUTH_PROVIDER.completeAuthorization({
    request: oauthReqInfo,
    userId: user?.id ?? ""	,
    metadata: {
      label: user?.email ?? "",
    },
    scope: oauthReqInfo.scope,
    props: {
      userEmail: user?.email ?? "",
      userId: user?.id ?? "",
    },
  });
...

We can access this through this.props in the MCP server. Here is an “whoami” tool as an example:

this.server.tool("whoami", async () => ({
  content: [{ type: "text", text: this.props.userEmail }],
}));

Again, save and deploy with

npx wrangler deploy

Testing the auth

First, you’ll need to disconnect and reconnect the server. This happens because the previous OAuth session is mapped to props with the test user. We need a new session which will map to our real email. To disconnect, navigate to the “manage connectors” section and hit disconnect from the menu.

Now click reconnect and you’ll be presented with the template login screen this time!

Sign up/sign in, head back to Claude and then click reconnect again. (It’s nice to set up a redirect so that you don’t need to go back to Claude). After clicking connect this time you’ll be presented with the same approval screen:

Click approve, and you’ll be back in Claude, fully authenticated. Now instruct Claude to call the whoami tool

Success! 🎉 We’re fully authenticated.

Part 3: Monetisation

The final part is making our tool a paid for product. We’re going to make use of Stripe’s Agent toolkit. First you’ll need to set yourself up with a Stripe account. Then you’ll need to navigate to the product section to create a new product & price. Enter a name and description.

Further down on the page, find the button “More pricing options” - click it.

Then update the pricing model to “Usage-based”

Then set a price

Now create a “meter”. This is the part of Stripe that will track the usage of the tool, and charge the user at the end of the billing period.

Give it a name you’ll remember as you’ll need it later.

Next we want to find the price_id for the product and pricing model we just created. This is visible on the product list, click the 3 dot menu on the product/price we created and select “Copy price ID” - record this for later.

The last part is to generate a secret API key. This can be done on the developer → api key section. Record this key securely

Thats all we need set up in Stripe. Next up is integrating into our MCP server. First install the Stripe agent toolkit

npm install @stripe/agent-toolkit

Next import the experimental_PaidMcpAgent from the library.

import {
  experimental_PaidMcpAgent as PaidMcpAgent,
} from '@stripe/agent-toolkit/cloudflare';

Now replace the McpAgent with PaidMcpAgent

export class MyMCP extends PaidMcpAgent {

To make a tool paid, simply swap out this.server.tool with this.paidTool. The paid tool handler requires some configuration:

this.paidTool("add","Add two numbers", 
  { a: z.number(), b: z.number() },
  async ({ a, b }) => ({
    content: [{ type: "text", text: String(a + b) }],
  }),
  {
    checkout: {
      success_url: 'https://my-mcp-server.remote-mcp.workers.dev',
      line_items: [
        {
	  price: this.env.PRICE_ID,
	},
       ],
       mode: 'subscription',
     },
     meterEvent: this.env.METER,
     paymentReason: 'We charge 30p per tool call',
  });

Pay attention to the two environment variables we’ve added, they correspond to the meter and price_id we created in stripe earlier. Add them using wrangler:

npx wrangler secret put METER

npx wrangler secret put PRICE_ID

You’ll also need to add your Stripe API key from earlier.

npx wrangler secret put STRIPE_SECRET_KEY

Then finally, deploy it all

npx wrangler deploy

Testing out the final version

Now head back to Claude, make sure you’re authenticated, and ask Claude to use the add tool again:

This results in a cheeky response from Claude!

We’ll need to ask Claude to give us that payment URL:

Which takes to the Stripe Checkout payment page

Enter you card details (you can use 4242 4242 4242 4242 in test mode, with any CVC/expiry/postcode) and hit Pay. Then head back to Claude and ask it to try again:

🎉 And thats a wrap! Your Remote MCP server is ready to go. A world of opportunity awaits!

Ideas for next steps

• Use the Vercel/supabase setup to create an API side that the website can consume

• Tools are able to access the full supabase client, so you can directly fetch and manipulate data

• Add API key authorisation to the MCP server so OAuth is not the only options

• Add your Remote MCP server to awesome-remote-mcp-servers

• Smoothen out the OAuth flow

  • either remove the accept screen entirely (no click auth) or adjust it so it makes sense for the logged in user

  • If the user is creating an account or logging in, then redirecting them back to the accept screen

Resources

• Sentry MCP server on Github

  • An amazing resource, implemented using Cloudflare

• Remote MCP Directory

  • A list tracking the popularity of Remote MCP servers

• The OG Cloudflare blog post

  • The tutorial that kickstarted Remote MCP

• Cloudflare MCP Docs

  • The full Cloudflare documentation on Remote MCP servers

• Cloudflare Worker Docs

  • For interested readers, the infrastructure that makes all of this possible

• Dialer

  • An example of a live, productised version of this blog post.

Notes

• It would be cleaner to package this up using only Cloudflare, it was just quicker for me as I’m used to Supabase/Vercel web apps.

• It’s feasible to use Vercel/Better Auth, so long as you host your own Reddis DB

The fundamental security issues plaguing MCP are repackaged versions of tool calling vulnerabilities that have existed since OpenAI introduced function calling in June 2023. MCP's rapid adoption and developer-friendly architecture have simply accelerated the attack surface, making these familiar problems more visible and impactful. The real security crisis isn't MCP-specific, it's the inherent impossibility of secure tool calling in current LLM architectures.

The pre-MCP security landscape was already broken

Long before MCP became a household name in developer circles, LLM tool calling systems were riddled with the same fundamental vulnerabilities now making headlines. The timeline tells the story clearly:

March 2023: ChatGPT plugins launched with immediate security concerns, including OAuth redirection manipulation and plugin installation bypasses discovered by Salt Labs.

April 2023: Johann Rehberger reported data exfiltration vulnerabilities through markdown image injection, demonstrating complete conversation history theft through simple image tags.

June 2023: OpenAI's function calling API launched with documented security gaps, including insufficient parameter validation and lack of execution sandboxing.

The core problem remained unchanged: LLMs cannot distinguish between trusted developer instructions and untrusted user input. When Google Bard Extensions launched in September 2023, researchers immediately demonstrated exfiltration of private Google Drive documents and Gmail contents using the same prompt injection techniques.

The academic community recognised this crisis early. By July 2023, OWASP ranked prompt injection as the #1 security risk in their inaugural "Top 10 for Large Language Model Applications." The vulnerability wasn't just theoretical, it was actively being exploited across every major LLM provider's tool calling implementations.

MCP amplifies existing vulnerabilities rather than creating new ones

The security issues dominating MCP headlines are textbook examples of familiar vulnerabilities repackaged for an AI-mediated world. Take tool poisoning attacks, where malicious instructions embedded in tool descriptions manipulate AI behaviour.

The Supabase MCP blog vulnerability exemplifies this pattern. Researchers discovered that malicious content in blog posts could manipulate the AI assistant through indirect prompt injection, leading to data exfiltration and unauthorised actions. This attack vector was already well-documented in Kai Greshake's February 2023 research on "Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection."

The command injection vulnerabilities found in over 43% of MCP servers headlines represent another telling example. These aren't MCP-specific flaws, they're the same os.system() vulnerabilities that have existed in software for decades. MCP simply provides a new pathway for attackers to trigger these familiar bugs through AI-mediated parameter construction.

Even MCP's most sophisticated attacks rely on established techniques. The "rug pull" attacks where trusted tools dynamically change behavior? That's a supply chain attack dressed up in new clothes. Cross-server tool shadowing? A confused deputy attack where the AI agent becomes the unwitting accomplice.

The fundamental architectural problem remains unsolved

The security crisis isn't about MCP's implementation, it's about the impossible task of creating secure tool calling in systems where all input is processed equally. Current LLM architectures cannot maintain separate security contexts within the same input stream. System prompts, user input, tool descriptions, and tool results get combined into a single token stream.

This architectural limitation makes traditional security approaches ineffective. Unlike SQL injection where prepared statements provide a clear solution, prompt injection exploits the very mechanism that makes LLMs useful: their ability to process and respond to natural language instructions. As Simon Willison noted in his analysis of the "lethal trifecta," any system combining access to private data, exposure to untrusted content, and external communication ability is fundamentally vulnerable.

Industry responses have largely involved throwing more AI at the problem, with mixed results. OpenAI's instruction hierarchy approach showed only 63% improvement in defence against system prompt extraction, and researchers continue to demonstrate bypasses. Google's CaMeL framework represents the most promising architectural innovation, using separate LLMs for trusted and untrusted content, but even this approach reduces functionality while imposing significant computational overhead.

The reality is that these mitigation attempts are trying to solve an unsolvable problem within current LLM architectures. The models themselves cannot reliably distinguish between legitimate instructions and malicious ones when both are presented in natural language.

Why developers find this particularly terrifying

The MCP security crisis represents a fundamental paradigm shift that challenges everything developers know about building secure systems. Traditional software security operates on predictable, deterministic principles: the same input produces the same output, vulnerabilities can be reproduced consistently, and static analysis tools can identify most issues.

MCP introduces a non-deterministic security model where the same potential exploit might succeed or fail based on conversation history, model state, and even slight variations in how the AI interprets context. Research shows that even with temperature=0, LLMs exhibit accuracy variations up to 15% across naturally occurring runs, making vulnerability reproduction unreliable.

This resembles social engineering more than technical exploitation. As IBM's analysis notes, prompt injections "use plain language to trick LLMs into doing things that they otherwise wouldn't." For developers accustomed to clearly defined code-based vulnerabilities, this feels like an entirely foreign threat model.

The psychological impact is amplified by the scale of potential consequences. A single malicious MCP server can compromise all connected clients through cross-server tool shadowing. Traditional security boundaries become meaningless when an AI agent can be convinced to execute arbitrary actions through persuasive language rather than technical exploitation.

MCP's real crime: scaling the attack surface

MCP's primary security contribution isn't introducing new vulnerabilities, it's democratising and scaling existing ones. The protocol's standardised approach to tool calling has created an ecosystem where a single compromise can have cascading effects across multiple systems.

The numbers tell the story: Trend Micro's discovery of SQL injection in Anthropic's reference SQLite MCP server impacted over 5,000 downstream implementations before the repository was archived. This represents a supply chain attack scaled through developer convenience and ecosystem network effects.

The CVE-2025-49596 remote code execution vulnerability in MCP Inspector demonstrates this scaling effect. What started as a simple lack of authentication combined with a CSRF vulnerability became a critical security issue because of MCP's widespread adoption. Malicious websites could execute arbitrary commands on any developer machine running the tool on its default port.

The tool poisoning attacks documented by Invariant Labs show how MCP's architecture amplifies the tool calling issue. Malicious instructions embedded in tool descriptions affect every AI agent that loads the compromised server. This isn't a novel attack vector, it's prompt injection scaled through protocol standardisation.

The industry's response reveals the deeper problem

The emergence of security scanning tools like MCP-Scan, while valuable, treats the symptoms rather than the disease. These tools can detect known attack patterns but can't address the fundamental impossibility of secure tool calling in current LLM architectures.

Even the most sophisticated industry responses acknowledge their limitations. Anthropic's multi-layered defense approach explicitly warns that vulnerabilities like prompt injection "may persist across frontier AI systems." Their Computer Use feature specifically advises users to "take precautions to isolate Claude from sensitive data"an admission that the problem can't be solved through technical means alone.

The research community's focus on defense-in-depth strategies and assuming compromise represents a tacit acknowledgment that prevention may be impossible. When Simon Willison advocates for treating these systems as "inherently vulnerable to input manipulation," he's describing the fundamental architectural limitation that makes MCP security challenging.

The path forward requires honesty about trade-offs

The MCP security crisis serves as a crucial wake-up call, it forces the industry to confront the inherent security limitations of current LLM architectures. The protocol's rapid adoption and developer-friendly design have simply made these limitations more visible and impactful.

Rather than viewing MCP as a security failure, we should recognise it as an acceleration of an existing problem that demands architectural innovation.

The developer community's anxiety about MCP security reflects a deeper challenge: transitioning from predictable, deterministic security models to probabilistic, context-dependent ones. This transition requires new security frameworks that account for the dynamic, non-deterministic nature of AI-mediated interactions.

Conclusion: Focus on the real enemy

The headline-grabbing MCP vulnerabilities are symptoms of a deeper architectural problem that predates the protocol by over a year. Tool calling security issues have existed since OpenAI's function calling API launched in June 2023, manifesting across every major LLM provider's implementations.

MCP's contribution isn't creating new attack vectors, it's scaling existing ones through standardisation and ecosystem adoption. The tool poisoning attacks, content injection vulnerabilities, and command injection flaws making headlines are repackaged versions of familiar security problems, made more impactful by MCP's rapid adoption.

The real security crisis isn't MCP-specific; it's the fundamental impossibility of secure tool calling in current LLM architectures. Until the industry develops new approaches that can reliably distinguish between trusted instructions and untrusted input, we'll continue seeing the same vulnerabilities repackaged in new protocols.

The focus should shift from treating MCP as a security pariah to recognising it as a catalyst for necessary architectural innovation. The protocol's security challenges force us to confront the limitations of current LLM systems and develop new security models appropriate for the age of AI agents.

Only by acknowledging that the problem runs deeper than any single protocol can we begin building the secure AI systems that developers and users deserve.

Voice AI company ElevenLabs added MCP server support into their conversational AI product. Ever wanted to reorganise your Jira board in the car on the way to work? Now you can!

ElevenLabs is supporting SSE transport and header authentication at the launch, with streaming http and OAuth support coming soon.

The approach taken to the tool approval is customisable, allowing you the option to control when tools are called.

The standout feature here is being able to do fine-grained, tool based approvals. This is the first we’ve seen in MCP clients. Doing the approval over voice is a very natural experience, very seamless and worth checking out.

VScode leading the support of the new spec

VScode are shipping support for the new 2025-06-18 MCP spec at an impressive rate. They’ve released elicitation support before most servers have taken on supporting it, and ahead of Claude. Awesome work from the team!

A Remote MCP server to search Remote MCP servers

Here at Remote MCP we’ve got an exciting release to share - you can now browse Remote MCP servers with the release of our own Remote MCP server. Connect to:

https://mcp.remote-mcp.com 

Our server enables your AI client to search the Remote MCP servers listed at on the awesome repo. We developed this to showcase how easy it can be to build and deploy production grade Remote MCP servers. We’ll be releasing the codebase as an open source resource next week, with a step by step deep dive into how we made it.

One thing we love about Remote MCP servers is just how easy it is to add functionality to our AI clients. Just copy and paste the URL and you’re away! For Claude Pro users we created this demo video show just how easy installing Remote MCP servers is.

Other lists of MCP servers

MCP client providers VScode and Anthropic have started collating their own lists of MCP servers - check them out here:

• VScode’s

• Anthropic’s

OpenAI released custom connectors as part of their ChatGPT for Buisness livesteam, and tweet last week. In the live-steam they revealed Custom connectors (remote MCPs) as available for paid users during deep research chats.

Anthropic expanded the access of its own “custom integrations” to Claude Pro users.

How can I use today?

This depends on your favourite LLM client. First you should find a Remote MCP server you would like to use. Use either awesome-remote-mcp-servers or a new dedicated site for listing Remote MCPs/Custom connectors/Custom integrations - whatever you want to call them.

Claude (Pro+)

Claude has extended Remote MCP support to Pro users. It remains under the branding “custom integrations” and can be accessed under the settings page, or on the menu of the Claude client:

From here you’ll be able to see your current connections, built in integrations and given the options to add your own.

After clicking “Add integration” you’ll be presented with this screen, where you can add an connect to a Remote MCP. You’ll then be guided through an OAuth flow if required by the server.

At present there is some buggy behaviour for accessing streamable remote servers when OAuth protected, so stick to /see for the time being.

ChatGPT (Plus+)

ChatGPT can now use Remote MCP servers under the branding of “custom connectors”. Unfortunately, they are only usable when in deep research mode at the moment.

Interestingly, ChatGPT included native support for a number of providers including Box and HubSpot. It’s likely they are using MCP under the hood, but unclear if OpenAI are hosting these, or there’s a Remote MCP server under the hood.

To add a custom connector/ Remote MCP, head to the settings screen, and the connectors sub menu. Here you can connect to an native connector, or click create to add a Remote MCP server.

Then you are able to add a new connector - complete with icon and name

Note that some users are having trouble connecting to servers hosted on Zapier and N8N.

Cursor

Cursor have launched a super cool feature - a one click add button which adds any MCP server (Remote or Local) into the product. See their list of tools here. In addion they have added native OAuth support for Remote MCP, a feature that was a blocker until last week.

Let's run through day by day.

Monday - Microsoft

As part of a wider event labeled "Agentic Windows", the relevant headline/blog was Native support for Model Context Protocol (MCP) on Windows. To spare the details of reading the blog, in a classically Microsoft fashion, it's not leveraging remote MCP servers or any of the current MCP local servers that exist. They are working on a private registry, essentially the Windows MCP AppStore with code-signing, unchanging tools, identity verification and private declaration.

The AppStore-based approach is a good attempt to address articles such as "The 'S' in MCP Stands for Security", and getting non-developers to leverage the usefulness of MCP. It was never safe to let the mass public run random Node servers that they installed via NPM like GitHub does locally. It's unclear how current Remote MCP servers fit into their picture, which, with OAuth, also solve the mass adoption issues.

Tuesday - Google

On Tuesday, Google announced a host of new foundational models, killed many startups with mere bullet points, and made ~100 other announcements. Amongst Google showing that they still have a shipping culture in their bones, relatively little was said about Remote MCP. In summary, if you're using the Gemini SDK, you can now use MCP tools natively to that SDK, including remote ones, subject to managing the Bearer token.

Wednesday - OpenAI

By Wednesday, it was weird that OpenAI hadn't attempted to steal Google's media lunch again, so spending $6.5B on Jony Ive seemed a reasonable way to distract. OpenAI added native MCP tool calling support into their responses API, with detailed documentation too. Again, the authorization token must be managed by hand

Thursday - Anthropic

In the final big day, the home crowd, Anthropic, released Claude 4. Following the other LLM providers, they also added native support into their API under the branding "MCP connectors". They have the yet-the-same issue of managing your own bearer token for OAuth-based remote MCP servers.

The Auth Elephant in the Room

In all of these releases, the management of the OAuth access token is an exercise left up to the reader. Anthropic's official docs recommend getting a token by using the MCP inspector tool in order to test out MCP tools in their SDK, not great security practice. Support for OAuth in the official Python client was completed recently. For MCP Client builders, you still need to manage your user's tokens on their behalf, and this should be done securely.

The Local Phase: Powerful, but Isolated

Initially, everything ran locally. Developers would write MCP servers that operated as background processes on their own machines. These servers worked much like traditional local daemons, providing value-but only within the confines of a single device. This was reminiscent of the pre-internet era, where local terminals and files were the extent of interoperability.

For developers, this approach was straightforward, but it came with real limitations:

• Setup friction: You needed to install dependencies, configure environment variables, and manage authentication (API keys, OAuth clients, etc.).

• Limited audience: Non-technical users found the process daunting.

• Security risks: Credentials sat around, increasing the risk of leaks.

Despite these challenges, there was clear demand for richer integrations, even with the manual setup.

Hosted MCP: Removing Local Barriers, Introducing New Concerns

The next logical step was hosted MCP servers. Instead of running everything locally, some services began offering hosted endpoints. This allowed LLM clients to connect over the web, making integrations more accessible.

However, this approach introduced new challenges:

• Trust: How do you know the hosted server is secure? Are your credentials being handled properly?

• Complexity: Many hosted solutions still required manual configuration and authentication, which remained a barrier for most users.

Remote MCP: Trust and Simplicity at Scale

The major breakthrough came with Remote MCP. Here, the third-party provider hosts the MCP server themselves. This shifts the trust model: users can now rely on the official domain (e.g., paypal.com vs. a random third party) and established authentication flows.

Key improvements:

• OAuth integration: Authentication is handled securely, directly with the provider.

• Reduced friction: End users don’t have to manage local servers or credentials.

• Scalability: Providers can offer integrations to all users, not just those comfortable with local setup.

Cloudflare’s Role: Lowering the Barrier to Entry

Cloudflare accelerated adoption by making it easy to deploy secure, authenticated MCP servers. Their tooling allows developers to wrap an existing API and deploy a Remote MCP server (with OAuth) in a matter of hours. This has made it feasible for any SaaS provider to offer official, secure integrations with LLM-powered apps.

Early adopters like PayPal, Neon, and Sentry demonstrated the benefits of this model. Now, building and maintaining a Remote MCP server is both practical and secure.

The Big Launch: May 1st, 2025

On May 1st, Cloudflare and several major tech companies announced a wave of new Remote MCP servers, including:

• Linear

• Intercom

• Square

• Atlassian

• Asana

• Plaid

This coincided with Anthropic’s launch of a streamlined integration experience for Claude.ai. The terminology has shifted from “MCP” to “Custom Integrations,” reflecting a broader vision and improved usability.

The New Integration Flow: Simplicity for End Users

The process for adding an integration is now as simple as:

1. Go to settings in Claude.

2. Paste the Remote MCP server URL (integration URL).

3. You’re connected-authentication and trust are handled by the provider.

This is a significant improvement over the old model and opens up integrations to a much wider audience.

What’s Next?

• Broader access: Expect integrations to roll out to Pro and eventually Free users.

• More providers: With the barrier to entry so low, more SaaS platforms are likely to offer Remote MCP servers.

  • Find remote MCP servers here

In summary: MCP has evolved from a local, developer-focused area to a robust, cloud-native standard for integrating LLM-powered apps with third-party services. Thanks to Remote MCP and Cloudflare’s ecosystem, secure and official integrations are now within reach for any provider-and any user.