For a decade the SaaS integration playbook was boring on purpose: ship a REST API, write docs, maybe an SDK. Customers logged into your UI. Integrations synced on a schedule. That model still matters — and it is no longer enough. In 2026, a growing slice of real work is driven by AI agents that discover tools at runtime and act inside products without a human clicking every screen. The Model Context Protocol (MCP) is the open standard many of those agents speak. Major model vendors and developer tools have first-party support. Surveys show meaningful production adoption of MCP servers across software organizations. If your product is invisible to agents your customers already run, that is a distribution problem as much as a technical one.
What MCP actually is (without the hype)
MCP is a protocol for connecting models to external tools and context — often described as a USB-C layer for AI applications. Agents can list what your product can do and call those capabilities with a uniform shape, instead of writing one-off glue for every SaaS API. The July 2026 MCP specification push made the core more like ordinary HTTP: more stateless, easier to run behind load balancers, with extensions for longer-running tasks and interactive surfaces. The practical founder takeaway is not “rewrite everything.” It is: agents want a discoverable, permissioned tool surface — and they will prefer products that provide one.
REST is not dead — dual surfaces win
Do not kill your REST API to chase agents. Scheduled syncs, partner integrations, mobile apps, and enterprise procurement still expect documented HTTP. The winning pattern is dual: keep REST as the system of record for humans and classical integrations; add a tenant-scoped MCP surface for agent-driven workflows. Think of MCP as another client of your domain layer — not a second source of truth. The same authorization, auditing, and tenancy rules that protect REST must bind every tool call. If an agent can act with weaker controls than your UI, you have built an attack path, not a feature.
A founder checklist before you expose MCP
1. Tenant context is server-bound. Never trust a model-supplied tenant ID. Inject tenancy from the authenticated session into every tool. 2. OAuth and audience controls. Tokens should be scoped to the MCP surface, rotatable, and short-lived. Align with how you already do OAuth for APIs. 3. Human approval for destructive tools. Create-invoice and delete-project are not the same risk class as “list open tickets.” 4. Audit every tool call. Who/what/when/which tenant — same bar as admin actions in your UI. 5. Rate limits and spend caps. Agents loop. Cap them like you would an abusive API client. 6. Keep REST first-class. Docs, SDKs, and partner integrations do not disappear because agents arrived. 7. Start with a thin tool catalog. Expose five high-value, well-guarded tools before you mirror your entire API.
When to wait
If you have no authenticated multi-tenant API, weak audit logs, or you cannot explain who can call what, fix that before MCP. Protocol cosplay on a shaky authorization model is how demos become incidents. If your customers are not running agents yet, you can still design the domain layer so an MCP adapter is cheap later — tenancy middleware, clear command boundaries, and idempotent writes.
Questions that expose slideware
“Show me the auth flow for a tool call as Tenant A trying to touch Tenant B.” “Which tools require human approval?” “Where is the audit row for the last agent write?” “What happens when the agent retries a payment tool?” Teams that built this for production answer without improvising.
What “good” looks like in the first 90 days
Week one to four: pick one customer persona that already uses agents (engineering tools, ops copilots, or internal assistants). Map three to five actions they repeatedly ask a human to do in your product. Implement those as tools with the same authorization checks as your UI. Instrument latency, error rates, and approval rates. Week five to eight: add audit export for security reviews, tighten OAuth scopes, and run a red-team pass where Tenant A’s agent tries Tenant B resources. Publish a short partner doc: tool catalog, auth, rate limits, and what will never be exposed. Week nine to twelve: expand only tools that show measured usage. Deprecate noisy tools. If nobody’s agents call your surface, treat that as a product signal — not a mandate to mirror the entire API.
Pricing and packaging implications
Agent traffic does not look like human traffic. Bursty tool loops can spike cost and support load. Decide early whether agent access is included, metered, or enterprise-only. Some SaaS teams already experiment with outcome-oriented packaging for agent workflows; even if you keep seat pricing, you still need per-tenant caps so one customer’s agent farm cannot exhaust your shared budget. Also plan for support: “the agent deleted my project” needs a clearer incident path than “a user clicked delete.” Idempotency keys, soft deletes, and approval gates are product features when agents are clients.
