An agency lead pastes a CSV of PageSpeed scores into ChatGPT and asks for a client summary. It works once. The next week the export is stale, the columns drifted, and nobody wants that spreadsheet sitting in a third-party chat history. The question we hear is not whether assistants are useful. It is how a SaaS product should let ChatGPT or Claude read this tenant's data without turning the dashboard into a scrapable public page.
That is why we are studying the Model Context Protocol (MCP) as a possible future interface for Apogee Watcher. It is not in the product today. We are still in planning and early development: no customer MCP endpoint, no OAuth assistant flow, no ship date. MCP is a way for assistants to call tools and resources you define, under authentication you control. It is not a licence to mirror your entire database into a prompt. What follows is the framing we use while we explore that idea: scoped access, tenant isolation, and honest limits.
Why CSV paste into ChatGPT fails for multi-tenant SaaS
Copy-paste workflows feel fast because they skip integration work. For a monitoring product used by agencies, they fail on three fronts that show up in the first serious client week, and none of those fronts is "the model was not smart enough." The failure is operational: stale data, oversized exports, and no way to revoke access after the paste.
First, the data is wrong the moment it leaves the app. Scores move after deploys; a pasted table is a snapshot without a schedule. Second, the blast radius is too large. Exports often include client URLs, organisation names, and enough context to reconstruct a portfolio if the chat log leaks. Third, there is no audit trail of what the assistant was allowed to see. You cannot revoke a paste.
MCP flips that shape. The assistant requests a named tool or resource. Your server checks the user, the organisation, and the scope, then returns only what that call needs. Revocation is a token and a scope change, not a hope that someone deleted a chat.
What MCP means for a monitoring SaaS (and what it does not)
If we ever ship an MCP server for Watcher, we would keep the tool set small on purpose: list sites the caller can access, fetch recent lab results for a page, summarise budget breaches for an organisation, maybe draft a short client note from those numbers. Resources might point at documented schemas or help text, not at raw dump endpoints. That shape is still a design sketch, not a released API.
What it does not mean:
- Giving the model a global read on every customer table because "context helps".
- Letting an assistant invent write actions without a separate, stricter approval path.
- Treating browser automation against the logged-in app as a substitute for a protocol. Scraping a dashboard skips scopes, rate limits, and stable contracts.
That last point matters because agentic browsing and lab scoring are a different problem. Our Watcher piece on Lighthouse agentic browsing covers how crawlers and assistants score pages in lab conditions. MCP for SaaS is the other direction: the assistant comes to your API with credentials, instead of pretending your UI is the API.
How to secure MCP access for ChatGPT and Claude
If we take MCP past early prototypes, we would start from the same multi-tenant rules we already enforce for humans in the app. The protocol would not replace those rules; it would have to enforce them on every tool call. If the human UI already scopes by organisation, any assistant path must do the same without a special case.
Authenticate every tool call. Prefer OAuth (or an equivalent delegated login) so the assistant acts as a named user, not as a shared "bot key" that spans organisations. Shared service accounts are how one agency's chat session starts reading another client's URLs. Named users also make revocation boring and reliable.
Scope tools to the smallest useful unit. Read-only "latest scores for site X" is a different risk class from "export all historical JSON for the organisation". Default to read. Writes, if any, need separate scopes and louder confirmation.
Keep tenant isolation in the server, not in the prompt. The model should never be asked to "only look at org 42". The server must refuse rows outside the authenticated organisation before any response is built. Prompt instructions are not an access-control layer.
Log what was called. Agencies will ask which data left the product. A tool-call audit (who, when, which site or page, which tool) would be part of any serious design, not an optional operations nicety you add after the first incident. Without that log, support cannot answer a simple security questionnaire.
Rate-limit and page results. Assistants retry. Unbounded list tools become an accidental data pump, so pagination and quotas belong in the server design from day one. Treat a chat session like any other API client that can loop.
None of this is unique to MCP. It is the same discipline you need for any customer-facing API. MCP just makes the consumer an LLM host instead of a custom script, which raises the cost of a sloppy default.
How MCP could layer onto agency PageSpeed monitoring
Agencies already want continuous checks, not one-off exports. That is the core of setting up automated PageSpeed monitoring across multiple sites: schedules, baselines, and a portfolio view humans can trust. Without that spine, an assistant only speeds up confusion.
In a future design, MCP would sit beside that loop, not replace it. The monitoring product would still own discovery, schedules, budgets, and history. The assistant would use MCP to ask narrow questions against that truth: "Which of our top ten URLs failed mobile LCP this week?" or "Summarise budget breaches for Client A since Monday." The answer should cite the same numbers the app would show, not a fresh scrape of public PageSpeed Insights that ignores your device splits and your URL list.
We describe that as layer, don't replace. ChatGPT or Claude is not the monitoring system that runs tests and stores results. Watcher (or your equivalent) remains that system. MCP, if we ship it, would be a controlled read path for people who already live in an assistant UI for drafting and triage. Today, that path does not exist in Watcher; customers use the app, exports, and whatever reporting they already run.
Honest limits of MCP for SaaS user data
MCP is not part of Apogee Watcher today. We are in planning and early development only: exploring the access model, not advertising a feature. Backstage posts should say what we are thinking through, not invent a ship date. The useful part for other SaaS teams is the access checklist, even before anyone opens a pull request.
Limits we accept up front:
- Assistants will still invent numbers if you ask them to guess thresholds that are not in the tool response. Return measured values; do not ask the model to invent budgets.
- MCP does not fix a thin URL inventory. If you only monitor the homepage, the assistant will sound confident about a thin slice of reality.
- Security review still belongs with your customer's IT policies. Some enterprises will forbid any assistant host from receiving client URLs. In those cases, keep data in the app and use human-authored summaries.
If your team is evaluating whether to add an LLM host to your SaaS, start with the access model before the demo prompt. Decide which tools exist, which scopes map to roles, and how revocation works on a Friday afternoon when a freelancer leaves. The protocol is the easy part once those decisions are written down.
Design the deny list before the demo
We will keep Watcher's monitoring spine on the product we ship today: multi-site schedules, budgets, and alerts that do not depend on a chat window. MCP remains optional future work in early exploration. If we continue, it would be a candidate interface for secure, scoped reads so ChatGPT and Claude could work with your organisation's data without a CSV ritual. The monitoring loop would stay the source of truth; the assistant would get a narrow door into it, only after auth, scopes, and audit are designed well enough to trust.
If you are designing the same surface for your own SaaS, write the deny list first: which fields never leave the boundary, which tools are read-only by default, and how tenant checks run before any response leaves the server. Then give the assistant the smallest tools that still make agency workflows faster. That is the bar we will hold ourselves to if MCP moves from planning into a real Watcher release.
Top comments (0)