Connect MonoDuty MCP

Connect your assistant

Model Context Protocol (MCP) lets an AI application use external tools. MonoDuty MCP brings workspace context and supported monitoring actions into your coding conversation. See the MonoDuty MCP overview and example request.

In an MCP-compatible coding assistant that supports remote Streamable HTTP and OAuth, add this production endpoint:

https://mcp.monoduty.com/mcp

Sign in with your existing MonoDuty account, select an eligible workspace, and review the requested permissions. Native OAuth handles authorization; you do not need to paste a customer API token or workspace ID into the client.

Your account must be active and verified, with workspace administrator permissions and an API-eligible plan. Public availability does not remove these requirements. See workspace roles and plans and usage. A connection stays bound to the workspace selected during authorization, even if you switch workspaces in the dashboard.

Choose permissions

• Read: inspect workspace context, active alerts, monitoring coverage, and alerting readiness.
• Proposals: allow monoduty_propose_instrumentation to save a setup proposal. The proposal still needs an administrator to review it, claim its credentials, and activate it in the dashboard. This permission alone cannot create active resources.
• Resource creation: separately allow the assistant to create services, public HTTP(S) Monitors, Heartbeats, and Webhook alert sources. This can activate monitoring and return newly created integration credentials once.
• Management: separately allow supported updates, pausing, resuming, deletion, cancellation of pending plans, and incident resolution.

These permissions are separate choices. Existing read or proposal connections do not gain creation or management permissions automatically. To add permissions, reconnect through OAuth and explicitly select them. Allowing a tool inside your assistant does not expand the MonoDuty connection's permissions. Revoke a connection from the dashboard when access is no longer needed.

Set up monitoring

1. Ask the assistant to inspect monoduty_get_workspace_context and fetch monoduty_get_integration_guide. Describe your service, environment, API endpoint, and scheduled jobs; the remote MCP server cannot inspect your local repository by itself.
2. Review the proposed settings and missing details. monoduty_preview_instrumentation validates proposal fields without saving a plan; workspace quota and ownership checks happen when submitting.
3. With creation permission, reuse a suitable service or use monoduty_create_service, then monoduty_create_monitor, monoduty_create_heartbeat, or monoduty_create_webhook. Without creation permission, use the proposal and dashboard approval workflow.
4. Implement the returned integration instructions. A Monitor starts checking its public target immediately. A new Heartbeat waits for the first real successful-job ping before starting its missed-signal timer.

Local stdio connections using customer API tokens do not support direct resource creation; use native OAuth for creation tools. Workspace ownership and plan limits apply to every supported operation.

With management permission, inspect monoduty_get_resource before using monoduty_pause_resource, monoduty_resume_resource, monoduty_update_resource, or monoduty_delete_resource. Use the returned revision to avoid overwriting concurrent changes. monoduty_cancel_instrumentation_plan cancels pending plans; monoduty_resolve_alert resolves an incident but does not repair its source.

Store integration credentials

Direct Heartbeat and Webhook creation returns the new secret URL only in the first successful response. Store it directly in your application or deployment secret store using the exact returned environment variable name. Keep the URL out of chat replies, source code, repository manifests, analytics, and logs.

Retry a timed-out creation with the same idempotency key and identical input. A retry returns the resource mapping without revealing its secret again. Recover a lost credential through the dashboard; changing the key can create a duplicate resource. Existing credentials cannot be retrieved or rotated through MCP.

Run a controlled test

Ask the assistant to help plan the expected failure, incident, recipient, and recovery before you test. Tests that send alerts need your explicit request. MCP tools do not send test alerts, and resource activation, coverage, or readiness checks do not prove notification delivery.

Run the agreed test from your application environment, then verify the incident and delivery result in MonoDuty. Treat unavailable observations or tool errors as unknown, not as proof that your service is healthy.

Follow the relevant contracts for Webhooks, Monitors, and Heartbeats, and check the configured on-call response.