What this page covers
This is the architecture write-up from a real build: the production MCP server Node8 delivered for a leading investment research firm, running on Google Cloud and serving Claude, ChatGPT, Microsoft Copilot, and Perplexity. The business context is in the case study and the engagement overview. Here we cover the decisions that mattered, in the order they’ll bite you.
Decide your auth stack first — everything waits on it
The single most consequential early decision was not the framework or the hosting — it was the identity platform. Nothing user-facing can be wired up until auth is settled, and remote MCP servers have unusually specific requirements:
- OAuth 2.1 with PKCE, as the MCP spec requires for remote servers.
- Dynamic client registration, because Claude, ChatGPT, and Copilot each register as distinct OAuth clients, and you’ll add more clients over time. We modeled the assistants as separate client categories from day one.
- Token lifecycle: defined access-token lifespans with refresh flows, so long-running assistant sessions don’t strand users mid-conversation.
- Consumer and enterprise login in one system. Individuals connect with Google or Microsoft social login; enterprise customers need SSO against their own identity provider.
We chose a hosted identity layer (WorkOS) rather than building this in-house. The enterprise pattern it gave us is the one to steal: each corporate customer becomes an organization in the identity layer, with trusted email domains and SSO configured against their IdP — in the first enterprise rollout, Microsoft Entra via OIDC. Onboarding the next enterprise customer is configuration, not code, and the customer’s IT contact can even self-serve the SSO setup through a delegated admin flow.
The user experience this produces is the whole point: a user adds the connector in their assistant, clicks connect, signs in with the account they already have, and is querying proprietary data thirty seconds later.
Two auth planes: user-facing OAuth, machine-to-machine behind it
The subtler design question was how the MCP server should authenticate to the firm’s backend APIs. Two options:
- Pass each user’s credentials through to the backend — which means teaching decades-old internal APIs about OAuth users.
- Authenticate the MCP server to the backend as a single machine identity, and pass the authenticated user ID as a parameter on every call.
We chose the second. The backend keeps one credential to manage (with key rotation), the legacy systems stay untouched by the identity migration, and per-user governance survives because every request carries the user’s identity: the backend rate-limits on the user ID, not the shared machine credential.
Be honest about the cost: this required an API-side change — a new parameter and updated rate-limiting logic — that the firm’s API team had to absorb. It was the right trade, but it’s backend work, and it belongs on the plan from week one.
Task-oriented tools, not endpoint mirrors
The firm’s internal API surface spans hundreds of endpoints. We shipped three tool groups at launch:
- Content history — analyst articles and commentary by ticker, with 100+ content categories behind one interface.
- Company snapshot — overview, earnings estimates, and surprise history.
- Report retrieval — locating and returning analyst report documents by query type.
A second batch of roughly five followed: fundamental ratios, sales estimates, price history, and related datasets. The design principles:
- One tool per user task, not per endpoint. The model composes badly; humans compose in the tool implementation instead.
- Descriptions are the API docs now. Each tool’s name, description, and input schema is what the model reasons over. Write them for the model: what the tool answers, when to use it, what the parameters mean in domain terms.
- Shape the outputs. Return assistant-ready structures, not raw backend payloads. Fewer tokens per response means faster and cheaper conversations — token cost was an explicit design target, not an afterthought.
- Expose knobs deliberately. Where users legitimately need control (period, ticker set, category), make it a parameter; don’t leak internal pagination or backend quirks.
More on why this beats mirroring your API in Why MCP Instead of a Traditional API?.
Hosting and scaling on Google Cloud
The server runs as a containerized service on Google Cloud’s serverless stack (Cloud Run), which fits the traffic shape: MCP sessions are bursty, request-response over streamable HTTP, and idle most of the day early in a rollout. Scale-to-zero keeps the idle bill near zero; autoscaling absorbs the spikes when a directory listing goes live. Google-managed SSL certificates cover the HTTPS requirement without certificate babysitting.
Three operational notes that saved (or cost) us real time:
- Build in the customer’s cloud project from day one. Early development ran in a partner-owned GCP environment and had to migrate to the firm’s own project before production — DNS, credentials, and OAuth registrations all had to move with it. Avoidable.
- The DNS → HTTPS → OAuth chain is strict. You cannot register OAuth apps with Google and Microsoft for production until your domain is live under HTTPS; the certificate can’t be issued until DNS is confirmed; and provider app registration also requires proof of domain ownership and a published privacy policy. Sequence these in week one — they gate everything user-facing.
- Put cost controls on before traffic. Budget alerts and quota caps on the project, because an assistant loop can generate traffic no human would.
For phase two — retrieval over the firm’s unstructured analyst research — the platform choice is Vertex AI Search, using the firm’s structured metadata to drive document retrieval so assistants can discover and cite the right research.
Observability
Treat the MCP server as a product with analytics, not just a service with logs. We instrument per-tool call volume, latency, and error rates; auth funnel metrics (connect attempts vs completed authorizations — this catches broken OAuth before users complain); and per-user and per-organization usage, which doubles as the input to rate limiting and, eventually, to commercial reporting. Cloud Run’s integration with Cloud Logging and Cloud Monitoring means the baseline is configuration rather than code.
The checklist
- Pick the identity platform; model assistants as separate OAuth clients; confirm dynamic client registration.
- Register domains, set DNS to production, get HTTPS issued, publish the privacy policy — then register OAuth apps with Google and Microsoft.
- Design task-oriented tools around user questions; budget tokens per definition and per response.
- Decide the backend auth plane; schedule the API-side user-ID and rate-limiting change.
- Deploy on Cloud Run in the customer’s own GCP project, with cost controls and monitoring from day one.
- Then start directory submissions — they have their own clocks.
Work with Node8
Node8 designs and operates production MCP servers on Google Cloud — and as a Google Cloud reseller and implementation partner, we can stand up the platform underneath as well as the AI layer on top. If you’re building one, talk to us.