Opengraph io MCP

setMonitoringSchedule

DestructiveIdempotent

Create, adjust, pause, or remove recurring website audit schedules. Set frequency, run time, timezone, page scope, and notifications while keeping existing settings.

Instructions

Turn recurring audits on, change their settings, or turn them off for a website.

THIS COMMITS ONGOING SPEND. Each scheduled run consumes the organization's page quota indefinitely until the schedule is changed or removed, and completed runs can trigger alert email. Confirm with the user before enabling or changing a schedule.

Set enabled: false to stop monitoring. That DELETES the schedule configuration — frequency, timing and options are not retained, and re-enabling means setting them again. To pause temporarily and keep the configuration, use paused: true instead.

Settings you do not pass are carried over from the stored schedule, so you can change one field without re-sending the rest. Alert recipients cannot be set here; they are managed in the dashboard. Requires the Site Audit scheduling entitlement — the call fails with a plan message without it.

Input Schema

TableJSON Schema

Name	Required	Description
`paused`	No	Pause without deleting — the configuration is kept and can be resumed.
`enabled`	No	false removes the schedule and stops recurring audits. Defaults to true.
`runHour`	No	Hour of day to run (0–23). Anchoring needs runHour and timezone together.
`timezone`	No	IANA zone, e.g. 'America/New_York'. Runs stay at the same wall-clock time across DST.
`dayOfWeek`	No	Day for a weekly schedule — 0 is Sunday.
`frequency`	No	How often the audit runs. Required when enabling.
`runMinute`	No	Minute of the hour.
`websiteId`	Yes	Website ID from listWebsites.
`dayOfMonth`	No	Day for a monthly schedule (1–28, so the day exists in every month).
`pageScopeMode`	No	Which pages each run covers.
`includeNewPages`	No	Audit pages discovered after the schedule was created. Increases quota use over time.
`notificationMode`	No	When alert email is sent for this schedule.
`autoAdvanceBaseline`	No	Move the comparison baseline forward after each run, so changes are measured against the previous run rather than a fixed point.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`enabled`	Yes
`schedule`	No
`websiteId`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv2.1.0Sep 22, 2026

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations (destructiveHint, readOnlyHint, etc.), the description discloses critical behavior: ongoing spend, indefinite quota consumption, alert emails, permanent deletion of schedule configuration when disabled, partial-update carryover semantics, and failure without the entitlement. These are exactly the hidden behavioral traits an agent needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Although longer than average, every sentence carries operational weight. High-risk information is front-loaded with 'THIS COMMITS ONGOING SPEND,' and the pause-vs-disable distinction is clearly separated from the general behavior. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex 13-parameter tool, the description covers cost implications, destructive semantics, partial-update behavior, entitlement requirements, and parameter relationships. Since an output schema exists, missing return-value details are acceptable. Nothing essential is left unexplained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so parameters are already well described. The description adds valuable cross-parameter context: frequency is required when enabling, unpassed settings are carried over, and includeNewPages increases quota use over time. This goes beyond the schema and helps correct parameter decisions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the exact resource and verbs: turn recurring audits on, change their settings, or turn them off for a website. It clearly differentiates this from related tools like getMonitoringSchedule (reading) and startSiteAudit (manual runs) by emphasizing recurring schedule configuration.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit when-to-use and when-not-to-use guidance: use `paused: true` to keep configuration, use `enabled: false` to permanently stop and delete, and know that alert recipients are managed in the dashboard, not here. It also calls out the entitlement prerequisite and the need to confirm with the user before enabling or changing a schedule.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.