Get one monitored page in full, including every setting add_source and update_source can write — userPrompt, notificationsEnabled and updateSensitivity — which list_sources does not return. Read a setting through this tool before changing it, and call it again to confirm the change landed. monitoringFrequency is the cadence stored on the page and effectiveMonitoringFrequency the one in effect: checks run on a scheduler tick, so the two differ whenever the stored cadence is the faster of the pair, and on a verified account with an empty balance the effective value is the weekly rotation (10080) while monitoringFrequency keeps the stored setting. nextCheckTime is absent when there is no next check to report: no check is coming at all (a paused or auto-paused page), or the page has never been checked and its first one has not landed — which is what you will read right after add_source, on an active page. updateSensitivity runs from 0 to 1 and decides how much of a page's churn is worth reporting; the response's sensitivityLevel names the band the number falls in: 0-0.33 is low (material facts only, and a price must move 5% to alert), 0.34-0.66 is medium (the default when it was never set; adds supporting detail, 2% on price), 0.67-1 is high (adds small clarifications too, 0.5% on price). lastListRead says how much of the page the last check read: coverage "partial" means it did not cover the list — it read itemsRead of at least pageItems items — so the page holds items this source is not watching. "whole" means the extraction covered the list. It does NOT mean the page is fully stored: itemsRead is what survived the gates below the extractor, so it can sit under pageItems when they refused rows. itemsDropped is how many they refused: itemsRead plus itemsDropped is what the extraction answered, so anything still short of pageItems is what it never answered. That arithmetic needs itemsDropped to be present — a reading that carries itemsRepeated without it predates the field and is a page whose last check is older than it, not a check that refused nothing. itemsDroppedLost is how many of those refusals cost this page a row; itemsDropped minus it is what the pipeline correctly declined — chrome, rows off the monitoring instructions, a repeat, a shape the contract does not name — so a steady itemsDropped with itemsDroppedLost at 0 is a healthy page and not a short one. It is present whenever itemsDropped is, including as 0, so an itemsDropped with no number beside it is a reading older than the field rather than a check that lost nothing. reason "items_dropped" names the check where they refused every one of them, and itemsRepeated the rows folded into a sibling, which is one part of itemsDropped and not extra to it, and one itemsDroppedLost does not count. reason says what fell short: three budgets (item_cap, prompt_cut, selection), short_answer, which is no budget at all — the check simply came back with fewer items than the page holds — and items_dropped, where the check read the page and a gate below the extractor refused every item it found, leaving itemsRead at 0. itemsRead is what the check took INTO the source, so it can never exceed the rows the page produced. itemsRepeated, when present, is how many rows the check read and did not store as items of their own because another item of the same check had the same identity; a repeat is already outside itemsRead, so the two never overlap, and it is one named part of itemsDropped rather than an addition to it. listReadCut answers what lastListRead cannot: lastListRead describes only the last check and reads unmeasured on a check that did not read the list, so a page whose lowered item cap cut a read and that has not changed since shows nothing there. When listReadCut is present the stored items are SOME of what the page shows, and it stays until a whole-page reread that the item cap no longer cuts clears it (it kept rows, ran at a cap that held, and read whole or short_answer, never item_cap, prompt_cut or selection). Its absence is not proof the page is fully stored: a page whose own count includes the header row of a table reads short_answer even when every row was read, so compare list_source_entries with the page; it is absent when no cut is known, which includes a page that is short only because of its own configured cap. time is when the cut was first noted (epoch milliseconds), which is the check that cut the read, except on a page noted by hand before the field existed, where it is the day it was noted; retries counts the whole-page reads spent on it: below 3 a check that finds the page unchanged reads it whole again (a page that changed keeps its diff, and the retry waits), and at 3 the retries stop and the field stays as the report that the items are short.