# MCP Introduction
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](https://modelcontextprotocol.io/) 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 [#server-url]
```
https://mcp.vitalsentinel.com/mcp
```
That 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 [#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](/api/introduction), 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 [#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](/mcp/tools) and [prompts and resources](/mcp/prompts-and-resources).
## What a browser sign-in asks for [#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](/mcp/security#the-consent-screen-is-the-control) 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](/mcp/connecting#option-b-connect-with-an-api-key).
## Tools appear based on what you can actually do [#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](/api/scopes#a-credential-is-a-ceiling-not-a-grant).
## What it will never do [#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? [#mcp-or-the-api]
| Use the MCP server when | Use the [REST API](/api/introduction) 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](/api/credits).
## Where to go next [#where-to-go-next]
Step-by-step setup for Claude, ChatGPT, Cursor, Claude Code, and any other MCP client.
All 70 tools, what each one answers, and the scope it needs.
Four guided investigations, ready to run.
What the server can and cannot do, and how content from monitored sites is handled.