Skip to main content
Glama

iGods GEO Visibility Tool

by com.igods.geo.mcp
OverviewDiscussionsAdmin

Manage schedules

gvt_schedule_test
Destructive

Manage recurring GVT test schedules: add, delete, reset, pause, resume, cancel, and change_frequency. Discover existing schedules and their schids via gvt_list_schedules; control modes require a schid. For one-off tests use gvt_run_visibility_test; for queued batches without recurrence use gvt_run_visibility_batch. Modes: "add" upserts schedules for the provided urls without duplicating; "delete" permanently removes schedule entries by schid or url (test results are never deleted by any mode); "reset" is destructive — deletes all matching schedules first (domain-scoped when provided, otherwise ALL account-wide), then upserts the provided urls; "pause" halts reversibly; "resume" restarts a paused schedule and clears auto-pause reasons and failure counts; "cancel" permanently ends the schedule (schid unusable); "change_frequency" updates the recurrence interval. Management modes (add/delete/reset) require urls; control modes require schid. Subscription-tier enforcement applies.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoSchedule operation mode. add/delete/reset operate on URLs (require urls array). pause/resume/cancel/change_frequency operate on a single schedule (require schid).add
urlsNoArray of URL/schedule objects. Required for add, delete, and reset modes.
schidNoSchedule ID. Required for pause, resume, cancel, and change_frequency modes.
domainNoDomain to scope a reset operation (reset mode only). e.g. "example.com". Matches https://, http://, with/without www., with/without trailing path. Omit to reset ALL schedules.
frequencyNoNew frequency for the schedule. Required for change_frequency mode.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
successNoTrue when the requested mode completed
scheduledNoSchedules now in effect (add/reset modes)
deletedByUrlNoPer-URL breakdown of deleted schedules (delete mode). Present on delete mode responses, including schid-based deletes; omitted for reset mode.
deletedCountNoSchedule entries removed (delete/reset modes)
upsertedCountNoSchedules created or updated (add/reset modes)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / properties / deletedByUrl / description
      Previous value: -"Per-URL breakdown of deleted schedules (delete mode)"New value: +"Per-URL breakdown of deleted schedules (delete mode). Present on delete mode responses, including schid-based deletes; omitted for reset mode."
  2. Changed11 schema fields changed
    • addedOutput schema / properties / deletedByUrl / description
      Added value: +"Per-URL breakdown of deleted schedules (delete mode)"
    • addedOutput schema / properties / deletedByUrl / items / properties / count / description
      Added value: +"Number of schedule entries deleted for this URL"
    • addedOutput schema / properties / deletedByUrl / items / properties / frequencies / description
      Added value: +"Frequencies that were removed for this URL"
    • addedOutput schema / properties / deletedByUrl / items / properties / url / description
      Added value: +"The URL whose schedules were deleted"
    • addedOutput schema / properties / deletedCount / description
      Added value: +"Schedule entries removed (delete/reset modes)"
    • addedOutput schema / properties / scheduled / description
      Added value: +"Schedules now in effect (add/reset modes)"
    • addedOutput schema / properties / scheduled / items / properties / schid / description
      Added value: +"Schedule ID for later pause/resume/cancel calls"
    • addedOutput schema / properties / scheduled / items / properties / url / description
      Added value: +"The URL placed on schedule"
    • addedOutput schema / properties / scheduled / items / properties / wpPostId / description
      Added value: +"Associated WordPress post ID, when provided"
    • addedOutput schema / properties / success / description
      Added value: +"True when the requested mode completed"
    • addedOutput schema / properties / upsertedCount / description
      Added value: +"Schedules created or updated (add/reset modes)"
  3. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "description": "Result varies by mode: add/reset return upsertedCount and scheduled; delete returns deletedCount and deletedByUrl",
+  "properties": {
+    "deletedByUrl": {
+      "items": {
+        "properties": {
+          "count": {
+            "type": "integer"
+          },
+          "frequencies": {
+            "items": {
+              "enum": [
+                "daily",
+                "weekly",
+                "monthly",
+                "once"
+              ],
+              "type": "string"
+            },
+            "type": "array"
+          },
+          "url": {
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "deletedCount": {
+      "type": "integer"
+    },
+    "scheduled": {
+      "items": {
+        "properties": {
+          "schid": {
+            "type": "string"
+          },
+          "url": {
+            "type": "string"
+          },
+          "wpPostId": {
+            "type": [
+              "string",
+              "null"
+            ]
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "success": {
+      "type": "boolean"
+    },
+    "upsertedCount": {
+      "type": "integer"
+    }
+  },
+  "type": "object"
+}
  4. First observed

TDQS

A5/5.0
Behavior5/5

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

The description goes well beyond the annotations by detailing consequences: delete permanently removes entries but never deletes test results; reset is destructive and deletes all matching schedules before upserting; pause is reversible; resume clears auto-pause reasons and failure counts; cancel makes the schid unusable. The destructiveHint annotation is confirmed and enriched with mode-specific scope and side effects.

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?

The description is dense but every sentence earns its place: it starts with the primary purpose, then immediately routes to sibling tools, then defines each mode with its behavioral consequence. The mode definitions are compact yet complete, and the requirement summary sentence is a useful checklist.

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?

Given the tool's multi-mode complexity and zero required fields in the schema, the description fully compensates by specifying mode-specific argument requirements, destructive behavior, domain scoping, and the relationship to schedule discovery. The presence of an output schema means return-value details are already covered elsewhere, so nothing essential is missing.

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

Parameters5/5

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

Even though the schema covers all parameters, the description adds crucial operational meaning: 'add' upserts without duplicating, 'delete' can target schid or url, 'reset' is domain-scoped or account-wide, and 'change_frequency' requires a new frequency. This clarifies how the optional-looking schema fields (all non-required) actually combine per mode, which the schema alone does not convey.

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 opens with a specific verb and resource: 'Manage recurring GVT test schedules,' then enumerates the seven supported modes (add, delete, reset, pause, resume, cancel, change_frequency). It differentiates from sibling tools by explicitly naming gvt_list_schedules, gvt_run_visibility_test, and gvt_run_visibility_batch as alternatives for discovery and non-recurring runs.

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 routing guidance: use gvt_list_schedules to discover schids, use gvt_run_visibility_test for one-off tests, and use gvt_run_visibility_batch for queued non-recurring batches. It also states mode-specific requirements, such as 'Management modes (add/delete/reset) require urls; control modes require schid,' so an agent knows exactly when to invoke this tool versus siblings.

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

All iGods GEO Visibility Tool toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources