Skip to main content
Glama
localseodata

Local SEO Data

Official

ai_keyword_data

Read-only

Measure how often keywords are searched in ChatGPT and other LLMs. Get AI search volume and monthly trend data per keyword to guide content strategy.

Instructions

Use when measuring how often keywords are searched in ChatGPT and other LLMs. Returns ai_search_volume and monthly trend data per keyword. IMPORTANT: volumes are country-level (volume_scope: "country") regardless of the location passed — check location_used. Costs 9-16 credits, scaling with keyword count (100 keywords = 16).

Input Schema

NameRequiredDescriptionDefault
keywordsYesKeywords to get AI volume for (e.g. ["plumber near me", "emergency plumber"])
languageNoLanguage as ISO 639-1 code or name (e.g. "fr", "French"). Defaults to the language we hold AI keyword data for in that country.
locationNoLocation for results (e.g. "Miami, FL"). Default: US

Output Schema

NameRequiredDescriptionDefault
keywordsYes
languageNo
locationNo
volume_scopeNo
location_usedNo
total_keywordsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.1.0
    • addedInput schema / properties / language
      Added value: +{
      +  "description": "Language as ISO 639-1 code or name (e.g. \"fr\", \"French\"). Defaults to the language we hold AI keyword data for in that country.",
      +  "type": "string"
      +}
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "http://json-schema.org/draft-07/schema#",
      +  "additionalProperties": true,
      +  "properties": {
      +    "keywords": {
      +      "items": {
      +        "additionalProperties": true,
      +        "properties": {
      +          "ai_search_volume": {
      +            "type": "number"
      +          },
      +          "keyword": {
      +            "type": "string"
      +          },
      +          "monthly_searches": {
      +            "items": {},
      +            "type": "array"
      +          }
      +        },
      +        "required": [
      +          "keyword",
      +          "ai_search_volume",
      +          "monthly_searches"
      +        ],
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "language": {
      +      "type": "string"
      +    },
      +    "location": {
      +      "type": "string"
      +    },
      +    "location_used": {
      +      "type": "string"
      +    },
      +    "total_keywords": {
      +      "type": "number"
      +    },
      +    "volume_scope": {
      +      "enum": [
      +        "local",
      +        "country"
      +      ],
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "total_keywords",
      +    "keywords"
      +  ],
      +  "type": "object"
      +}
  2. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the readOnly/openWorld annotations by disclosing the country-level volume scope caveat, the instruction to check location_used, and a credit cost model (9-16 credits, scaling with keyword count, 100 keywords = 16). That cost and scope information is exactly the kind of behavioral detail an agent needs before calling.

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?

Four short sentences, each carrying distinct information (use case, return fields, scope caveat, cost). The use case is front-loaded and the 'IMPORTANT' marker correctly flags the one gotcha an agent could trip on.

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 an output schema present, return values don't need explanation, and the description nonetheless names the key fields. Cost, scope limitation, and default behavior are all covered, leaving nothing an agent needs in order to invoke it correctly.

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?

Schema coverage is 100%, yet the description still adds real meaning: it warns that results are country-level regardless of the location argument and points at location_used for verification, and it ties keyword count to credit cost. This is substantive guidance beyond the field descriptions.

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 and resource — measuring how often keywords are searched in ChatGPT and other LLMs — and names the return fields (ai_search_volume, monthly trend). The 'AI' qualifier implicitly separates it from the Google-oriented search_volume sibling, so an agent can pick it without opening the schema.

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?

'Use when measuring how often keywords are searched in ChatGPT and other LLMs' gives a clear triggering condition. It stops short of explicitly routing the agent away from search_volume or keyword_trends for traditional search data, so the alternative is only implied.

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