DEV Community: Kate Johnson

Serving many brands from one Nuxt 3 codebase

Kate Johnson — Mon, 13 Jul 2026 17:08:31 +0000

I work on a white-label storefront that ships under a couple dozen brands. Same flows, same components, different logos, colors, copy, API credentials, and feature sets. One codebase serves all of them, and the difference between brands is data, not code.

That last sentence is the whole architecture. Everything below is the mechanics of making it true in Nuxt 3, using two fictional brands, acme and globex, as stand-ins.

tenant config is data

Every brand gets one JSON file. Not a branch, not an env file full of one-off variables, not a folder of overridden components. A config file with a schema.

// config/tenants/acme.json
{
  "id": "acme",
  "name": "Acme Fiber",
  "domains": ["shop.acme.example", "acme.localhost"],
  "theme": {
    "colorPrimary": "220 90% 45%",
    "colorAccent": "32 95% 55%",
    "radius": "0.5rem",
    "logo": "/logos/acme.svg"
  },
  "flags": {
    "giftCards": true,
    "scheduledInstall": false,
    "liveChat": true
  },
  "api": {
    "baseUrl": "https://api.internal.example/acme"
  }
}

globex.json has the same shape and different values. A Zod schema validates every file at build time, so a typo in a brand config fails the build instead of failing one brand's checkout on a Tuesday.

The discipline this buys you is that adding a brand becomes a data entry task. Our record from "signed contract" to "staging site up" is under a day, and none of that day was spent writing components.

Notice what's not in the file. No secrets. The config gets shipped to the client for theming and flags, so credentials live elsewhere, which is the next section.

runtimeConfig holds the secrets

Nuxt's runtimeConfig splits into private keys, available only server-side, and a public block that reaches the browser. Per-tenant API credentials go in the private part.

// nuxt.config.ts
export default defineNuxtConfig({
  runtimeConfig: {
    tenantApiKeys: '', // JSON map, injected at deploy time
    public: {
      defaultTenant: 'acme',
    },
  },
});

The values here are placeholders. At runtime, Nuxt overrides them from environment variables using the NUXT_ naming convention, so NUXT_TENANT_API_KEYS populates tenantApiKeys without a rebuild. That property is load-bearing for multi-tenant work. We build one artifact, and the same image runs in every environment with different env vars.

There are two deployment shapes for multi-brand Nuxt, and it's worth being explicit about which you're in because it changes where secrets live.

One process per brand. Each brand gets its own deployment with its own env vars, and the tenant is fixed at boot. Simple, strong isolation, more infrastructure to run. This is what we do for brands with contractual isolation requirements.

One process, many brands. A single deployment serves every domain and resolves the tenant per request. Cheaper to operate, and credentials become a keyed map like tenantApiKeys above rather than flat env vars. Most of our traffic runs this way.

The config-as-data approach supports both, which is convenient when a brand needs to move from the shared pool to a dedicated deployment. That has happened twice, and both times it was an infra change, not a code change.

resolving the tenant in Nitro middleware

In the shared-process shape, some code has to decide which brand a request belongs to, and it has to happen before any handler runs. Nitro server middleware is built for this. Files in server/middleware/ run on every request, and their job is to decorate event.context, not to return responses.

// server/middleware/tenant.ts
import { tenants } from '~~/config/tenants';

export default defineEventHandler((event) => {
  const host = getRequestHost(event, { xForwardedHost: true });
  const tenant = tenants.find((t) => t.domains.includes(host));

  if (!tenant) {
    throw createError({ statusCode: 404, statusMessage: 'Unknown host' });
  }

  event.context.tenant = tenant;

  const { tenantApiKeys } = useRuntimeConfig(event);
  const keys = JSON.parse(tenantApiKeys) as Record<string, string>;
  event.context.tenantApiKey = keys[tenant.id];
});

A few notes on the details. getRequestHost and createError are h3 utilities, auto-imported in the server directory. The xForwardedHost option matters when you sit behind a load balancer, and it's only safe because our ingress strips and resets that header. If yours doesn't, trusting it means anyone can impersonate a brand with a curl flag. Verify before you copy that line.

Passing event to useRuntimeConfig(event) is the documented form in server handlers, and it keeps per-request config features working.

Downstream, every server route reads identity and credentials from context instead of computing them.

