Describe the two things you want to watch
For a public API, provide its public HTTP(S) endpoint and expected behavior. For a scheduled job, describe when it runs, how long successful work normally takes, and where a success signal can be sent. The remote MCP server cannot inspect your local repository by itself; provide context or let your coding assistant inspect the repository using its own capabilities.
Use this request:
Review my public API and scheduled job. Inspect MonoDuty workspace context and integration guidance, then propose the supported monitoring setup. Ask for missing details and explain the changes before applying them.
Review before creating
Ask the assistant to inspect monoduty_get_workspace_context and monoduty_get_integration_guide. Preview instrumentation to validate proposal fields. Previewing does not save a plan, and quota and ownership checks still happen when submitting.
With creation permission, reuse an appropriate service or create one, then create the supported Monitor, Heartbeat or Webhook. Without creation permission, use a proposal and have an administrator review, claim credentials and activate it in the dashboard.
Know when checks start
A Monitor starts checking its public target immediately. A new Heartbeat waits for the first real successful-job ping before its missed-signal timer begins. Wire the success signal to successful completion of the job rather than treating resource creation as proof the job is reporting.
Store returned secret URLs in the application or deployment secret store. Follow the returned integration instructions and the documented Heartbeat contract linked from the MCP setup documentation.
Finish with a controlled delivery test. Seeing resources in the dashboard does not prove that an incident will reach the intended person.
References
MonoDuty MCP setup and permissions · MonoDuty MCP overview
Reviewed against MonoDuty documentation on September 30, 2026.