Ability to customize the .well-known/ directory contents

[fzaninotto]

I have built an authenticated MCP server based on a Supabase service, leveraging Supabase OAuth.

I originally wanted to use Supabase Edge functions for that, but it turns out it's impossible. Since authenticated MCP servers use OAuth, the MCP client must be able to determine the authentication provider for the server by calling the .well-known path on the server. To my knowledge, it is not possible to customize the contents of that resource on a Supabase instance, so I was stuck. I ended up implementing the MCP server in a separate express server, hosted on a domain where I controlled the .well-known contents. This kinds of defeats the purpose of a backend as a service...

Anyway, the MCP server is working but it's cumbersome to host (see https://marmelab.com/atomic-crm/doc/users/mcp-server/ for a demo of what I built).

I wanted to know if there is a new or hidden way to customize the .well-known/ directory contents, or the Supabase team intends to support it in the near future?

Because without OAuth, the ability to build an MCP server with Edge functions, explained in your documentation, cannot be used in production.

[gregnr]

Hey @fzaninotto! We've been working on a solution to the exact problem you are facing called BYO-MCP (build your own MCP on Edge Functions). I agree that auth is the real power of building your own MCP on Supabase. Project level OAuth 2.1 servers was the first step to making this work and this is publicly available now. The second step is to wire this into an Edge Function so that it correctly handles oauth as described in the MCP spec.

You are correct that .well-known paths cannot be customized on Supabase today, but our solution to this actually doesn't require .well-known at all. MCP auth expects a www-authenticate header in the HTTP response which tells the client where to find the protected resource metadata. By default this lives in .well-known, but you can change this to any URL you want, and any spec-compliant client will use that instead. So if your Edge Function was called mcp and lived at https://<ref>.supabase.co/functions/v1/mcp, you could set the protected resource metadata to https://<ref>.supabase.co/functions/v1/mcp/oauth-protected-resource and the same Edge Function can handle both routes.

If you're eager to try this out now, you can reference https://github.com/gregnr/edge-function-mcp-sandbox which manually implements the above auth logic (in mcp/index.ts). We're in the middle of building some lightweight SDKs to wrap this logic so that it's simpler to use, but if you need something working today this should be a good reference.

Hope that helps but let me know if you had any other thoughts or questions about the implementation. We're hoping to have some official docs for this soon.

[fzaninotto]

Hi @gregnr , and thanks a lot for your feedback.

It works! I managed to port my standalone MCP server into an edge function, thanks to the example you posted. I'm super happy to be able to ship the MCP server as an Edge function. If you're curious, it's available at https://github.com/marmelab/atomic-crm/blob/main/supabase/functions/mcp/index.ts. I didn't use Hono as I found it overkill for 2 routes. I also added CORS as calls from web clients (Claude.ai for instance) wouldn't work without it.

Using the www-authenticate header to point to the Edge function was my original attempt, but for some reason it didn't work at the time. I believe the OAuth implementation on the client side (Claude and ChatGPT) wasn't complete.

I met a few bumps:

1. It's impossible to test the MCP server locally. I tried running an ngrok proxy in front of my local instance to make it callable by a web agent, but in the OAuth process the Supabase server keeps pointing to http://127.0.0.1 in its redirection headers, which is doubly wrong (http instead of https, and the localhost that can't be called from outside). I ended up testing in production (!)
2. It's very hard to debug the entire process. And until everything is right, the MCP simply doesn't integrate with any agent. The OAuth server logs are incomprehensible JSON. The Edge functions don't log the POST body by default, so I had to log manually. And because of 1. everything happens in production, so I had to add console.log and redeploying several times - not ideal.
3. The fact that Edge functions use Deno doesn't facilitate the process - it's hard to unit test as soon as there is a dependency, and the versions of the dependencies doesn't automatically match what's in packages.json (and escapes dependabot control). This is more a general remark about Supabase, but IMHO the choice of Deno doesn't bring much but makes many things harder.

But when everything works, this feels miraculous, and the user experience is super fluid.

Again, thank you so much for pointing me in the right direction. I can't wait for the BYO-MCP release!