Skip to main content
Use this workflow when you know the source page and the target it should link to. For a one-time local check, use first result. Hosted checks need an accessible project and check allowance.

​
Create and check the watch

  1. Call list_projects and choose the project.
  2. Call monitor_link with its projectId, your source and target URLs, and the target scope. Save the returned watch identifier. Identical placements are deduplicated.
  3. Call request_link_check with the watch identifier and an idempotency value unique to this intended check.
  4. Save the returned job identifier. Read get_check_job until it reaches a terminal state. Respect retry guidance and avoid tight polling.
  5. Read get_link_history for dated observations. Use the observation identifier to locate occurrences or retrieve retained evidence.
The reference pages contain exact requests for MCP, CLI and HTTP. Admission to the queue reserves work; it does not prove the link is present. If the network fails after submission, retry the same arguments and idempotency value to recover the same request.

​
Decide what the observation supports

A completed job can yield unknown. Read the observation’s reason separately from the job state. One absent observation describes that fetch; confirmed loss requires two complete absent observations at least thirty minutes apart. Unknown attempts preserve uncertainty. A source link and destination health answer different questions. To check the destination independently, use monitor_target and its check job flow. Keep the watch active for later changes, or pause it with update_link_watch. If raw evidence has expired, keep the dated observation metadata and request a new check when needed. A new check cannot recreate the historical page. See evidence and troubleshooting.