On a Thursday evening, Nexus had a full-featured REST API and a working dashboard. By Friday morning, it also had a complete MCP server that any AI agent could connect to, authenticate against, and start using without any human involvement. The build took about three hours. Here's exactly what we did and what we learned.
MCP supports two transport mechanisms: stdio (standard input/output, for local process communication) and Streamable HTTP (HTTP-based, for remote services). For a SaaS product with cloud-hosted infrastructure, stdio is a non-starter — it only makes sense for tools running locally on the same machine as the agent. We needed Streamable HTTP.
Streamable HTTP is well-suited for our architecture for a specific reason: it supports both request-response and server-sent event streaming in the same connection. Agents can call a tool and get an immediate response for fast operations, or receive a stream of updates for longer-running ones. This is the right primitive for ecommerce workflows where some calls return instantly and others — like bulk order processing — take time.
We deployed the MCP endpoint as a Supabase Edge Function. This gave us global distribution, automatic scaling, and zero cold-start latency problems — Edge Functions run on Deno and stay warm. The endpoint lives at a stable URL that agents can store and reuse across sessions.
Getting auth right was the most important architectural decision of the night. Human SaaS auth is well-understood: users log in with a password or OAuth, get a session token, and stay authenticated until they log out. Agent auth is different in ways that matter.
Agents don't have browsers. They can't complete an OAuth flow that redirects to a callback URL. They can't type a password. They need a credential they can store and present programmatically — ideally one they can obtain without any human action at all.
We built two Supabase Edge Functions to handle this: agent-register and agent-auth.
agent-register accepts a POST with a JSON body containing the agent's name, a brief description of what it does, and the Nexus account ID it's connecting to. It creates a record in the agent_registrations table in Supabase and returns a client_id and client_secret. No human login required. The account owner can review registered agents in the dashboard and revoke any of them, but they don't have to pre-approve them.
agent-auth accepts the client_id and client_secret and returns a JWT. That JWT carries three important fields in its payload: the account ID, the permission scope (read on the free tier, read:write on paid tiers), and an expiry. The MCP server validates this JWT on every tool call — no database lookup required, just signature verification against our Supabase JWT secret.
Scoped tokens were a deliberate choice. A token that carries its own permissions in the payload means the MCP server can enforce access control at the edge without a round trip to the database. It also means that if we later add more granular scopes — read:orders only, or write:messages only — we can do it without changing the auth architecture.
The zero-human-required registration flow was one of the things we were least sure would work until we actually tested it. Here's the exact sequence:
/functions/v1/agent-register with its name, description, and the Nexus account ID (found in the account dashboard).client_id and client_secret./functions/v1/agent-auth with the credentials and receives a fresh JWT valid for 24 hours.WRITE_ACCESS_REQUIRED if the operation exceeds the token's permissions.The whole sequence takes under two seconds in practice. An agent that's never connected to Nexus before can go from zero to authenticated in its first tool-calling turn.
We started by listing every operation an agent might plausibly need to perform on an ecommerce operation. The list was 40+ items long. We then asked: which of these are on the critical path of the most common agent workflows?
The answer shaped the 13 tools we shipped. Order retrieval and contact retrieval are the entry point for almost every workflow — the agent has to understand the current state before it can do anything. Sending a message is the most common output action. Creating a flag is the escalation primitive that keeps agents from acting on things they shouldn't. Stock checking and shipment tracking are the data sources most often needed for proactive outreach.
The tools we deliberately left out of v1 are the ones that require complex business logic we didn't want to encode in the MCP layer: refund processing, promotion creation, multi-warehouse transfers. These are available via the REST API for teams that need them, but they're not in the MCP server yet because agents making high-stakes financial decisions need more guardrails than we'd built in one night.
The surprise was how much you can accomplish with 13 well-designed tools. Every agent workflow we've tested since — order triage, proactive shipping delay outreach, inventory anomaly detection, customer win-back campaigns — fits within these 13 primitives. The constraint forced clarity.
If you're building your own MCP server, start narrower than you think you should. A small set of tools with excellent descriptions and deterministic behavior is worth ten times a large set of tools with ambiguous parameters and inconsistent outputs. Agents are only as good as the tools you hand them.
Your AI agent can self-register, get a scoped token, and start calling tools in under 5 minutes. Full technical docs at the link below.