iGods GEO Visibility Tool

List prompt workflows

gvt_list_prompts

Read-onlyIdempotent

List the GVT prompt workflows: user-invocable recipes that chain GVT tools into complete tasks (check a page, review a monthly batch, analyze regressions, verify fixes, set up domain monitoring, report client status). Each entry lists its arguments. Use gvt_get_prompt to render a prompt with concrete argument values, then follow the rendered instructions to run the workflow. This catalog is static and costs nothing to call on every session start — it never queues tests or consumes credits.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description
`ttlMs`	No	Suggested client cache lifetime in milliseconds
`prompts`	No	The prompt workflow catalog
`promptCount`	No	Number of prompt workflows in the catalog

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedSep 10, 2026
- addedOutput schema / properties / promptCount / description
```
Added value: +"Number of prompt workflows in the catalog"
```
- addedOutput schema / properties / prompts / description
```
Added value: +"The prompt workflow catalog"
```
- addedOutput schema / properties / prompts / items / properties / arguments / description
```
Added value: +"Arguments the prompt accepts"
```
- addedOutput schema / properties / prompts / items / properties / arguments / items / properties / description / description
```
Added value: +"What the argument controls"
```
- addedOutput schema / properties / prompts / items / properties / arguments / items / properties / name / description
```
Added value: +"Argument name"
```
- addedOutput schema / properties / prompts / items / properties / arguments / items / properties / required / description
```
Added value: +"True when the argument must be supplied"
```
- addedOutput schema / properties / prompts / items / properties / description / description
```
Added value: +"What the prompt workflow does"
```
- addedOutput schema / properties / prompts / items / properties / name / description
```
Added value: +"Prompt name for gvt_get_prompt"
```
- addedOutput schema / properties / prompts / items / properties / title / description
```
Added value: +"Human-readable display name"
```
- addedOutput schema / properties / ttlMs / description
```
Added value: +"Suggested client cache lifetime in milliseconds"
```

Changed1 schema field changedSep 10, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "promptCount": {
+      "type": "integer"
+    },
+    "prompts": {
+      "items": {
+        "properties": {
+          "arguments": {
+            "items": {
+              "properties": {
+                "description": {
+                  "type": "string"
+                },
+                "name": {
+                  "type": "string"
+                },
+                "required": {
+                  "type": "boolean"
+                }
+              },
+              "type": "object"
+            },
+            "type": "array"
+          },
+          "description": {
+            "type": "string"
+          },
+          "name": {
+            "type": "string"
+          },
+          "title": {
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "ttlMs": {
+      "type": "integer"
+    }
+  },
+  "type": "object"
+}

First observedSep 9, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint are all true/false appropriately sums up safety. The description adds value by stating the catalog is static, costs nothing, never queues tests or consumes credits, which goes beyond what annotations provide. This is exactly the kind of behavioral transparency that helps an agent know side-effect-free it is.

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?

Three sentences, all packed with useful information: what it lists, what the entries contain, how to use the result, and the cost/static nature. No fluff. The most critical information (listing workflows and how to render them) is front-loaded.

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 a zero-parameter, read-only catalog tool, the description covers everything an agent needs: what it returns, how to act on it, and the fact it's free. The output schema likely lists the structure, so return values are covered. The description is complete for a tool of this simplicity.

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?

The tool has zero parameters, so the schema is complete. The description doesn't add param-specific semantics because there are none. It does explain what each entry in the returned list contains ('Each entry lists its arguments'), which adds context about the output beyond just the schema. Given 0 params, a baseline of 4 is appropriate, and the description meets it.

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 clearly states the tool lists GVT prompt workflows and explains what those are (user-invocable recipes that chain tools into tasks), with examples of the types of workflows. It distinguishes this from siblings like gvt_get_prompt, which renders a specific prompt. The verb 'list' and resource 'GVT prompt workflows' are specific and 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?

The description explicitly says when to use this tool: to get a catalog of workflows, and then use gvt_get_prompt to render a specific one. It also states that it costs nothing and can be called on every session start, implying it's appropriate as an initial step. It does not explicitly say when not to use it, but the routing to gvt_get_prompt is clear, and the context of siblings makes the alternative obvious.

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 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?