Review uptime coverage and create an approved status monitor
Review uptime coverage and create an approved status monitor. Read provider data first, then explicitly approve the selected change with operator write opt-in and a unique per-call approval key.
A task guide, with live account discovery
This page describes the job to accomplish. It does not publish a fixed provider tool sequence or private execution plan.
- Configure the authorized provider connection in PipMCP and discover its actual published tools with your account key.
- Select the intended operation and review its returned schema, permissions and side effects.
- Call through the gateway, preserve the stable request key and inspect the receipt. Follow hosted confirmation without bypassing uncertain outcomes.
Tool availability and end-to-end success are established by your real account results, not this guide.
Connect the hosted client
Node.js22+. The first run is an offline plan. Real discovery and execution use your PIPMCP_API_KEY; provider credentials stay in PipMCP.
git clone https://github.com/jannikco/better-stack-mcp.git
cd better-stack-mcp
npm ci --ignore-scripts
npm test
npm start
# Set PIPMCP_API_KEY in your environment
npm run doctor
# Launch from an MCP client as a stdio command
npm run serverOne PipMCP key, hosted provider access
Create an account key with connectors:read for discovery and connectors:call for calls. Set PIPMCP_API_KEY in the client environment. Connect the authorized provider account in PipMCP.
When multiple accounts are available, choose explicit PIPMCP_INTEGRATION_ID and PIPMCP_CONNECTION_ID from the hosted inventory. A missing app, missing connection and insufficient scope are different account conditions.
What the evidence establishes
| Capability | Level | Scope |
|---|---|---|
| Client transport and stdio | Tested | Fixtures test the client contract; no provider outcome is implied. |
| Current hosted provider execution | Documented | No current provider Live outcome is established by this directory. |
Tool discovery is not provider execution. Pending, confirmation-required, uncertain, failed and succeeded receipts remain distinct. Inspect returned data before claiming final delivery.