Skip to main content
Glama

iGods GEO Visibility Tool (GVT)

by com.igods
OverviewDiscussionsAdmin

Read a fix record

gvt_get_fix
Read-onlyIdempotent

Read the canonical fix record for one GVT issue type: severity range, impact, scoring weight, plain-language description, and the recommended remediation. Issue IDs come from the fixId field on issues in gvt_get_test_results output. The same content is served as the gvt://knowledge/fixes/{issue_id} resource template for resource-capable clients. Copy fixId verbatim from the results output — unknown or mistyped IDs return not-found rather than a fuzzy match. Responses are static reference content and cacheable.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
issue_idYesStable issue identifier, e.g. og_title_missing or color-contrast. Matches the fixId field in gvt_get_test_results output.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
ttlMsNoSuggested client cache lifetime in milliseconds
impactNoPlain-language statement of what the issue costs
weightNoScoring weight
categoryNoAnalysis category the issue belongs to
issue_idNoStable issue identifier, e.g. og_title_missing
resourceUriNoThe gvt:// resource this record was read from
subcategoryNoFiner-grained grouping within the category
recommendationNoThe recommended remediation
severity_rangeNoSeverity levels this issue can take
human_descriptionNoHuman-readable description of the issue

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changed
    • addedOutput schema / properties / category / description
      Added value: +"Analysis category the issue belongs to"
    • addedOutput schema / properties / human_description / description
      Added value: +"Human-readable description of the issue"
    • addedOutput schema / properties / impact / description
      Added value: +"Plain-language statement of what the issue costs"
    • addedOutput schema / properties / issue_id / description
      Added value: +"Stable issue identifier, e.g. og_title_missing"
    • addedOutput schema / properties / recommendation / description
      Added value: +"The recommended remediation"
    • addedOutput schema / properties / resourceUri / description
      Added value: +"The gvt:// resource this record was read from"
    • addedOutput schema / properties / severity_range / description
      Added value: +"Severity levels this issue can take"
    • addedOutput schema / properties / subcategory / description
      Added value: +"Finer-grained grouping within the category"
    • addedOutput schema / properties / ttlMs / description
      Added value: +"Suggested client cache lifetime in milliseconds"
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "description": "Canonical fix record for one issue type",
+  "properties": {
+    "category": {
+      "type": "string"
+    },
+    "human_description": {
+      "type": "string"
+    },
+    "impact": {
+      "type": "string"
+    },
+    "issue_id": {
+      "type": "string"
+    },
+    "recommendation": {
+      "type": "string"
+    },
+    "resourceUri": {
+      "type": "string"
+    },
+    "severity_range": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "subcategory": {
+      "type": "string"
+    },
+    "ttlMs": {
+      "type": "integer"
+    },
+    "weight": {
+      "description": "Scoring weight",
+      "type": "number"
+    }
+  },
+  "type": "object"
+}
  3. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds meaningful behavioral detail beyond annotations: responses are static reference content, cacheable, and lookups are exact-match only with no fuzzy fallback. This materially informs the agent's invocation and caching expectations.

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 compact and front-loaded: the primary purpose and content list appear first, followed by ID provenance, resource-template equivalence, exact-match warning, and cacheability. Each sentence contributes distinct operational value with no filler or redundancy.

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?

With one well-documented parameter, an output schema present, and annotations covering safety, the description is complete for selection and invocation. It explains where the ID comes from, how to handle it, and the response characteristics, leaving no critical 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%, with issue_id already documented as a stable identifier matching the fixId field. The description adds extra operational semantics beyond the schema: 'Copy fixId verbatim from the results output' and the not-found behavior for unknown or mistyped IDs. This enriches the parameter's meaning beyond the schema baseline.

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: 'Read the canonical fix record for one GVT issue type,' and enumerates the record's contents (severity range, impact, scoring weight, plain-language description, recommended remediation). This makes the tool's function unmistakable and distinct from generic knowledge or list tools among siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear usage context: issue IDs come from the fixId field in gvt_get_test_results outputcars, and IDs must be copied verbatim because unknown or mistyped IDs return not-found. It does not explicitly name alternative tools or state when not to use this tool, but the guidance is sufficient for an agent to invoke it correctly.

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