A product manager asks whether ChatGPT can “just call our API” the way a deploy script does. The honest answer is usually no. A REST endpoint returns JSON when something supplies the right path, headers, and body. An assistant needs a named capability, a short description of when to use it, a schema for arguments, and a permission boundary that survives a multi-turn chat. Those pieces are what Model Context Protocol (MCP) is designed to expose. Your existing API can still power the work; MCP is the contract the assistant reads first.
We wrote the companion piece on MCP for SaaS and secure assistant access from the security and tenant-isolation side: CSV paste, scopes, revocation. Here the question is narrower and more developer-shaped: what REST already gives deterministic callers, what MCP adds for ChatGPT and Claude, and why “ship MCP instead of REST” is the wrong fork. In our own product thinking we keep HTTP for automation and CI, and treat assistant-facing tools as a separate surface. Layer both. Do not rip and replace OpenAPI.
A conventional SaaS API is built for deterministic callers. A pipeline knows the route. A webhook knows the event. A customer script knows which query parameters to send. OpenAPI (or your internal docs) describe status codes and payloads for humans and code generators. That is enough for CI, cron, and partner integrations.
Assistants do not start with a hardcoded route. They start with a user sentence (“show me which client sites drifted this week”) and a catalogue of tools they may call. Without tool names, descriptions, and input schemas, the model either invents URLs (GET /api/v1/sites?all=true
on a route that does not exist), asks the user to paste a curl command, or falls back to scraping a dashboard. Scraping is brittle, slow, and a poor fit for tenant-scoped data. The gap is not “JSON versus natural language.” The gap is discovery and safe invocation, and that gap shows up the first time someone tries to answer a portfolio question from a chat window without a tool catalogue.
“We already have an API” closes the automation ticket. It does not close the assistant ticket. MCP sits on top of the same domain logic when you want ChatGPT or Claude to act with credentials the user granted, without teaching every model the shape of your private OpenAPI file.
MCP’s useful vocabulary is different from CRUD:
HTTP verbs still matter under the hood. A tool named get_site_latest_run
may call GET /api/v1/sites/{id}/runs/latest
on your side. The assistant never has to know that path. It needs to know the tool exists, what arguments are required, and whether the call is read-only. OpenAPI describes the path. MCP describes the capability in language the host and model share.
If you only publish REST, every assistant integration becomes a custom glue project: someone maps user intents to routes by hand, or pastes tokens into a prompt. If you only publish MCP and drop REST, you break deploy scripts, webhooks, and partner jobs that should never go through a chat host. The monitoring spine stays on HTTP and schedulers; the assistant gets a thin tool layer on top when humans want answers in chat without pasting your OpenAPI into the prompt. Build gates and deploy hooks need stable, low-latency, non-interactive calls. A Lighthouse CI assertion or a post-deploy budget check should hit an HTTP endpoint (or a CLI that wraps one), wait for a result, and fail the job with a clear exit code. That path does not benefit from tool discovery or multi-turn clarification. It benefits from the same contract you already use for scripts.
We already write about that split for webperf: put a small set of lab checks in the pipeline, and keep portfolio schedules and alerts in monitoring. The CI/CD performance budget guide on our Watcher blog covers how teams wire Lighthouse CI today, and notes that a customer HTTP API for triggering and reading tests is in active development for agency automation on paid plans. That API story is about pipelines and stored results, not about ChatGPT choosing a tool mid-conversation.
For multi-site PageSpeed schedules, the operational guide remains the monitoring setup path: sites, URLs, cadence, budgets. That is human and scheduler work, not assistant tool work. See How to Set Up Automated PageSpeed Monitoring for Multiple Sites. Rule of thumb we use internally: if the caller is a robot with a fixed job, prefer REST (or a CLI). If the caller is an assistant interpreting a human request, prefer MCP tools that wrap the same domain services. Mixing those callers on one “assistant-only” surface usually makes CI flaky and chat sessions over-privileged.
For a multi-tenant PageSpeed product, assistant-facing tools that make sense are mostly read-oriented. Naming the calls settles the catalogue faster than theory:
Tools we would refuse, or gate behind extra confirmation, include anything that changes billing, deletes sites, rotates API keys, or broadens tenant visibility. Assistants amplify mistakes. A wrong DELETE
in a chat session is worse than a wrong GET
. Scopes should default to read, and write tools should be rare, logged, and easy to disable per organisation.
Auth still looks like SaaS OAuth: the user connects the assistant host, grants scopes, and the MCP server enforces tenant isolation the same way the HTTP API would. MCP does not replace your authorisation model. It is another front door that must honour it.
Page-level WebMCP (tools registered in the browser for agentic browsing) is a different problem from a SaaS MCP server. One helps agents use a website UI; the other helps assistants query product data the user already owns. Do not conflate them when scoping a roadmap.
Ask three practical questions:
If the answers are yes, yes, and yes, MCP is a layer. Ship a thin tool catalogue on top of existing services, document scopes clearly, and keep OpenAPI for the callers that never needed natural language. If you cannot answer (2), you are not ready for MCP; you are still clarifying the product surface. REST remains the right interface for scripts, CI, and deterministic automation. MCP is the right interface when an assistant must discover what it may do and call it with structured arguments under user consent. They share backend logic; they do not share the same public contract.
Before you tell the product manager “we already have an API,” write two lists on one page. First: the HTTP routes and webhooks CI, cron, and partners must keep unchanged. Second: the ten or fewer tools a chat host may discover, each read-only by default, each mapped to a service you already run. If the second list is empty, you are not choosing between MCP and REST. You are still deciding what assistants are allowed to know about your product, and that decision belongs on paper before anyone ships a demo integration.