// server/api/offers.get.ts
export default defineEventHandler(async (event) => {
  const { tenant, tenantApiKey } = event.context;

  return $fetch(`${tenant.api.baseUrl}/offers`, {
    headers: { 'x-api-key': tenantApiKey },
  });
});

The route has no idea how tenancy gets resolved, and that's the point. When we later added a header-based override for internal preview environments, one middleware file changed.

For the client side, a small plugin exposes the sanitized tenant (theme, flags, copy, never credentials) through useState, so components call useTenant() and stay ignorant of the resolution mechanics.

theming with CSS custom properties

Brand theming fails in one of two directions. Either you compile a CSS bundle per brand, and builds get slow and cache-hostile, or you sprinkle :class bindings everywhere, and the design system erodes. CSS custom properties avoid both. One stylesheet, per-request values.

The tenant plugin injects the theme as variables on the root element during SSR.

// plugins/theme.server.ts
export default defineNuxtPlugin(() => {
  const tenant = useTenant();
  const t = tenant.value.theme;

  useHead({
    htmlAttrs: {
      style: [
        `--color-primary: ${t.colorPrimary}`,
        `--color-accent: ${t.colorAccent}`,
        `--radius: ${t.radius}`,
      ].join(';'),
    },
  });
});

Because this happens server-side, the first paint is already branded. No flash of default theme, no client-side style swap.

Tailwind then maps its tokens onto the variables instead of hardcoded values.

// tailwind.config.js
module.exports = {
  theme: {
    extend: {
      colors: {
        primary: 'hsl(var(--color-primary) / <alpha-value>)',
        accent: 'hsl(var(--color-accent) / <alpha-value>)',
      },
      borderRadius: {
        brand: 'var(--radius)',
      },
    },
  },
};

Components write bg-primary and rounded-brand and never learn which brand they're rendering. Designers still work in the token vocabulary they know. The <alpha-value> trick keeps Tailwind's opacity modifiers working, which is why the config stores raw HSL channels rather than a complete color string.

The limit of this approach is structural variation. Variables handle colors, spacing, radii, and fonts well. They do not handle "globex wants the checkout steps in a different order." For structure we use flags and, rarely, per-tenant component slots. If a brand needs a genuinely different page, that's a product conversation, not a theming problem.

feature flags without tenant names

The failure mode to guard against is this line spreading through the codebase.

if (tenant.id === 'acme') { ... }

One of these is harmless. Fifty of them mean brand behavior is defined by scavenger hunt, and every new brand starts by grepping for a competitor's name. The rule we enforce in review is that tenant ids appear in config files and tests, never in application logic.

Instead, behavior keys off named capabilities in the config's flags block, read through one composable.

// composables/useFlag.ts
export function useFlag(flag: keyof TenantFlags): boolean {
  const tenant = useTenant();
  return tenant.value.flags[flag] ?? false;
}

<GiftCardBanner v-if="useFlag('giftCards')" />

The difference from the if (acme) version looks cosmetic and isn't. A flag names the behavior, so the code reads as "this brand sells gift cards" rather than "this brand is acme, whatever that implies this week." Onboarding a brand means answering yes/no questions in a config file. And when a flag is finally true for everyone, you delete it and the branch it guarded, which is much harder when the condition is a list of brand names someone has to research.

Typing flags as a closed interface, not Record<string, boolean>, keeps the flag list honest. Adding a flag is a deliberate schema change with a default, and dead flags show up as unused keys.

per-tenant smoke tests

Everything above has an uncomfortable side effect. Code coverage no longer implies brand coverage. Your test suite can pass completely while globex.json points at a decommissioned API host, because configs are data and data doesn't compile.

Most of our production incidents in this app have been config-shaped, not code-shaped. A wrong domain in one brand's file. A flag enabled for a brand whose backend didn't support the feature yet. Unit tests catch none of that.

So the CI stage that has earned its keep is a smoke matrix. For every tenant config, boot the app resolved to that tenant, then hit a short list of golden-path checks. Home page renders with that brand's logo and primary color variable. The offers endpoint returns 200 through that brand's credentials. Checkout loads. Flag-gated pages return 200 where the flag is on and 404 where it's off. In Playwright this is one spec file and a loop over the config directory, with the tenant selected per project via its domain alias.

