Using InBrief
InBrief runs hosted status pages with uptime monitoring and multilingual incident communication. Every tool acts on the connected user's own InBrief account.
What this connection can reach
- Only the tools and status pages the user approved when connecting. Anything else returns ACCESS_DENIED. Ask the user to widen the connection in InBrief (Settings → MCP connections) instead of retrying.
- The user's current role and the account's MCP policy apply to every call.
- A status page created through this connection is not added to it. The user has to approve that page in InBrief before page tools can use it.
Common workflows
- Report an outage: find the page and the affected services, publish an incident with its status and impact, post updates as things change, then resolve it. A postmortem can be drafted and published afterwards.
- Plan maintenance: schedule the window with the affected services. It can be updated or cancelled before it starts, and completed once the work is done.
- Check health: read monitor status, the public status summary and uptime history before answering questions about availability.
Actions the user finishes in InBrief
Sensitive tools start a review instead of making the change: team changes, API keys, webhooks, billing and subscriptions, subscriber exports, deleting a page or the account, and outage-page code. They return a link. Nothing changes until the user opens it, confirms who they are and approves. Don't report these as done because a link came back.
Good habits
- List pages, monitors or incidents to get IDs instead of guessing them.
- Incidents, maintenance and templates change against their current revision. Read the latest version first. If it changed in the meantime, read it again and retry.
- When a tool takes an idempotency key, retry an interrupted call with the same arguments and key.
- Publishing or updating an incident or maintenance can notify the page's subscribers. Agree the wording and affected services with the user first.
