MCP Introduction
What the VitalSentinel MCP server is, what an AI assistant can do with it, and how it differs from calling the API yourself.
The VitalSentinel MCP server lets an AI assistant read and act on your monitoring data on your behalf. Connect it once, then ask questions in plain language:
- "Which of my domains regressed on LCP this week?"
- "Traffic dropped on Tuesday. What changed?"
- "Is anything blocked in robots.txt that shouldn't be?"
- "Give me a postmortem for last night's outage."
Model Context Protocol is an open standard for connecting AI assistants to external systems. Any MCP-capable client can connect: Claude, ChatGPT, Cursor, Claude Code, VS Code, and others.
Server URL
https://mcp.vitalsentinel.com/mcpThat is a remote server over streamable HTTP. There is nothing to install, no npx package, no local process, and no configuration file holding a secret.
Remote is the only way this server is offered, and that is a settled decision rather than a sequencing one. A local package's only practical credential is a long-lived key sitting in a config file, which is exactly the failure mode the design below exists to avoid.
How it works
Your AI assistant (Claude, ChatGPT, Cursor, ...)
|
| MCP over streamable HTTP, carrying your own OAuth token
v
mcp.vitalsentinel.com
|
| HTTPS, the same token forwarded unchanged
v
VitalSentinel public API /api/public/v1/...The MCP server is a translation layer and nothing more. Every tool call becomes one or more calls to the public API, carrying your own credential.
It holds no credentials of its own. No database access, no service account, no shared API key. It never issues a token, never mints one, and never caches one. That single property is why it cannot act with more authority than the credential you handed it, and why it stores nothing about you.
What it can do
70 tools across 15 modules, covering the same data the dashboard shows:
| Area | Examples |
|---|---|
| Orientation | List workspaces and domains, get a cross-module health snapshot |
| Performance | Core Web Vitals from RUM and CrUX, vitals timelines, worst pages, LCP and INP subpart breakdowns |
| Availability | Uptime status, incident history, SSL expiry, synthetic test results |
| Search | Search Console performance, queries, pages, indexing status and issues |
| Traffic | Web Analytics overview, top pages, sources, audience, custom events, ecommerce |
| Technical SEO | robots.txt rules and changes, URL testing, sitemap URLs and conflicts |
| Operations | Alert rules, fired alerts, notifications, report templates, credit balance |
Plus four guided prompts for common investigations and four resources an assistant can read directly. See the tool reference and prompts and resources.
What a browser sign-in asks for
A browser sign-in is not read-only. The server advertises 29 scopes during discovery, 17 read plus 9 write and 3 run, so a client that follows discovery asks you to consent to all of them and the resulting connection can reach every tool.
This changed on 5 August 2026. The server previously advertised read scopes only, which left every one of its write and run tools unreachable over OAuth. That was a defect rather than a deliberate policy, and connecting today grants more than it used to. An existing connection keeps the scopes you originally approved until you consent again.
The consent screen is where you decide. It lists what is being requested under Read, Configure, and Run, and it is not editable, so you approve the whole request or deny it. Read it before approving, and see Security for why that matters when the server also returns content harvested from the sites you monitor.
If you want a narrower connection than the one the consent screen offers, connect with an API key carrying only the scopes you want. See Connecting.
Tools appear based on what you can actually do
The tool list is built once per connection, after the server asks the API who you are. A credential never sees a tool it cannot use, rather than seeing it and having every call fail.
This uses your effective permissions, not the raw scopes on the credential. A credential created by a workspace member legitimately advertises fewer tools than one created by an admin, because a member's write access is stripped out before the tool list is built. See Scopes.
What it will never do
Some capabilities are structurally impossible here, not merely unimplemented:
- Create, delete, or rename a workspace or a domain
- Connect or disconnect a Google account
- Create, rotate, or revoke a credential
- Touch billing or your subscription
- Read individual visitor sessions. RUM data through the API is aggregate only, at any scope.
- Edit the robots.txt file on your site. It reads yours and annotates changes in VitalSentinel. It cannot write to your server.
Tool names matching those patterns are blocked at startup, so a future tool cannot quietly reopen a hole an explicit decision closed.
MCP or the API?
| Use the MCP server when | Use the REST API when |
|---|---|
| A person is asking questions and wants an answer | Software needs a deterministic result |
| The investigation path is not known in advance | The sequence of calls is fixed |
| You want the assistant to correlate across modules | You are building a dashboard, an export, or an alerting pipeline |
| You are exploring | You are shipping |
Both hit the same data, with the same permissions, metered against the same credit allowance.
Where to go next
Connecting
Step-by-step setup for Claude, ChatGPT, Cursor, Claude Code, and any other MCP client.
Tool reference
All 70 tools, what each one answers, and the scope it needs.
Prompts and resources
Four guided investigations, ready to run.
Security
What the server can and cannot do, and how content from monitored sites is handled.
Versioning and Stability
What the v1 contract guarantees, what counts as a breaking change, the six-month notice period, and what your client has to do to stay covered.
Connecting a Client
Add the VitalSentinel MCP server to Claude, ChatGPT, Cursor, Claude Code, VS Code, or any other MCP-capable client.