It's not deep testing, maybe thirty seconds per brand, and it converts "works on the brands we happened to check" into "works on all of them" on every PR. When a config edit breaks a single brand, the failing job names the brand before review does.

If you take one thing from this post, take the shape rather than the specifics. Push every brand difference into validated config, resolve identity once in server middleware, express look and behavior through tokens and flags that never mention a brand by name, and smoke test each config because it is now part of your program. Nuxt makes the mechanics pleasant, but the payoff comes from the discipline, and the discipline is what lets brand twenty-four cost a day instead of a sprint.

What broke when we ran Bun in production

Kate Johnson — Mon, 13 Jul 2026 17:03:02 +0000

We run an internal Nuxt service on GKE. It talks to the Kubernetes API from inside the cluster, manages some infrastructure, nothing exotic. Last year we moved it from a Node base image to oven/bun, and it mostly went fine. This is a field report on the part that didn't, because the failure mode was quiet and the debugging took longer than the migration.

why we switched

The honest answer is CI time. Our npm install step took a couple of minutes on a cold cache, and bun install did the same work in seconds. Multiply by every PR build and it adds up. Nitro already supported the Bun runtime, the app had no native addons, and the dependency tree looked clean. It felt like a low-risk win.

We changed the Dockerfile base to oven/bun:alpine, swapped the CMD to bun server/index.mjs, ran the test suite, clicked around staging. Everything passed. We shipped it.

what worked

Credit where due, most of the pitch held up.

Installs got dramatically faster. Cold installs in CI went from minutes to under ten seconds, and local installs stopped being a coffee break. This alone paid for the migration.

The image got smaller. The oven/bun:alpine image plus our app came out meaningfully leaner than the equivalent Node Alpine build, partly the base image, partly that Bun didn't need some of the toolchain layers we'd been carrying.

Memory usage dropped. Steady-state RSS on the pods came down noticeably, enough that we tightened the memory requests. I won't quote exact numbers because they're workload-specific, but the direction was consistent across restarts.

Startup was quicker too, which made rollouts and crash-loop recovery a little less tense.

So far, the brochure version. Now the other part.

what broke

A few days after the rollout, a feature that lists cluster resources started returning empty results. No crash, no 500s, no restarts. The logs showed TLS errors from the Kubernetes client, the kind you get when certificate verification fails against a self-signed chain.

Some background on how in-cluster auth works. A pod talks to the Kubernetes API using a service account token and a cluster CA certificate, both mounted at /var/run/secrets/kubernetes.io/serviceaccount/. The API server's certificate is signed by that cluster CA, not by anything in the public trust store. So every request has to present that CA as trusted, or verification fails.

We were on @kubernetes/client-node v1.x, which routes its requests through node-fetch. To trust the cluster CA, the library builds a custom https.Agent with the CA loaded into it and passes it to node-fetch via the agent option. Under Node, this works. It has worked for years.

Under Bun, the agent option never took effect. No warning, no error at the point of configuration. The requests went out without the cluster CA, TLS verification failed against the API server's cert, and the library surfaced that as request failures. From the app's perspective, the Kubernetes API was just unreachable.

The part that made this painful is the silence. If Bun had thrown "agent option not supported," we'd have fixed it in an hour. Instead the config appeared to apply and the failure showed up two layers away, dressed up as a certificate problem, in code we hadn't touched.

the debugging detour

My first theory was the CA file itself, so I exec'd into the pod and verified the mount. Fine. Second theory was NODE_EXTRA_CA_CERTS, the usual escape hatch for custom CAs. I pointed it at the mounted CA and restarted. It didn't rescue the client's requests, and at the time I couldn't find a clear statement of how completely Bun honored that variable across its socket paths. Maybe it works for some code paths now. That's exactly the problem, "maybe" is not a property you want in your trust chain.

The breakthrough was reproducing outside the cluster. I wrote a ten-line script that made an HTTPS request to a server with a private CA, passing the CA through a custom agent the way the client library does. Run with node, it connected. Run with bun run, verification failed. Same script, same machine, different runtime. That was the whole bug in miniature, and it took ten minutes once I stopped assuming the two runtimes behaved the same.

the fix

We stopped fighting the abstraction. For the handful of in-cluster API calls this service makes, we dropped the client library's request layer and used node:https directly, passing the CA in the request options.

import { readFileSync } from 'node:fs';
import { request } from 'node:https';

