Model Context Protocol (MCP)Copy link to this section
The Model Context Protocol is an open standard for connecting AI assistants to the systems where work actually lives. Instead of every assistant needing a purpose-built plugin for every product, and every product shipping a different plugin for every assistant, a product exposes one MCP server and any compliant assistant can use it.
An MCP server offers three things. Tools are functions the assistant can call — read a number, write a record. Resources are documents the assistant can read, addressed by URI. Prompts are workflows the product author has written out, which the assistant surfaces to the user as a starting point for a job that takes more than one step.
The word points in two directions, which is a frequent source of confusion. A product can be an MCP server (an assistant connects to it) or an MCP client (it connects out to somebody else's server). The same product can be both, for different purposes, and the security questions are completely different in each direction.
Why it matters for SaaSCopy link to this section
The integration surface most SaaS companies have spent a decade building — REST APIs, webhooks, SDKs — assumes a developer is going to sit down and write code against it. MCP assumes the caller is a language model that has never seen your product before and will be given a list of tools and expected to pick the right one.
That changes what a good interface looks like. Tool descriptions matter more than reference docs, because the description is what the model reads before deciding. Result size matters, because a model's context is finite and a truncated tool result does not announce that it was truncated. And returning too much is as harmful as returning too little: a response that buries the answer in forty null fields makes the model work harder and answer worse.
It also changes who your integration users are. A customer who would never have written against your API will happily ask their assistant "how many demos did we run last month" — if the connection exists.
The authorization problemCopy link to this section
An MCP connection acts as a person, which makes it unlike an API key. The standard settles this with OAuth 2.1 and PKCE: a human approves the connection in a browser, while signed in, choosing what it may do.
The rules that make that safe are the ones worth checking in any implementation. Does the connection's access ever exceed the person's own permissions? Does revoking it take effect immediately, or only when a token expires? Does a demotion take effect at all? Is there one connection per account, or does approving once reach everything the person can reach?
MCP at FloeCopy link to this section
Floe is both. Floe is an MCP server at api.floe.so/mcp: a customer
connects Claude, ChatGPT or Cursor and works with Floe as a product — counting
demos, reading what prospects asked, editing the scripts the demo agent
follows. Floe is also an MCP client in Support mode, where the support
agent calls a customer's own MCP server to answer a signed-in user's questions
about their account.
Connections in the server direction are scoped to one organization, capped by the member's own role, and revocable from the dashboard.