"Your SaaS is already an MCP server"

The Model Context Protocol problem we hear most often: "great spec, but how do I plug it into my SaaS without rewriting the auth?"

The answer for Postiba forks: you don't. The OAuth/OIDC server that already powers your dashboard is the same server that authenticates MCP calls. The same per-user role, the same multi-tenant isolation, the same audit pipeline. Three weeks of integration work compressed into a dotnet sln line.

What ships in the box

The Postiba.Module.Mcp module exposes a Streamable-HTTP /mcp endpoint on the API host. Four tools out of the box, gated by subscription tier:

• whoami: identity of the authenticated caller. Free tier.
• get_workspace: workspace metadata: name, plan, member count. Pro.
• list_members: workspace roster with roles and join dates. Pro.
• query_audit_events: read the audit log for the current tenant. Pro.
• admin_query_audit_events_all_tenants: cross-tenant audit, SystemAdmin only. Enterprise.

Each tool declares its required feature key with a [RequiresFeature(...)] attribute. The dispatcher filters tools/list before the client ever sees them. A Free-tier user calling tools/list sees one tool. A Pro-tier user sees four. An Enterprise SystemAdmin sees five.

Discovery, not configuration

The integration step on the client side is exactly one URL.

1. Paste https://api.acme.com/mcp into Claude.app.
2. Claude reads /.well-known/oauth-protected-resource (RFC 9728) to discover which authorization server protects the resource.
3. Claude reads the OIDC discovery doc on that server, finds the registration_endpoint (RFC 7591), and POSTs its name and redirect URI.
4. Claude runs the standard OIDC authorization-code + PKCE flow against your existing Postiba.Oauth login page.
5. The bearer token flows back to Claude, Claude calls /mcp, your feature gate filters the tool list, Claude shows the tools to the user.

No copy-paste of client IDs, no out-of-band coordination, no custom registration flow. Production OAuth doing what production OAuth was always supposed to do.

Why a module, not core

Postiba.Module.Mcp is three csproj under src/modules/Mcp/. A fork that does not want MCP removes:

• the two <ProjectReference> lines in Postiba.Api.csproj and the module-assembly entry in Program.cs,
• the migration for the mcp.tool_invocations table.

Six lines of diff. The dynamic client registration endpoint stays in core because it is a generic OAuth feature, but the /mcp transport and the tools disappear cleanly.

This is the same modular-monolith pattern we use for Stripe billing (see the earlier post on module-or-core). A vertical that not every fork wants belongs in a module.

What's deliberately NOT in the box

• No write tools. The four shipped tools are read-only. Write tools require an idempotency story (we have the table, we have the dedup pattern, we have not yet decided which mutations are worth exposing as the canonical example).
• No server-driven prompts. MCP is the programmatic surface; the WASM dashboard is the human surface. We do not duplicate the dashboard's affordances as MCP prompts.
• No tool-result streaming. The SDK supports it, the four default tools do not need it. The streaming pattern lights up as soon as a tool with non-trivial latency joins the catalog.

A fork that needs any of these adds them in the module's own namespace without changing the core surface.

The 5-minute test

Clone the template. Copy .env.example. docker compose up. Open npx @modelcontextprotocol/inspector, point it at http://localhost:5181/mcp, log in with the seed admin account. The inspector shows the tool list. Call whoami. You see your identity.

That's the end of the demo. From here it is your tools, your workspace data, your feature gates. The plumbing is done.