const SA_DIR = '/var/run/secrets/kubernetes.io/serviceaccount';
const ca = readFileSync(`${SA_DIR}/ca.crt`);
const token = readFileSync(`${SA_DIR}/token`, 'utf8');

function k8sGet(path: string): Promise<unknown> {
  return new Promise((resolve, reject) => {
    const req = request(
      {
        host: process.env.KUBERNETES_SERVICE_HOST,
        port: 443,
        path,
        ca,
        headers: { Authorization: `Bearer ${token}` },
      },
      (res) => {
        let body = '';
        res.on('data', (chunk) => (body += chunk));
        res.on('end', () => resolve(JSON.parse(body)));
      },
    );
    req.on('error', reject);
    req.end();
  });
}

Bun's node:https implementation honors the ca option in request options, and that's been stable for us since. We kept the client library's types and config parsing and replaced only the transport. It's more code than I wanted to own, and it's also code whose behavior I can verify in one place instead of trusting a compatibility matrix.

Could we have pinned an older client version that used a different HTTP stack, or patched node-fetch? Probably. I preferred the option with no hidden layers, given that this exact class of hidden layer caused the outage.

reproduce with bun run, not node

The process lesson matters more than the fix. Locally, everyone was running the service with familiar Node tooling. Tests ran under Node. The dev server ran under Node. Only the container ran Bun, so the one environment that exhibited the bug was the one nobody used day to day.

Now the rule is simple. If prod runs Bun, dev and CI run bun run, including one-off repro scripts. A repro under node proves nothing about a Bun deployment. This sounds obvious written down. It did not feel obvious during the week we spent staring at certificate errors that no one could reproduce locally.

The same reasoning applies to any environment-shaped config. Don't trust NODE_EXTRA_CA_CERTS, custom agents, proxy env vars, or TLS knobs under Bun until you have watched them work under Bun, in a test that fails when they don't.

when I'd stay on Node

Bun is still in that image and I'd make the same call again for this service. I would not make it for every service. Stay on Node, at least for now, if any of these describe you.

Your dependencies configure HTTP behavior through custom agents, proxies, or private CAs. This is the exact seam that bit us.
You rely on native addons or anything that compiles against Node internals.
You depend on mature APM, profiling, or heap-analysis tooling. The Node ecosystem there is years ahead.
You have compliance requirements around TLS behavior (corporate CAs, FIPS-adjacent policies) where "silently different" is unacceptable.
Your team can't or won't run Bun everywhere. A prod-only runtime is a standing invitation for this whole story to repeat.
The service is critical and the win is only install speed. You can get fast installs in CI with caching and keep Node in the runtime image.

None of these are permanent objections. Bun's Node compatibility improves steadily, and half the items on this list may age badly. They're just the questions I'd answer before switching, rather than after.

The takeaway I keep coming back to is that "drop-in replacement" describes the happy path, not the guarantee. Bun ran our app, passed our tests, and served traffic while ignoring a security-relevant option without a word. The wins were real and we kept them. But the migration wasn't done when the tests went green. It was done when we'd verified, under Bun, every place our code touches the runtime's edges.

Building a production MCP server with NestJS

Kate Johnson — Mon, 13 Jul 2026 17:02:58 +0000

We had a NestJS API that already knew how to do everything an agent might want. Auth, tenancy, business logic, the works. What we didn't have was a way for an LLM to call any of it. MCP (Model Context Protocol) is the standard for that, and the TypeScript SDK handles the wire protocol. The part nobody writes down is how to fit it into NestJS without abandoning dependency injection and ending up with a 900-line file of closures.

This post walks through the setup I landed on. The examples use a fictional orders domain, but the structure is what I run in production.

A note on versions first. Everything below uses the v1 SDK, @modelcontextprotocol/sdk, which is the supported production line. A v2 (@modelcontextprotocol/server) is in beta as I write this, with a different package layout. If you're starting today, v1 is still the safe choice, and the concepts transfer.

why bother with NestJS at all

You can stand up an MCP server in 40 lines of Express. The SDK README shows you how. That's fine for a demo, but production tool handlers need the same things your REST handlers need. Database access, per-tenant scoping, logging, existing service classes. If your app is NestJS, the cheapest way to get all of that is to keep the tools inside the same DI container.

