An MCP server SaaS template should expose the product's real operations, not a second demo API that drifts from the admin panel. The server included here lives inside the application. It uses the same organization identity, API keys, feature gates, data services, and business workflows as the rest of the product.
The endpoint speaks JSON-RPC 2.0 over HTTP POST and identifies the MCP protocol version it implements. It handles initialization, tool discovery, tool calls, and ping. A GET request provides a small health and version response, while DELETE ends a session as a stateless no-op.
The POST handler accepts a single JSON-RPC message or a batch. Notifications without an ID return no response body, while a batch gathers only calls that need responses. That is protocol behavior in the shipped route, not a wrapper left to the buyer.
The important part is behind that transport: the current source contains 86 static tool declarations. They cover users, organizations, plans, feature flags, announcements, translations, content, email, theme, webhooks, alerts, automations, scheduled tasks, report templates, analytics, settings, audit logs, notifications, products, and integrations.
That count is the base, not the ceiling. Connect workflows are loaded into MCP dynamically. Product-specific tools can register from a dedicated extension file. An optional admin-assistant bridge can register more tools when its feature is present.
Tool access follows the API key
The MCP endpoint requires a bearer API key for calls. The validator resolves the organization and scope from that key. Read-only keys receive only read tools. Write and admin keys can see the full registry, subject to each tool's own feature requirement.
That filtering happens twice. tools/list filters by key scope and enabled organization features before returning the catalog. tools/call checks scope and the feature flag again before execution. A disabled feature therefore stays hidden during discovery and fails closed if a caller tries to invoke the tool by name anyway.
The whole server has its own mcp_server feature gate. When it is disabled for the organization, the endpoint returns 404. The default seed ships that flag off, so an owner has to choose to expose the surface.
This matters commercially and operationally. “Agent-ready” does not mean “publicly writable.” It means the product has a protocol endpoint that can be enabled, authenticated, scoped, and inspected.
The tools operate product services
The registry does not duplicate every route as a thin HTTP wrapper. Tool collections call the same database and service layer the product uses. User tools can list, invite, suspend, reactivate, and change roles. Organization tools can inspect usage and lifecycle. Plan and feature tools operate the billing model. Translation, email, theme, and integration tools expose owner controls.
Connect workflows add a stronger reuse path. The four base workflows—subscribe an organization, cancel a subscription, invite a user, and promote a role—are registered once. The REST Connect endpoint and the MCP bridge load the same definitions. Input schemas, required scope, execution steps, and dispatched events stay attached to the operation.
The tool manifest is branded from the product configuration rather than a generic hardcoded project name. That prevents every product from announcing the same placeholder identity to an agent.
What connects from the outside
Browser-based clients can reach the endpoint through CORS. By default, the response allows any browser origin for backward compatibility. An owner can configure an origin allowlist. Non-browser clients ignore CORS, so the bearer API key remains the actual authorization boundary in either case.
Calls share the API-key usage log and per-key limiter. The tool context carries the organization, scope, and key ID into execution. The result comes back as MCP text content containing the tool's JSON output.
The design is intentionally stateless. There is no separate MCP user database and no long-lived server session to reconcile with the product. The API key is the identity on every call.
The honest limit
The server is disabled by default. A buyer has to enable the organization feature and issue an API key. Tools that depend on another feature or external provider remain unavailable until that dependency is configured. The 86 static declarations are therefore not a promise that every key sees 86 runnable actions.
The current protocol surface is tools-only. The handler advertises the tools capability and recognizes initialize, tools/list, tools/call, and ping. It does not implement MCP resources or prompts. A buyer who needs those protocol surfaces has to add them.
The per-key limiter also needs Redis. Without it, the MCP-specific limiter is a no-op, though the application's broader API edge limiter still applies in production. Consistent distributed quotas require the shared Redis configuration.
Finally, an MCP tool cannot do more than the underlying product can do. Configuring an email provider, creating a regional payment account, or adding a product-specific business action still requires the corresponding integration or service. The protocol makes capabilities available to agents; it does not manufacture capabilities that are absent from the application.
Why MCP is part of the base
Agent access is easiest to trust when it reuses existing permissions. Adding a separate automation server later often produces a privileged shortcut around the product's tenant model and admin controls.
Here, the agent surface starts behind the same organization key and feature system. Read keys stay read-only. Disabled capabilities stay hidden. Product workflows can serve REST and MCP from one definition. Audit and key-usage records remain connected to the caller.
That is the practical meaning of an agent-ready product: not a chatbot badge, but an owned protocol surface with real tools and visible limits.