Hosted MCP

Hosted MCP is the customer-facing MCP connector for the StatiBeat application. It is the recommended path when you want a remote MCP client such as Claude, Cursor, or another OAuth-capable client to connect through StatiBeat-hosted authorization.

StatiBeat also has a page-scoped stdio MCP server for internal tooling and API-token based automation. The two surfaces intentionally have different setup models and different write boundaries. Use MCP Reference when you need the complete side-by-side resource, prompt, and tool inventory.

MCP integration choices

Surface	Best for	Authentication	Scope model
Hosted MCP	Customer-facing remote clients	StatiBeat sign-in, OAuth consent, refreshable connector tokens	Multi-page discovery plus explicit page_id on page-bound resources and writes
Page MCP server	Internal agents, support tooling, local stdio clients, and page-scoped automation	StatiBeat API token	One configured page, optionally constrained by read-only mode or an allowed-tool list

What hosted MCP is for

Hosted MCP is designed for:

• page admins who want a low-friction connector setup
• real-user OAuth consent with controls in the product
• page-scoped incident and maintenance workflows
• page-scoped Beats health investigation and action review context
• auditable connector access with revoke controls in the product

Hosted MCP is not trying to replace every other integration surface:

• use Slack for chat-native approvals and coordination
• use Terraform for durable configuration and governance
• use the REST API for broader automation

Supported client shape

Hosted MCP is built for remote MCP clients that support:

• a hosted HTTP MCP endpoint
• OAuth-based authorization
• user-directed consent

Today, that means the best fit is clients like Claude and Cursor that can connect to remote MCP servers directly.

What makes it the product path

Hosted MCP:

• is connected from the StatiBeat app through OAuth and PKCE
• is tied to a real signed-in StatiBeat user
• shows approved clients and revoke controls in the admin UI
• publishes the hosted resource URL, authorization server URL, OAuth endpoints, supported scopes, approved clients, and recent connector activity in the product
• uses a curated hosted tool surface that is narrower than the page MCP server
• is intended to be the default customer integration story

Setup flow

1. Open the page admin UI and go to Hosted MCP.
2. Copy the Resource URL shown there.
3. Add that URL in your MCP client.
4. Sign in with your StatiBeat account when the client redirects you to OAuth consent.
5. Approve the requested scopes.
6. Return to Hosted MCP to confirm the client appears under connected clients.

The connector endpoint is shown in the product because the exact app host can vary by environment.

Hosted MCP routes are enabled per environment. When the hosted connector is not enabled, the admin page shows an unavailable state instead of endpoint, consent, and connection controls.

The OAuth flow uses authorization code with PKCE S256, no client secret, 10-minute authorization codes, 1-hour access tokens, and 30-day refresh tokens. Redirect URIs must be https except for http loopback redirects such as localhost or another loopback address. Non-loopback redirect URIs are fail-closed and must be registered with HOSTED_MCP_ALLOWED_CLIENT_REDIRECTS as exact client_id=redirect_uri entries separated by commas, whitespace, or new lines.

OAuth scopes

Hosted MCP uses a narrow scope model in v1:

• mcp.pages.read
• mcp.beats.read
• mcp.incidents.read
• mcp.incidents.write
• mcp.maintenances.read
• mcp.maintenances.write
• mcp.analytics.read

Effective access is always:

• the scopes granted during OAuth
• intersected with the signed-in user’s existing page permissions

That means OAuth approval alone does not let the connector exceed the user’s current page role.

Page scoping

Hosted MCP is multi-page aware for reads and explicit about writes.

Read behavior:

• the connector can discover which pages the signed-in user can access
• read resources are filtered by the same page visibility and permission rules the user already has

Write behavior:

• mutating tools require an explicit page_id
• the backend checks both OAuth scope and page-role permission before it writes
• a connector cannot silently perform broad tenant-wide changes

Scope checks are only one layer. The signed-in user's page permissions must also allow the action:

OAuth scope	Page permission requirement
mcp.pages.read	Page read plus the relevant read permission for status definitions, lifecycle stages, maintenance lifecycle stages, or hierarchy reads
mcp.incidents.read	Incident read
mcp.incidents.write	Incident manage
mcp.maintenances.read	Maintenance read
mcp.maintenances.write	Maintenance manage
mcp.analytics.read	Analytics read
mcp.beats.read	Synthetic monitor read; pending Beat actions additionally require synthetic monitor manage

Current hosted v1 surface

Hosted MCP v1 is intentionally narrow and focused.

Session resources include:

• current user identity
• accessible pages

Page-scoped read resources include:

• page summary
• status definitions
• lifecycle stages
• maintenance lifecycle stages
• hierarchy tree
• active and resolved incidents
• incident detail plus recent updates
• active and upcoming maintenance windows
• maintenance detail plus recent updates
• bounded analytics summary
• Beats inventory, including current stage and automation state
• Beat Groups, including members and shared automation state
• pending Beat actions awaiting operator review
• recent Beat failures
• per-Beat evidence events

Hosted resource URIs use the multi-page form statibeat://pages/{page_id}/.... The client should first read statibeat://pages, choose an accessible page, and then pass that page_id into page-bound resources, prompts, and write tools.

Prompts include:

• draft_customer_incident
• draft_incident_update
• plan_maintenance_window
• review_existing_incident_state
• summarize_current_beat_health
• investigate_beat_failure
• review_pending_beat_action

Prompts are shown only when the connector has the scopes needed for the prompt's required resources.

Write tools currently include:

• create_incident
• add_incident_update
• schedule_maintenance
• add_maintenance_update

Current write-surface limits

Hosted MCP does not currently expose:

• delete operations
• generic patch or update tools
• resolve or reopen lifecycle actions
• Beat mutation tools such as creating, updating, pausing, or running Beats
• Beat action approval or rejection tools
• configuration or governance-heavy writes
• subscriber bulk import or hygiene workflows
• branding, embed, or audience-policy mutation

That boundary is deliberate. Hosted MCP v1 is optimized for safe operational actions first. When a team needs broader page-scoped tools, use the page MCP server and constrain it with a narrow API token, STATIBEAT_MCP_READ_ONLY, or STATIBEAT_MCP_ALLOWED_TOOLS.

Audit and revoke behavior

Hosted MCP is designed to be attributable.

• each connector approval is tied to a real StatiBeat user
• the admin UI shows the current user’s approved clients and granted scopes
• revoking a connection invalidates the connector session and its active tokens
• audited Hosted MCP writes and revokes are surfaced in the Hosted MCP page when audit logs are enabled
• deeper event history remains available in the auditing view when audit logs are enabled

Read, list, and prompt calls record operational metrics, but they are not shown as a full audit-feed history. Writes are guarded with hosted MCP-specific rate limits and audit context so support and operators can distinguish connector actions from browser or token traffic.

Hosted versus page MCP writes

Hosted MCP writes are limited to creating incidents, adding incident updates, scheduling maintenance, and adding maintenance updates.

The page MCP server has the broader operational write set: incident create/update/acknowledge/resolve/reopen/delete, maintenance schedule/update/complete/cancel/delete, manual Beat runs, and pending Beat action approval or rejection. That broader surface is useful for trusted internal automation, but it is not the default customer-facing connector path.

Rollout guidance

For a production rollout:

1. start with read-focused workflows and prompt-assisted drafting
2. connect one or two trusted clients first
3. review the granted scopes and recent activity in the Hosted MCP page
4. add write workflows only after you are comfortable with the audit trail

Hosted MCP is meant to feel like a built-in product integration. If a workflow starts depending on extra customer-side setup outside the app, it has probably drifted away from the supported path.