The goal is that a tool handler looks like any other Nest provider. It injects OrdersService, it gets tested with the Nest testing module, and the MCP plumbing stays in one thin layer.

module layout

The layout I use has three pieces. Tool classes, a server factory, and a controller that owns the transport.

Each tool class is a normal injectable that knows how to register itself on an McpServer instance. I pass a per-request context in, which matters later for tenancy.

// src/mcp/tools/orders.tools.ts
import { Injectable } from '@nestjs/common';
import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
import { z } from 'zod';
import { OrdersService } from '../../orders/orders.service';

export interface ToolContext {
  tenantId: string;
  environment: 'sandbox' | 'production';
}

@Injectable()
export class OrdersTools {
  constructor(private readonly orders: OrdersService) {}

  register(server: McpServer, ctx: ToolContext): void {
    server.registerTool(
      'list_orders',
      {
        title: 'List orders',
        description:
          'List recent orders for the current store, newest first. ' +
          'Use status to narrow the result. Returns order id, status, ' +
          'total in cents, and created date.',
        inputSchema: {
          status: z
            .enum(['pending', 'shipped', 'refunded'])
            .optional()
            .describe('Only return orders in this state'),
          limit: z
            .number()
            .int()
            .min(1)
            .max(50)
            .default(10)
            .describe('Maximum number of orders to return'),
        },
      },
      async ({ status, limit }) => {
        const orders = await this.orders.list({
          tenantId: ctx.tenantId,
          environment: ctx.environment,
          status,
          limit,
        });
        const output = { orders };
        return {
          content: [{ type: 'text', text: JSON.stringify(output) }],
          structuredContent: output,
        };
      },
    );
  }
}

Two SDK details trip people up. inputSchema is a raw Zod shape, an object of key to schema, not z.object(...). And the handler returns a content array, optionally with structuredContent when you also declare an outputSchema.

Why register(server, ctx) instead of a fancier abstraction where tools declare metadata and a registry loops over them? I tried the registry version. The generics needed to keep handler args typed from the Zod shape got ugly fast, and the SDK already infers those types perfectly when you call registerTool directly. Letting each class call the SDK keeps the types and costs one interface.

The factory collects the tool classes through a multi-provider token and builds a fresh server per request.

// src/mcp/mcp.module.ts
import { Module } from '@nestjs/common';

export const MCP_TOOLS = Symbol('MCP_TOOLS');

@Module({
  imports: [OrdersModule],
  controllers: [McpController],
  providers: [
    OrdersTools,
    RefundsTools,
    {
      provide: MCP_TOOLS,
      useFactory: (orders: OrdersTools, refunds: RefundsTools) => [orders, refunds],
      inject: [OrdersTools, RefundsTools],
    },
    McpServerFactory,
  ],
})
export class McpModule {}

// src/mcp/mcp-server.factory.ts
import { Inject, Injectable } from '@nestjs/common';
import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';

@Injectable()
export class McpServerFactory {
  constructor(@Inject(MCP_TOOLS) private readonly tools: OrdersTools[]) {}

  create(ctx: ToolContext): McpServer {
    const server = new McpServer({ name: 'orders-mcp', version: '1.0.0' });
    for (const tool of this.tools) {
      tool.register(server, ctx);
    }
    return server;
  }
}

wiring the transport

For a server that sits behind an agent product, I run the Streamable HTTP transport in stateless mode. No session tracking, one server instance per request, nothing to clean up between requests except the request itself. Sessions buy you resumability and server-initiated notifications, and until you need those, statelessness keeps horizontal scaling boring.

// src/mcp/mcp.controller.ts
import { Controller, Post, Req, Res, UseGuards } from '@nestjs/common';
import { Request, Response } from 'express';
import { StreamableHTTPServerTransport } from '@modelcontextprotocol/sdk/server/streamableHttp.js';

@Controller('mcp')
@UseGuards(ApiKeyGuard)
export class McpController {
  constructor(private readonly factory: McpServerFactory) {}

  @Post()
  async handle(@Req() req: Request, @Res() res: Response): Promise<void> {
    const ctx: ToolContext = req.tenantContext; // set by ApiKeyGuard
    const server = this.factory.create(ctx);
    const transport = new StreamableHTTPServerTransport({
      sessionIdGenerator: undefined, // stateless
    });

    res.on('close', () => {
      transport.close();
      server.close();
    });

    await server.connect(transport);
    await transport.handleRequest(req, res, req.body);
  }
}

Injecting @Res() puts Nest into library-specific mode for this route, so response interceptors won't run here. That's intentional. The transport owns the response, including SSE streaming, and anything that touches the response after it will corrupt the stream. Keep this controller dumb.

Nest's default body parser has already parsed JSON by the time the handler runs, which is why req.body gets passed through as the third argument.

schemas an LLM can actually use

This is where most MCP servers quietly fail. The model only sees the tool name, the description, and the schema. It cannot read your code. Things that made a real difference for us, in rough order of impact.

Describe behavior, not types. limit: number tells the model nothing it can't see from the schema. "Maximum number of orders to return, newest first" changes how it calls the tool.

Constrain everything you can. z.enum(['pending', 'shipped', 'refunded']) means the model can't invent a cancelled status that your database has never heard of. Ranges on numbers, .default() where a sane default exists.

Prefer several small tools over one flexible tool. We started with a query_orders tool that took a filter object. The model produced creative filters, most of them invalid. Splitting it into list_orders, get_order, and search_orders_by_customer cut tool-call errors to almost nothing. Boring tools get called correctly.

Return errors as results, not exceptions. A thrown exception becomes a generic protocol error and the model learns nothing. Set isError: true and say what went wrong in plain language, ideally with what to do instead.

return {
  content: [{
    type: 'text',
    text: `Order ${orderId} not found for this store. Use list_orders to see valid ids.`,
  }],
  isError: true,
};

That last sentence is a nudge the model will actually follow.

scoping per tenant and environment

The tempting design is a tenantId parameter on every tool. Don't. The model chooses parameter values, and a model should never choose which tenant's data it reads. Same argument as never trusting a client-supplied tenant id in a REST API, except the client here is a language model that will cheerfully hallucinate one.

Tenant identity has to come from the credential. In the controller above, ApiKeyGuard resolves the API key to a tenant and an environment before the MCP layer sees the request, and the factory bakes that context into every handler via the closure over ctx. A tool physically cannot query another tenant because the tenant id never appears in its schema.

Environment scoping works the same way and matters just as much. Our sandbox and production keys map to different environment values, and the services route to different backends from there. An agent wired up with a sandbox key can call refund_order all day without touching real money.

One consequence of per-request server construction is that you can also vary the tool list by context. Sandbox keys get a seed_test_orders tool, production keys don't. Registration happens in register(), so a plain if on ctx.environment is all it takes.

testing handlers

Two layers have earned their keep.

Unit tests hit the tool class directly through the Nest testing module, with the domain service mocked. Nothing MCP-specific about these, which is the point of keeping handlers as providers.

Integration tests run the real protocol without HTTP. The SDK ships an in-memory transport pair for exactly this.

import { Client } from '@modelcontextprotocol/sdk/client/index.js';
import { InMemoryTransport } from '@modelcontextprotocol/sdk/inMemory.js';

it('lists orders scoped to the tenant', async () => {
  const [clientTransport, serverTransport] = InMemoryTransport.createLinkedPair();

  const server = factory.create({ tenantId: 'tenant-a', environment: 'sandbox' });
  await server.connect(serverTransport);

  const client = new Client({ name: 'test-client', version: '1.0.0' });
  await client.connect(clientTransport);

  const result = await client.callTool({
    name: 'list_orders',
    arguments: { limit: 5 },
  });

  expect(result.isError).toBeFalsy();
  expect(ordersService.list).toHaveBeenCalledWith(
    expect.objectContaining({ tenantId: 'tenant-a' }),
  );
});

This catches a class of bug unit tests miss, like schema definitions that reject arguments your handler expects, or handlers returning shapes that fail outputSchema validation. It's also the right place to assert the tenant-scoping property, since it exercises the same factory path production uses.

What these tests don't tell you is whether a model can use your tools well. For that we keep a small eval script that points a real agent at the server with a handful of scripted tasks and checks the outcomes. It's crude and occasionally flaky, and it has still caught two bad tool descriptions before users did.

The whole thing came out to around 300 lines on top of an existing NestJS app, and most of that is tool definitions we'd want regardless. Keep the transport in one controller, resolve tenancy from credentials before the SDK ever runs, and treat descriptions as the API surface they are. The protocol part turns out to be the easy bit.