iGods GEO Visibility Tool (GVT)

Run a visibility test

gvt_run_visibility_test

Run a GEO visibility test on a URL. Analyzes 7 categories: JavaScript dependencies (js), no-JS rendering (nojs), semantic HTML5, heading structure, schema.org markup, social tags, and accessibility. This is an async operation — it returns a tid immediately. Pass that tid to gvt_get_test_results to retrieve scores and issues once the test completes (poll until status is not "pending" or "running").

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "url": "<url>"
    },
    "name": "gvt_run_visibility_test"
  }
}

Input Schema

Name	Required	Description	Default
`url`	Yes	The URL to analyze
`waitForJs`	No	Wait for JavaScript rendering before analysis. Set to false to skip JS rendering (faster, but may miss dynamically injected content).

Output Schema

Name	Required	Description
`tid`	No	8-character test ID to poll with
`next`	No	The suggested next call
`status`	No	Always pending at queue time
`message`	No	Human-readable acknowledgement with polling guidance

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedSep 10, 2026
- addedOutput schema / properties / message / description
```
Added value: +"Human-readable acknowledgement with polling guidance"
```
- addedOutput schema / properties / next / properties / arguments / description
```
Added value: +"Arguments for the next call"
```
- addedOutput schema / properties / next / properties / arguments / properties / tid / description
```
Added value: +"The tid to poll with"
```
- addedOutput schema / properties / next / properties / tool / description
```
Added value: +"The tool to call next"
```
- addedOutput schema / properties / status / description
```
Added value: +"Always pending at queue time"
```

Changed1 schema field changedSep 10, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "description": "Async acknowledgement. Poll gvt_get_test_results with the returned tid until status is not pending or running.",
+  "properties": {
+    "message": {
+      "type": "string"
+    },
+    "next": {
+      "description": "The suggested next call",
+      "properties": {
+        "arguments": {
+          "properties": {
+            "tid": {
+              "type": "string"
+            }
+          },
+          "type": "object"
+        },
+        "tool": {
+          "enum": [
+            "gvt_get_test_results"
+          ],
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "status": {
+      "enum": [
+        "pending"
+      ],
+      "type": "string"
+    },
+    "tid": {
+      "description": "8-character test ID to poll with",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

First observedSep 9, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Pipelines the async nature explicitly: it says 'returns a tid immediately' and that results are retrieved separately by passing tid to gvt_get_test_results, with polling instructions. This behavior isn't implied by annotations (readOnlyHint=false, no idempotentHint), so the description carries the burden and does so thoroughly. No contradiction with annotations.

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?

Concise but information-dense. Two sentences: first defines the tool's function and scope, second addresses the async behavior and next steps. No filler; every sentence earns its place.

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 an output schema exists (though not detailed here), the description need not explain return values. It covers the core: what the tool does (analyzes 7 categories), the async contract, and how to proceed (poll until status changes). For a tool of moderate complexity with a well-covered schema, this is complete.

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?

Schema description coverage is 100%, both parameters (url and waitForJs) already have clear descriptions in the schema. The description adds marginal value beyond the schema—it doesn't mention parameters at all, but the schema is sufficient. Baseline 3 applies because the description adds no extra parameter context but doesn't need to.

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 the specific action (run a GEO visibility test on a URL), lists the 7 categories it analyzes (js, nojs, semantic HTML5, heading structure, schema.org markup, social tags, accessibility), and differentiates itself from siblings like gvt_run_visibility_batch (batch) and gvt_schedule_test (scheduled). The purpose is unambiguous.

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 instructs when to use this tool: to run a single visibility test on a URLichelses immediate asynchronous result. It contrasts with gvt_get_test_results (retrieve results by tid) and implies not for batch (run_visibility_batch). It provides clear workflow guidance: pass the tid to gvt_get_test_results and poll until status changes.

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 (GVT) tools Inspect

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

Need Help?