Skip to main content
Glama

iGods GEO Visibility Tool

List schedules

gvt_list_schedules
Read-onlyIdempotent

Retrieves the paginated roster of the authenticated caller's test monitoring schedules, allowing filtering by domain, frequency, and status. This is the only way to discover existing schedules and their schids, which the pause/resume/cancel/change_frequency modes of gvt_schedule_test require. Completed one-off rows are hidden by default: batch runs create a throwaway once row per queued URL, so include them only with includeCompletedOnce true. The row's tid is deliberately not surfaced (it is often stale); use gvt_list_tests or gvt_get_latest for test result lookups. Read-only: consumes rate limit, never test credits.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoThe maximum number of schedules requested for this page.
domainNoFilter to schedules matching this domain substring.
offsetNoThe number of skipped items from the beginning of the result set.
statusNoFilter by the derived overall state of the schedule.
frequencyNoFilter by repetition interval.
sortDirectionNoSort order by creation time; desc is newest first.desc
includeSubdomainsNoWhether subdomains should be included in the domain filter match.
includeCompletedOnceNoWhether to include completed one-off schedules in the results. Hidden by default because batch runs create a throwaway once row per queued URL; include them only when investigating batch history.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoPage size applied to this response
totalNoTotal schedules matching the filters, across all pages
domainNoThe applied domain filter, null when unfiltered
offsetNoOffset applied to this response
statusNoThe applied status filter, null when unfiltered
hasMoreNoTrue when more results exist beyond this page
frequencyNoThe applied frequency filter, null when unfiltered
schedulesNoOne entry per schedule, newest first by creation time
nextOffsetNoOffset for the next page, null when hasMore is false
includeSubdomainsNoThe applied subdomain-inclusion setting
allowedFrequenciesNoFrequencies the caller may set when creating schedules
maxActiveSchedulesNoThe caller's cap on active schedules; add mode enforces this limit
includeCompletedOnceNoWhether completed one-off rows were included in this response

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations declare readOnly, idempotent, and non-destructive, and the description adds meaningful behavioral detail beyond those: pagination, hidden completed one-off rows due to batch-run throwaway entries, the deliberate omission of tid because it is often stale, and the distinction that it consumes rate limit but never test credits. This is rich, honest context.

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?

Five sentences, each carrying a distinct piece of necessary information: function, unique purpose, hidden-row caveat, tid caveat with alternative routing, and read-only/rate-limit behavior. It is front-loaded with the core purpose and contains no filler or repetition of schema content.

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 an 8-parameter, 0-required, read-only list tool with an output schema, the description covers purpose, alternatives, behavioral caveats, and parameter edge cases. The output schema handles return-value details. Nothing an agent needs to invoke this correctly is missing.

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

Parameters3/5

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

Input schema coverage is 100%, with each parameter already having a solid description, so the description does not need to restate them. The description does add useful context for includeCompletedOnce (why it is hidden by default and when to include it), but that is a marginal enhancement over an already complete schema.

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?

States a specific verb ('Retrieves'), resource ('paginated roster of the authenticated caller's test monitoring schedules'), and capabilities (filtering by domain, frequency, status). It also distinguishes itself as the only way to discover schedules and schids, clearly separating it from sibling list tools like gvt_list_tests.

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?

Explicitly identifies when to use this tool (discovering existing schedules and schids for gvt_schedule_test's pause/resume/cancel/change_frequency modes) and when not to (for test result lookups, pointing to gvt_list_tests or gvt_get_latest). It also clarifies the edge case around includeCompletedOnce, leaving no ambiguity about selection.

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