Connecting those two took longer than I expected, and almost none of the difficulty was about MCP. It was about tenancy. I’m writing this down because I couldn’t find much on it when I needed it.
There’s a runnable version of the pattern here: dotnet-mcp-tenancy. Stripped-down .NET API plus MCP server, demonstrating everything below — including the bugs.
This was the first thing people suggested, and it’s the wrong instinct.
In a database-per-tenant system, a global database holds the tenant registry and handles provisioning, each customer gets their own store, and migrations fan out across all of them. Identity often lives in a separate auth service, so the tenant databases don’t even have a user table — only user references.
Point an agent at that directly and you’ve handed a language model the job of picking the right connection string. Every tool call becomes a place where one customer’s data can surface for another. I didn’t want tenant resolution to be something the model could get wrong, so it had to happen in code, on the backend, before any query ran.
The shape I settled on: the Node service owns the agent and the MCP server. The .NET backend exposes a small set of internal endpoints under /internal/, behind a service-key header. Each MCP tool is a thin wrapper that calls one of those with an explicit org and user. The model picks a tool. The tenant comes from the authenticated session that invoked it.
I assumed at first we’d reuse the existing controllers. That was wrong, and it took a while to see why.
A public endpoint answers a request from a browser session that’s already authenticated and scoped. An internal service-to-service endpoint answers another service, acting on behalf of a user, in a tenant the caller has to name. Different trust models. Serving both from one pipeline means either weakening the public one or contorting the internal one.
So the internal surface got its own controller that does nothing else. Every action takes org and user explicitly. Nothing is inferred from a cookie, because there isn’t one.
The part that surprised me: these endpoints need more validation than the public ones, not less. When a human links a ticket to a task, they’re doing it through a UI that only offers valid options. When an agent does it, it’s working from whatever it inferred from a conversation. So the link operation checks the ticket exists, checks it’s active, checks whether the task is already linked, and refuses to overwrite rather than silently replacing — returning a message the agent can relay straight back.
That refusal behaviour matters more than it sounds. An agent that quietly overwrites a link is much worse than one that says “that task is already linked to #114, unlink it first.” The first one loses data and nobody notices for a week.
Here’s the one that cost me an afternoon.
I moved an AI diagnosis feature from an inline call to a queued job. When I built the job table I keyed jobs on ticket ID, which is the obvious thing to do and is completely wrong in a database-per-tenant system. Ticket numbering restarts in every tenant store. Tenant A’s ticket 47 and tenant B’s ticket 47 are different tickets, and a job keyed on 47 will cheerfully attach one customer’s diagnosis to another customer’s ticket.
Jobs are keyed on (TenantId, TicketId) now. If you’re building anything asynchronous over per-tenant databases, go and check your job keys, your cache keys and your idempotency keys. Any identifier unique only within a tenant will betray you the moment it leaves one.
While I’m here — the reason for queuing at all is that Azure App Service terminates a request at 230 seconds and a diagnosis run takes minutes. The inline version also bypassed the concurrency cap entirely, so runs were effectively unbounded. We just hadn’t noticed, because nobody had triggered enough at once.
I chose polling over a callback from the worker service. A callback needs retry logic and has to carry the tenant with it to find the ticket again. Polling needs neither, survives a restart because all the state is in one row, and requires no hosted service or background worker. It’s the less elegant design and it was the right one.
We tracked AI token usage so organisations could see their spend and split it across projects. That turned out to be the buggiest surface in the system, and every bug was the same bug wearing a different hat.
The usage view showed nothing recorded while the product was visibly being used. Three separate causes. The streaming handler dropped token counts when the stream completed, without ever recording them. Tool operations — embeddings, search, evaluation — recorded a flat source with a null user, so nothing could be attributed to a caller. And where a workspace hadn’t been explicitly linked to a project, unassigned usage records from other organisations leaked into the summary.
That third one is the one I still think about. It wasn’t a feature that broke. It was a query that was correct under a single-tenant assumption nobody had written down.
The fix was small — an optional user ID on the usage record, mapped through the usage controller — but it’s what made everything else possible: telling apart tokens a human spent in chat from tokens someone’s IDE spent through MCP, and scoping project usage strictly to authorised members of that org rather than to whatever happened to be unassigned.
If you’re adding agent surfaces to a multi-tenant product, build attribution before you build features. Retrofitting means auditing every call site, and you will miss one. Usually the background job — which then shows up as a gap between the provider’s invoice and your own numbers.
Last one, and it’s my favourite because it’s so ordinary.
Customers create OAuth clients to connect Claude, ChatGPT or Copilot to their workspace. Those connector records lived in the AI service’s own table — which had no tenant column, because when it was written there was only one tenant that mattered.
The symptom: a brand-new, empty workspace would open the connectors page and see every connector in the product.
We moved the data into the per-tenant stores, where isolation already existed and was enforced. Only the data moved. The endpoint stayed exactly where it was, so every already-connected client kept working through the migration and nobody had to re-authenticate.
There’s a lesson in that beyond the bug. When you bolt an AI layer onto an existing product, that layer tends to get built as though it’s a greenfield single-tenant app — because that’s how all the examples are written. Every table it introduces is a place where your tenancy model doesn’t apply yet.
Keep tenant resolution out of the model’s reach. Give internal endpoints their own controller and their own trust model. Validate harder for agents than for humans, and make tools refuse rather than overwrite. Treat every identifier that’s unique within a tenant as a landmine outside one. And instrument attribution on day one, because tenancy bugs surface in your telemetry first — assuming your telemetry is capable of showing them at all.
None of this is MCP-specific, which is sort of the point. The protocol was the easy part.
Haris Nadeem is a Principal Software Engineer working on multi-tenant SaaS platforms in .NET and React. Code for this post: github.com/harisnadeem93/dotnet-mcp-tenancy
]]>