MCP Server for SaaS Products: Let Customers' AI Assistants Connect

What does an MCP server actually expose?

The protocol defines three things a server can offer, according to the MCP architecture overview. For a SaaS product they map like this, using an invented invoicing product as the example.

Primitive	What it is	Example in the invented product
Tools	Functions an assistant can call to act or query	List overdue invoices; create a draft reminder
Resources	Read-only data that gives context	The customer's invoice template or account settings
Prompts	Reusable templates for common requests	A "chase overdue payments" starting prompt

The host application, such as an AI assistant, creates one client per server. As of November 2026 the current specification revision on modelcontextprotocol.io is dated 2026-07-28, and the specification itself is the place to check for newer ones. Our post on MCP for business gives the plain-language background.

Illustrative scenario: a customer's assistant chases overdue invoices

An invented example, not a client result. A customer of the made-up invoicing product asks their assistant: "Which invoices are overdue, and can you draft reminders?" Read the trace as a conversation between the assistant and your server.

• Assistant: connects to the server's address and sends a request with no token.
• Server: answers 401 and points to its protected-resource metadata, which names the authorization server.
• Assistant: sends the customer through your normal sign-in and consent screen. The token that comes back is issued for your server and carries only the scopes granted, such as read invoices.
• Assistant: asks which tools exist. Server: lists them, and the list can depend on the scopes in the token, which the specification allows.
• Assistant: calls the overdue-invoices tool with a date range. Server: validates the input, checks the token's audience and scope, queries only that customer's data, and returns structured results with customer-visible fields only.
• Assistant: proposes drafting reminders. The create-reminder tool is a write action, so the assistant application asks the customer to confirm. The specification says there should always be a human able to deny a tool call.
• Server: creates drafts, not sent emails, and returns their ids. If a value is invalid, it replies with an error result the assistant can read and correct.
• Audit: each call is logged with customer, tool, arguments, outcome and time.

The customer then opens the drafts inside your product and sends them. The whole exchange moved information and prepared work; the irreversible step stayed in your interface.

What does the server do alone, what needs approval, and what is never exposed?

Category	Server alone	Customer confirms	Never exposed
Reading the caller's own records	Yes, within scopes
Creating drafts or low-risk records		Yes
Sending, publishing or emailing to third parties		Prefer a draft that a person sends
Deleting data, changing billing or permissions			Yes, in the first version
Reading another customer's records			Yes
Raw database queries or admin endpoints			Yes
Returning secrets, tokens or internal notes			Yes

Local or remote: stdio or Streamable HTTP?

The specification defines two standard transports. With stdio the assistant launches your server as a local process; with Streamable HTTP your server runs on your infrastructure and many customers connect to it. A product that sells to many customers almost always wants the remote form, because customers should not install and update your code. The architecture overview notes that local stdio servers typically serve a single client, while remote servers typically serve many.

Authorization is optional in the specification, but for HTTP it describes an approach based on OAuth, where the MCP server acts as a resource server. For stdio it advises retrieving credentials from the environment instead. For a multi-customer product, treat authorization as required in practice.

What must the server enforce itself?

The specification's security notes say servers must validate all tool inputs, implement proper access controls, rate limit invocations and sanitize outputs. It also says tool annotations should be treated as untrusted unless they come from a trusted server, so a client's behavior cannot be your safety plan. In practice:

• Check the token's audience. The authorization section says servers must only accept tokens issued for them, and must not accept or pass on other tokens. Never forward a customer's token to your own internal APIs.
• Authorize in the tool, every call. Check that this customer may see this record, with server-side data, not what the assistant claims.
• Treat arguments as hostile. Schema validation first, then business rules.
• Treat returned content as an injection route. If a tool returns customer-written text such as invoice notes, an assistant may read instructions inside it. Return the minimum fields, and say in the tool description that content is data. See AI agent security and prompt injection.

Whether to expose more later depends on logs from the first release. The general service is described on our MCP server development page.

How would success be measured?

We would define these with your product team before launch, and we would not put a number on any of them in advance:

• Connected accounts and active connections per week.
• Tool call volume by tool, to see which actions customers actually use.
• Tool error rate by tool, split into invalid input, denied access and server faults.
• Confirmation outcomes for write actions: confirmed, declined, abandoned.
• Support tickets mentioning the connection, and whether they fall as documentation improves.
• Latency per tool, because assistants wait on the slowest call.
• Access denials that look like probing, reviewed regularly.

To explore a server for your own product, talk to us. If your product itself is an AI application, see AI SaaS development.