Skip to main content
Glama

List monitored pages

list_sources
Read-onlyIdempotent

List the user's monitored pages with their current monitoring and fetch health. Read lastListRead before trusting a page's items to be all of them: coverage "partial" means that check did not cover the list, and itemsRead/pageItems say how far it got. "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 splits that total into the part that cost the page a row and the part the pipeline correctly declined (itemsDropped minus it): do not read a high itemsDropped as a problem on its own, because page chrome and rows off the monitoring instructions land there every check and are the pipeline working. itemsDroppedLost is the number to act on, and it is present whenever itemsDropped is, including as 0 — a measured "all of those refusals were correct", so an itemsDropped with no number beside it is a reading older than the field. 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 the lost count does not include since the row is held under the item that claimed its identity. listReadCut is the part of that story lastListRead cannot keep: lastListRead describes only the last check, so it reads unmeasured on a check that did not read the list, while listReadCut stays on a page whose item cap had to be lowered and cut a read, until a whole-page reread that the item cap no longer cuts clears it (absent when no cut is known, which includes a page that is short only because of its own configured cap; get_source describes time and retries; retries counts the whole-page reads spent, and a check that finds the page unchanged reads it whole again until it reaches 3). nextCheckTime is when the next check is expected, and it is ABSENT when there is none to report rather than a time that will never arrive: a page you paused, or one auto-paused after repeated failures, has no check coming at all, and a page whose first check has not landed yet has none to name. Read status to tell those apart — the second is active. effectiveMonitoringFrequency is the cadence in effect, which is slower than the stored monitoringFrequency when that is faster than the scheduler's tick. It does not carry a page's monitoring instructions or sensitivity — call get_source for one page's full settings, and list_source_entries for the items it holds. A page can be empty or shorter than limit while more results remain; continue with pagination.nextCursor until pagination.hasMore is false.

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum sources to return (1-100, default 25).
cursorNoOpaque cursor from the previous response's pagination.nextCursor.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior. The description adds substantial beyond-annotation context: how coverage and item counts relate, why itemsDropped can be normal, when nextCheckTime is absent, and how listReadCut differs from lastListRead.

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

Conciseness2/5

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

The purpose is front-loaded, but the rest is a dense, run-on block of roughly 380 words with repetitive and convoluted sentences. Much of the field-interpretation detail could be tightened or structured into clearer clauses without losing meaning.

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

Completeness4/5

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

With no output schema, the description does a thorough job explaining nuanced return fields such as lastListRead, coverage, itemsDropped, itemsDroppedLost, listReadCut, and nextCheckTime. It does not describe basic page identity fields (e.g., id, url, name) that the response likely includes, leaving a small completeness gap.

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 the schema already documents limit and cursor. The description adds useful usage context: a page can be empty or shorter than limit while more results remain, and the agent should continue with pagination.nextCursor until pagination.hasMore is false.

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 opening sentence states a specific verb and resource: 'List the user's monitored pages with their current monitoring and fetch health.' It also distinguishes itself from siblings by noting that it does not carry monitoring instructions or sensitivity and directing the agent to get_source and list_source_entries for those.

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?

It explicitly names alternatives and the conditions that select them: call get_source for one page's full settings, list_source_entries for the items it holds. It also gives concrete guidance on trusting lastListRead, interpreting coverage, and continuing pagination until pagination.hasMore is false.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources