Este es el nuevo servidor MCP v3. El servidor MCP anterior v2+ está obsoleto y se encuentra en dataforseo/mcp-server-typescript-deprecated.
Servidor MCP y CLI para que agentes LLM naveguen por la documentación de la API de DataForSEO y realicen solicitudes autenticadas a la API. Por defecto, el binario inicia un servidor MCP en stdio; los comandos CLI son un segundo modo opcional.
Inicia el servidor MCP en stdio (modo predeterminado; configura DATAFORSEO_LOGIN / DATAFORSEO_PASSWORD):
npx dataforseo-mcp-server@latestTransporte HTTP (puerto 3000; sobrescribir con PORT):
npx dataforseo-mcp-server@latest --mode httpRelated MCP server: FetchSERP MCP Server
OAuth 2.0 (predeterminado para HTTP MCP): funciona de inmediato. Los clientes MCP descubren el servidor de autorización de DataForSEO a través de metadatos de Recursos Protegidos y envían tokens Authorization: Bearer.
Alternativa: credenciales de API (usuario/contraseña) mediante variables de entorno (HTTP Basic). Necesario para CLI y stdio MCP; en HTTP se usa cuando no hay un encabezado Authorization.
# bash / macOS / Linux
export DATAFORSEO_LOGIN="your_api_login"
export DATAFORSEO_PASSWORD="your_api_password"# PowerShell
$env:DATAFORSEO_LOGIN="your_api_login"
$env:DATAFORSEO_PASSWORD="your_api_password"REM CMD
set DATAFORSEO_LOGIN=your_api_login
set DATAFORSEO_PASSWORD=your_api_passwordDATAFORSEO_USERNAME se acepta como alias de DATAFORSEO_LOGIN. Obtén claves API en https://app.dataforseo.com/api-access.
Las mismas implementaciones de herramientas alimentan tanto el servidor MCP como la CLI. Un solo binario sirve para ambos modos; MCP es el predeterminado.
Cómo elige el binario el modo:
MCP stdio — predeterminado cuando no se pasa ningún comando CLI
MCP HTTP — pasa --mode http (HTTP Streamable en el puerto 3000; sobrescribir con PORT)
CLI — cuando el primer comando es docs o request, o cuando se pasa --cli / --help / --version
MCP stdio (predeterminado):
npx dataforseo-mcp-serverMCP HTTP:
npx dataforseo-mcp-server --mode httpCLI:
npx dataforseo-mcp-server docs indexConfiguración del cliente MCP (Cursor, Claude Desktop y clientes similares que usan mcpServers):
Mediante URL — usa el servidor MCP remoto alojado, o inicia un servidor HTTP local (npx dataforseo-mcp-server --mode http) y apunta el cliente hacia él. OAuth funciona de inmediato; las credenciales de entorno son solo una alternativa opcional.
Servidor MCP remoto: https://data.dataforseo.com/v3
{
"mcpServers": {
"dataforseo": {
"url": "https://data.dataforseo.com/v3/mcp"
}
}
}Servidor local (puerto predeterminado 3000):
{
"mcpServers": {
"dataforseo": {
"url": "http://localhost:3000/mcp"
}
}
}Mediante command (stdio) — el cliente inicia el binario por sí mismo (stdio es el modo predeterminado). OAuth no se usa en este transporte — configura credenciales de entorno (o pásalas en el bloque env del cliente MCP):
{
"mcpServers": {
"dataforseo": {
"command": "npx",
"args": [
"dataforseo-mcp-server",
// Optional additional args:
// "--docs-cache-dir", "D:\\my-docs-cache",
// "--configuration", "field-config.json"
],
"env": {
"DATAFORSEO_LOGIN": "your_api_login",
"DATAFORSEO_PASSWORD": "your_api_password",
// Optional additional env:
// "FIELD_CONFIG_PATH": "field-config.json"
}
}
}
}Desde la raíz del repositorio durante el desarrollo:
{
"mcpServers": {
"dataforseo": {
"command": "npx",
"args": ["tsx", "src/index.ts"],
"cwd": "/path/to/mcp-server-typescript"
}
}
}Herramienta | Título | Descripción |
| Índice de Docs | Obtiene el índice de documentación, opcionalmente filtrado por sección (caché de 24h) |
| Listar Secciones | Devuelve los nombres de las secciones de documentación disponibles |
| Buscar en Docs | Obtiene documentación desde una URL de documentación ( |
| Solicitud a la API | Realiza una solicitud autenticada a la API |
api_request usa rutas .ai por defecto (sin parámetro aiMode). El cuerpo de la solicitud se pasa como data (objeto o array JSON). Las opciones solo para CLI (--param, --no-ai-mode) no se exponen a través de MCP.
Puntos finales HTTP Streamable:
POST /mcp
POST /http
Los metadatos de Recursos Protegidos OAuth 2.0 (RFC 9728) siempre están expuestos para que los clientes MCP puedan descubrir el servidor de autorización y autenticarse con tokens Bearer:
GET /.well-known/oauth-protected-resource
GET /.well-known/oauth-protected-resource/mcp
GET /.well-known/oauth-protected-resource/http
Detrás de un proxy inverso, configura TRUST_PROXY=true para que las URLs de metadatos usen https.
Prioridad de autenticación en solicitudes HTTP:
Encabezado Authorization: Basic
Encabezado Authorization: Bearer (token de acceso OAuth)
Credenciales de entorno (DATAFORSEO_LOGIN / DATAFORSEO_PASSWORD) — alternativa cuando no se envía un encabezado Authorization
Además de MCP, el mismo binario expone docs y request como comandos CLI.
Comando | Descripción |
| Obtiene el índice completo de documentación de la API |
| Filtra el índice por sección de la API |
| Lista las secciones disponibles |
| Obtiene documentación desde una URL o ruta de documentación (solo ejemplo cURL por defecto) |
| Obtiene documentación con ejemplos en PHP, Node.js, Python y C# |
| Realiza una solicitud autenticada a la API (ruta |
Desde un clon local compilado también puedes usar npx . en lugar de npx dataforseo-mcp-server.
# Browse SERP API endpoints
npx dataforseo-mcp-server docs index --section "SERP API"
# Read endpoint documentation (path or full docs URL)
npx dataforseo-mcp-server docs search serp/google/organic/live/regular
npx dataforseo-mcp-server docs search https://docs.dataforseo.com/v3/serp/google/organic/live/regular
# Include multi-language code examples (PHP, Node.js, Python, C#)
npx dataforseo-mcp-server docs search backlinks/referring_networks/live --need-code-example
# Live SERP request (recommended: use --param)
npx dataforseo-mcp-server request -X POST -p /v3/serp/google/organic/live/regular \
--param keyword=dataforseo --param language_code=en --param location_code=2840
# Same request via JSON body
npx dataforseo-mcp-server request -X POST -p /v3/serp/google/organic/live/regular \
-d '[{"keyword":"dataforseo","location_code":2840,"language_code":"en"}]'Las respuestas de documentación se almacenan en caché durante 24 horas. Directorio de caché predeterminado:
Windows: %LOCALAPPDATA%\dataforseo-mcp-server\docs-cache
macOS: ~/Library/Caches/dataforseo-mcp-server/docs-cache
Linux: ~/.cache/dataforseo-mcp-server/docs-cache (o $XDG_CACHE_HOME)
Sobrescribir con --cache-dir <ruta> en comandos CLI docs. Para MCP, pasa --docs-cache-dir <ruta> en los args de inicio del servidor.
Las respuestas de la API se devuelven solo como cuerpo de respuesta (JSON analizado cuando sea posible). Cuando se carga una configuración de campos, las respuestas de api_request / request se recortan a los campos configurados para esa ruta de endpoint (consulta Configuración de campos).
Opcionalmente, limita qué campos se devuelven de las respuestas de la API. A diferencia del servidor MCP anterior con múltiples herramientas (claves = nombres de herramientas), este paquete asigna la configuración por ruta de endpoint de la API.
# MCP stdio (default when no CLI command is passed)
npx dataforseo-mcp-server --configuration field-config.json
# MCP HTTP
npx dataforseo-mcp-server --mode http --configuration field-config.json
# CLI
npx dataforseo-mcp-server --configuration field-config.json request -X POST -p /v3/backlinks/summary/live --param target=example.comO configura variable de entorno:
FIELD_CONFIG_PATH — ruta a un archivo JSON (Node)
FIELD_CONFIG_JSON — cadena JSON en línea (Node / Cloudflare Worker)
Ejemplo mínimo (consulta field-config.example.json para una muestra más completa):
{
"supported_fields": {
"/v3/serp/google/organic/live/advanced": ["id", "items.title", "items.url", "status_code"],
"/v3/backlinks/summary/live": ["id", "items.backlinks", "items.referring_domains", "status_code"]
}
}Comportamiento:
Los valores predeterminados integrados siempre se aplican para /v3/on_page/lighthouse/live/json (carga útil de Lighthouse reducida). La configuración personalizada se fusiona encima y puede sobrescribir cualquier ruta.
La coincidencia de ruta ignora el sufijo .ai, la barra inclinada final y el host (las URLs completas funcionan).
Si la ruta está configurada con una lista de campos no vacía → solo se conservan esos campos (se aplican a cada elemento tasks[].result[]).
Si la ruta tiene una lista de campos vacía [] → respuesta completa para esa ruta (desactiva el filtrado).
Si la ruta falta tanto en los valores predeterminados como en la configuración personalizada → respuesta completa.
Copia el ejemplo y ajústalo a los endpoints que uses:
cp field-config.example.json my-config.jsonsrc/
├── index.ts # Unified entry (MCP by default stdio; CLI if docs/request/--cli)
├── config/ # URLs, sections, auth server
├── core/
│ ├── api/ # auth, client, path, request-body
│ ├── cli/ # program, error, output
│ ├── config/ # field configuration + defaults
│ ├── docs/ # path, section, cache
│ ├── http/ # fetch
│ ├── mcp/ # startup args (--configuration, --docs-cache-dir)
│ ├── tools/ # shared CLI + MCP tool implementations
│ ├── utils/ # field filter
│ ├── env.ts
│ └── version.ts
├── mcp/
│ ├── init-mcp-server.ts
│ ├── tool-definition.ts
│ ├── auth-middleware.ts
│ ├── http-routes.ts
│ ├── index.ts # stdio transport
│ └── index-http.ts # streamable HTTP
└── worker/ # Cloudflare Worker entry (built separately)Destino | Comando | Salida | Usado por |
Node (MCP + CLI) |
|
|
|
Cloudflare Worker |
|
|
|
La ruta del Worker es build/worker/worker/... porque tsconfig.worker.json establece rootDir en src y la entrada está en src/worker/index-worker.ts.
Lee SKILL.md en este repositorio para obtener instrucciones completas para el agente.
Requiere Node.js 20+.
npm install
npm run build
# Dev (tsx, no build step)
npm run dev # MCP stdio (default)
npm run dev:mcp:http # MCP HTTP
npm run dev -- docs index --section "SERP API" # CLI
# After build
npm run start # MCP stdio (default)
npm run start:mcp:http # Streamable HTTP
npx . docs index --list-sectionsThis endpoint will provide you with the demographic breakdown (by age and gender) of keyword popularity per each specified term based on DataForSEO Trends data
| Name | Required | Description | Default |
|---|---|---|---|
| location_name | No | full name of the location optional field in format "Country" example: United Kingdom | |
| keywords | Yes | keywords the maximum number of keywords you can specify: 5 | |
| type | No | dataforseo trends type | web |
| date_from | No | starting date of the time range if you don’t specify this field, the current day and month of the preceding year will be used by default minimal value for the web type: 2004-01-01 minimal value for other types: 2008-01-01 date format: "yyyy-mm-dd" example: "2019-01-15" | |
| date_to | No | ending date of the time range if you don’t specify this field, the today’s date will be used by default date format: "yyyy-mm-dd" example: "2019-01-15" | |
| time_range | No | preset time ranges if you specify date_from or date_to parameters, this field will be ignored when setting a task | past_7_days |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool provides demographic breakdowns but doesn't mention key behavioral aspects such as rate limits, authentication requirements, data freshness, or potential costs. For a data-fetching tool with multiple parameters, this lack of operational context is a significant gap, though it doesn't contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. It directly states what the tool does ('provide demographic breakdown') and the data source ('DataForSEO Trends'), making it easy to parse. Every part of the sentence contributes essential information, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no output schema, no annotations), the description is insufficiently complete. It explains the output type but lacks details on return format (e.g., structured data, visualizations), error handling, or example usage. For a tool fetching trend data with demographic filters, more context is needed to guide effective use, especially without annotations or output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, meaning all parameters are well-documented in the schema itself. The description adds no additional parameter semantics beyond implying demographic data output. It doesn't explain how parameters like 'location_name' or 'type' affect the demographic results, so it relies entirely on the schema. This meets the baseline for high schema coverage but doesn't enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'provide you with the demographic breakdown (by age and gender) of keyword popularity per each specified term based on DataForSEO Trends data.' It specifies the verb ('provide'), resource ('demographic breakdown'), and data source ('DataForSEO Trends'), making it clear what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'kw_data_dfs_trends_explore' or 'kw_data_google_trends_explore' which might offer different types of keyword trend analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools, specify use cases (e.g., for marketing analysis vs. general search trends), or outline prerequisites. This leaves the agent with minimal context for tool selection, relying solely on the description's content without comparative or contextual cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
This endpoint will provide you with the keyword popularity data from DataForSEO Trends. You can check keyword trends for Google Search, Google News, and Google Shopping
| Name | Required | Description | Default |
|---|---|---|---|
| location_name | No | full name of the location optional field in format "Country" example: United Kingdom | |
| keywords | Yes | keywords the maximum number of keywords you can specify: 5 | |
| type | No | dataforseo trends type | web |
| date_from | No | starting date of the time range if you don’t specify this field, the current day and month of the preceding year will be used by default minimal value for the web type: 2004-01-01 minimal value for other types: 2008-01-01 date format: "yyyy-mm-dd" example: "2019-01-15" | |
| date_to | No | ending date of the time range if you don’t specify this field, the today’s date will be used by default date format: "yyyy-mm-dd" example: "2019-01-15" | |
| time_range | No | preset time ranges if you specify date_from or date_to parameters, this field will be ignored when setting a task | past_7_days |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While it mentions the data source and scope (keyword trends), it doesn't describe important behavioral aspects like rate limits, authentication requirements, pagination, error handling, or whether this is a read-only operation. The description is insufficient for a tool with 6 parameters and no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two clear sentences that state the core functionality. It's front-loaded with the main purpose and follows with additional context about data sources. No wasted words, though it could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain what the output looks like, how results are structured, or provide any context about the DataForSEO Trends service. For a data retrieval tool with multiple parameters and no output schema, more contextual information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema already documents all 6 parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it doesn't explain parameter interactions, provide usage examples, or clarify relationships between parameters like 'time_range' and 'date_from/date_to'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'provide keyword popularity data from DataForSEO Trends' with specific data sources (Google Search, News, Shopping). It uses a specific verb ('provide') and resource ('keyword popularity data'), but doesn't explicitly differentiate from sibling tools like 'kw_data_google_trends_explore' which might offer similar functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions what data sources are available (Google Search, News, Shopping), but provides no guidance on when to use this tool versus alternatives like 'kw_data_google_trends_explore' or other sibling tools. There's no mention of prerequisites, limitations, or comparative use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
This endpoint will provide you with location-specific keyword popularity data from DataForSEO Trends
| Name | Required | Description | Default |
|---|---|---|---|
| location_name | No | full name of the location optional field in format "Country" example: United Kingdom | |
| keywords | Yes | keywords the maximum number of keywords you can specify: 5 | |
| type | No | dataforseo trends type | web |
| date_from | No | starting date of the time range if you don’t specify this field, the current day and month of the preceding year will be used by default minimal value for the web type: 2004-01-01 minimal value for other types: 2008-01-01 date format: "yyyy-mm-dd" example: "2019-01-15" | |
| date_to | No | ending date of the time range if you don’t specify this field, the today’s date will be used by default date format: "yyyy-mm-dd" example: "2019-01-15" | |
| time_range | No | preset time ranges if you specify date_from or date_to parameters, this field will be ignored when setting a task | past_7_days |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but lacks behavioral details. It doesn't disclose rate limits, authentication needs, data freshness, or what 'popularity data' entails (e.g., metrics like search volume, trends). The phrase 'provide you with' is vague, and there's no mention of output format or potential errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose and avoids redundancy. Every word earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what 'keyword popularity data' includes, how results are structured, or limitations (e.g., the 5-keyword maximum is only in the schema). For a data-fetching tool with rich parameters, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 6 parameters. The description adds no additional parameter semantics beyond implying 'location-specific' relates to 'location_name'. This meets the baseline for high schema coverage but doesn't enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'provide you with location-specific keyword popularity data from DataForSEO Trends.' It specifies the verb ('provide'), resource ('keyword popularity data'), and scope ('location-specific'), though it doesn't explicitly differentiate from sibling tools like 'kw_data_dfs_trends_demography' or 'kw_data_dfs_trends_explore' beyond mentioning 'subregion interests' in the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools, prerequisites, or specific use cases. The agent must infer usage from the name and parameters alone, which is insufficient for clear decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Utility tool for kw_data_google_ads_search_volume to get list of availible locations.
| Name | Required | Description | Default |
|---|---|---|---|
| country_iso_code | Yes | ISO 3166-1 alpha-2 country code, for example: US, GB, MT | |
| location_type | No | Type of location. Possible variants: 'TV Region','Postal Code','Neighborhood','Governorate','National Park','Quarter','Canton','Airport','Okrug','Prefecture','City','Country','Province','Barrio','Sub-District','Congressional District','Municipality District','district','DMA Region','Union Territory','Territory','Colloquial Area','Autonomous Community','Borough','County','State','District','City Region','Commune','Region','Department','Division','Sub-Ward','Municipality','University' | |
| location_name | No | Name of location or it`s part. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is a 'utility tool' that 'gets list of available locations', which implies a read-only operation but doesn't disclose any behavioral traits like authentication requirements, rate limits, pagination, error handling, or what format the list returns. The description is minimal and lacks necessary operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently states the tool's purpose and its relationship to another tool. It's appropriately sized without unnecessary elaboration, though it could be slightly more specific about the resource scope to improve clarity while maintaining conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool with 3 parameters. It doesn't explain what the output looks like (e.g., list format, structure), nor does it provide behavioral context needed for proper use. The minimal description leaves significant gaps in understanding how to effectively invoke and interpret results from this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all three parameters (country_iso_code, location_type, location_name) with descriptions and constraints. The description adds no additional parameter semantics beyond what's already in the schema, meeting the baseline score of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose as getting a list of available locations, but it's vague about what kind of locations (Google Ads locations) and doesn't clearly distinguish from sibling tools like 'serp_locations' or 'serp_youtube_locations'. It mentions being a utility for 'kw_data_google_ads_search_volume', which provides some context but lacks specificity about the resource scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions this is a utility for 'kw_data_google_ads_search_volume', implying it should be used in that context, but provides no explicit guidance on when to use this tool versus alternatives like 'serp_locations' or 'serp_youtube_locations'. There's no mention of prerequisites, exclusions, or specific scenarios for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get search volume data for keywords from Google Ads
| Name | Required | Description | Default |
|---|---|---|---|
| location_name | No | full name of the location required field Location format - hierarchical, comma-separated (from most specific to least) Can be one of: 1. Country only: "United States" 2. Region,Country: "California,United States" 3. City,Region,Country: "San Francisco,California,United States" | United States |
| language_code | No | Language two-letter ISO code (e.g., 'en'). optional field | |
| keywords | Yes | Array of keywords to get search volume for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'gets' data, implying a read-only operation, but doesn't clarify if it requires authentication, has rate limits, returns real-time or historical data, or handles errors. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Get search volume data for keywords from Google Ads'. It's front-loaded with the core purpose, has zero wasted words, and is appropriately sized for a straightforward tool. Every part of the sentence contributes essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't address behavioral aspects like authentication needs, rate limits, or data freshness. For a tool that likely interacts with an external API (Google Ads) and returns search volume data, more context on limitations, response format, or error handling would be beneficial to guide the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning the input schema fully documents the parameters (location_name, language_code, keywords) with detailed descriptions. The description adds no additional semantic information beyond what's in the schema, such as explaining the relationship between parameters or typical usage patterns. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get search volume data for keywords from Google Ads'. It specifies the verb ('Get'), resource ('search volume data'), and source ('Google Ads'), making the function unambiguous. However, it doesn't differentiate from sibling tools like 'kw_data_google_trends_explore' or 'kw_data_dfs_trends_explore', which might also provide keyword-related data from different sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools, such as 'kw_data_google_trends_explore' for Google Trends data or 'kw_data_dfs_trends_demography' for demographic trends, leaving the agent without context for tool selection. There's no indication of prerequisites, limitations, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
This endpoint will provide you list of Google Trends Categories
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool provides a list, implying a read-only operation, but doesn't cover aspects like rate limits, authentication needs, error handling, or data format. For a tool with zero annotation coverage, this is a significant gap in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'This endpoint will provide you list of Google Trends Categories.' It is front-loaded with the core purpose, has zero waste, and is appropriately sized for a simple tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimal. It states what the tool does but lacks context on usage, behavioral traits, or output details. For a tool that might interact with external APIs (Google Trends), more completeness on constraints or return values would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add param info, which is appropriate. A baseline of 4 is applied as it compensates adequately for the lack of parameters without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'provide you list of Google Trends Categories.' It specifies the verb ('provide') and resource ('list of Google Trends Categories'), making the function unambiguous. However, it doesn't differentiate from sibling tools like 'kw_data_google_trends_explore,' which might also involve Google Trends data, so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It doesn't mention context, prerequisites, or exclusions, such as how it differs from 'kw_data_google_trends_explore' or other sibling tools. This leaves the agent without direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
This endpoint will provide you with the keyword popularity data from the ‘Explore’ feature of Google Trends. You can check keyword trends for Google Search, Google News, Google Images, Google Shopping, and YouTube
| Name | Required | Description | Default |
|---|---|---|---|
| location_name | No | full name of the location optional field in format "Country" example: United Kingdom | |
| language_code | No | Language two-letter ISO code (e.g., 'en'). optional field | |
| keywords | Yes | keywords the maximum number of keywords you can specify: 5 the maximum number of characters you can specify in a keyword: 100 the minimum number of characters must be greater than 1 comma characters (,) in the specified keywords will be unset and ignored Note: keywords cannot consist of a combination of the following characters: < > | " - + = ~ ! : * ( ) [ ] { } Note: to obtain google_trends_topics_list and google_trends_queries_list items, specify no more than 1 keyword | |
| type | No | google trends type | web |
| date_from | No | starting date of the time range if you don’t specify this field, the current day and month of the preceding year will be used by default minimal value for the web type: 2004-01-01 minimal value for other types: 2008-01-01 date format: "yyyy-mm-dd" example: "2019-01-15" | |
| date_to | No | ending date of the time range if you don’t specify this field, the today’s date will be used by default date format: "yyyy-mm-dd" example: "2019-01-15" | |
| time_range | No | preset time ranges if you specify date_from or date_to parameters, this field will be ignored when setting a task | past_7_days |
| item_types | No | types of items returned to speed up the execution of the request, specify one item at a time | |
| category_code | No | google trends search category you can receive the list of available categories with their category_code by making a separate request to the keywords_data_google_trends_categories tool |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it mentions the data sources, it doesn't address important behavioral aspects: whether this is a read-only operation, rate limits, authentication requirements, response format, pagination, or error conditions. For a tool with 9 parameters and no output schema, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences that directly address the tool's function and scope. The first sentence states the core purpose, and the second provides additional context about available data sources. There's no wasted language or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, no annotations, no output schema), the description is insufficient. It doesn't explain what the tool returns, how to interpret the results, or provide context about Google Trends data limitations. For a data retrieval tool with multiple configuration options and no output schema, users need more guidance about expected outputs and result interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all 9 parameters thoroughly. The description adds minimal value beyond what's in the schema - it mentions the data sources (which relates to the 'type' parameter) but doesn't provide additional context about parameter interactions, dependencies, or best practices. The baseline of 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'provide you with the keyword popularity data from the 'Explore' feature of Google Trends.' It specifies the verb ('provide'), resource ('keyword popularity data'), and source ('Google Trends Explore feature'). However, it doesn't explicitly distinguish this tool from its sibling 'kw_data_google_trends_categories' or other keyword data tools, which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions what data sources are available ('Google Search, Google News, Google Images, Google Shopping, and YouTube'), but provides no guidance on when to use this tool versus alternatives like 'kw_data_google_ads_search_volume' or 'kw_data_dfs_trends_explore'. There's no mention of prerequisites, limitations, or typical use cases for Google Trends data versus other keyword tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
This endpoint allows parsing the content on any page you specify and will return the structured content of the target page, including link URLs, anchors, headings, and textual content.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL of the page to parse | |
| enable_javascript | No | Enable JavaScript rendering | |
| custom_user_agent | No | Custom User-Agent header | |
| accept_language | No | Accept-Language header value |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool parses and returns structured content, but doesn't cover important aspects like whether it makes external HTTP requests, potential rate limits, authentication needs, error handling, or what 'structured content' entails. For a tool that interacts with external URLs, this lack of behavioral context is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently communicates the core functionality. It's appropriately sized and front-loaded with the main purpose. There's no wasted text, though it could potentially benefit from slightly more detail given the lack of annotations and output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of parsing web pages and the absence of both annotations and an output schema, the description is insufficient. It doesn't explain what 'structured content' means in practice, how results are formatted, potential limitations (e.g., JavaScript-dependent content), or error conditions. For a tool with 4 parameters and no structured output documentation, this leaves significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all four parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. It mentions parsing 'any page you specify' which aligns with the 'url' parameter, but provides no additional syntax, format, or usage details. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: parsing content from a specified page and returning structured content including links, anchors, headings, and text. It uses specific verbs ('parsing', 'return') and identifies the resource ('any page you specify'). However, it doesn't explicitly differentiate from sibling tools like 'on_page_instant_pages' or 'on_page_lighthouse', which likely have related but distinct functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools or contexts where this parsing tool is preferred over other on_page or serp tools. Usage is implied only by the general purpose, with no explicit when/when-not statements or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Using this function you will get page-specific data with detailed information on how well a particular page is optimized for organic search
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to analyze | |
| enable_javascript | No | Enable JavaScript rendering | |
| custom_js | No | Custom JavaScript code to execute | |
| custom_user_agent | No | Custom User-Agent header | |
| accept_language | No | language header for accessing the website all locale formats are supported (xx, xx-XX, xxx-XX, etc.) Note: if you do not specify this parameter, some websites may deny access; in this case, pages will be returned with the "type":"broken in the response array |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions the tool returns 'detailed information on how well a particular page is optimized for organic search,' it lacks critical behavioral details: what specific metrics or data are returned, whether this involves external API calls or rate limits, authentication requirements, error handling (beyond a hint in the 'accept_language' parameter description), or performance characteristics. For a tool with 5 parameters and no annotations, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently states the tool's purpose. It's front-loaded with the core function and avoids unnecessary words. However, given the tool's complexity (5 parameters, no output schema) and lack of sibling differentiation, it could benefit from slightly more detail to be fully helpful, keeping it from a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain what the output looks like (e.g., the structure or types of 'detailed information'), how to interpret results, or any dependencies or limitations. With no output schema and rich parameterization, the description should provide more context to guide effective use, but it falls short.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, meaning all parameters are well-documented in the input schema itself. The description adds no additional parameter information beyond what's already in the schema (e.g., it doesn't explain the 'url' format, when to use 'custom_js', or default behaviors). With high schema coverage, the baseline score is 3, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'get page-specific data with detailed information on how well a particular page is optimized for organic search.' It specifies the verb ('get'), resource ('page-specific data'), and outcome ('optimized for organic search'). However, it doesn't explicitly distinguish this tool from its many siblings (e.g., 'on_page_content_parsing', 'on_page_lighthouse'), which appear to be related on-page analysis tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With numerous sibling tools like 'on_page_content_parsing' and 'on_page_lighthouse' that likely serve similar on-page analysis purposes, the description fails to indicate what makes this tool unique or when it should be preferred over others. No context, exclusions, or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The OnPage Lighthouse API is based on Google’s open-source Lighthouse project for measuring the quality of web pages and web apps.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL of the page to parse | |
| enable_javascript | No | Enable JavaScript rendering | |
| custom_user_agent | No | Custom User-Agent header | |
| accept_language | No | Accept-Language header value |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden but fails to disclose key behavioral traits. It does not mention whether this is a read-only operation, potential rate limits, authentication needs, or what the output entails (e.g., audit results, scores, errors). The description only provides background on Lighthouse without operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently explains the tool's basis without unnecessary details. It is front-loaded with the core information, though it could be more concise by directly stating the tool's function rather than background.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool with 4 parameters and likely complex behavior (web page quality measurement). It lacks details on what the tool returns, error handling, or performance implications, leaving significant gaps for an AI agent to understand its use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters (url, enable_javascript, custom_user_agent, accept_language). The description adds no additional meaning about parameters beyond what the schema provides, such as default behaviors or usage examples. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool is 'based on Google's open-source Lighthouse project for measuring the quality of web pages and web apps,' which provides a general purpose but lacks specificity about what it actually does (e.g., run audits, generate reports, return scores). It distinguishes from some siblings like 'on_page_content_parsing' by mentioning Lighthouse, but the verb 'measuring' is vague compared to more precise alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention sibling tools like 'on_page_content_parsing' or 'on_page_instant_pages' for comparison, nor does it specify contexts or exclusions for usage. The description only gives background without practical application advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Utility tool for serp_organic_live_advanced to get list of availible locations.
| Name | Required | Description | Default |
|---|---|---|---|
| search_engine | No | search engine name, one of: google, yahoo, bing. | |
| country_iso_code | Yes | ISO 3166-1 alpha-2 country code, for example: US, GB, MT | |
| location_type | No | Type of location. Possible variants: 'TV Region','Postal Code','Neighborhood','Governorate','National Park','Quarter','Canton','Airport','Okrug','Prefecture','City','Country','Province','Barrio','Sub-District','Congressional District','Municipality District','district','DMA Region','Union Territory','Territory','Colloquial Area','Autonomous Community','Borough','County','State','District','City Region','Commune','Region','Department','Division','Sub-Ward','Municipality','University' | |
| location_name | No | Name of location or it`s part. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool 'gets list of availible locations,' which implies a read-only operation, but doesn't disclose behavioral traits such as authentication needs, rate limits, pagination, or error handling. The description is minimal and lacks essential context for safe and effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and efficient, with no wasted words. However, it contains a typo ('availible') and could be slightly more polished, but overall it's appropriately sized for its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what the output looks like (e.g., list format, data structure) or provide context on complexity. For a tool with 4 parameters and no structured output info, more detail is needed to guide the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 4 parameters with descriptions and constraints. The description adds no additional meaning beyond the schema, as it doesn't explain parameter interactions or usage examples. Baseline 3 is appropriate when schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool is a 'Utility tool for serp_organic_live_advanced to get list of availible locations.' This clarifies it fetches location data for a specific sibling tool, but the purpose is somewhat vague—it doesn't specify what 'availible locations' means (e.g., search engine locations, geographic regions). It distinguishes from most siblings by focusing on locations, but lacks specificity in verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions it's for 'serp_organic_live_advanced,' implying usage context, but provides no explicit guidance on when to use this tool versus alternatives (e.g., serp_youtube_locations or other location-related tools in the sibling list). There are no exclusions or prerequisites stated, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get organic search results for a keyword in specified search engine
| Name | Required | Description | Default |
|---|---|---|---|
| search_engine | No | search engine name, one of: google, yahoo, bing. | |
| location_name | No | full name of the location required field Location format - hierarchical, comma-separated (from most specific to least) Can be one of: 1. Country only: "United States" 2. Region,Country: "California,United States" 3. City,Region,Country: "San Francisco,California,United States" | United States |
| depth | No | parsing depth optional field number of results in SERP | |
| language_code | Yes | search engine language code (e.g., 'en') | |
| keyword | Yes | Search keyword | |
| max_crawl_pages | No | page crawl limit optional field number of search results pages to crawl max value: 100 Note: the max_crawl_pages and depth parameters complement each other | |
| device | No | device type optional field can take the values:desktop, mobile default value: desktop | desktop |
| people_also_ask_click_depth | No | clicks on the corresponding element specify the click depth on the people_also_ask element to get additional people_also_ask_element items; |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'gets' results, implying a read-only operation, but doesn't clarify if it's a live query (suggesting real-time data), potential rate limits, authentication needs, or error handling. For a tool with 8 parameters and no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Get organic search results for a keyword in specified search engine.' It's front-loaded with the core purpose, uses clear language, and avoids redundancy. Every word contributes to understanding, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, no annotations, no output schema), the description is insufficient. It doesn't explain the return format (e.g., what data is included in 'organic search results'), behavioral aspects like real-time vs. cached data, or error conditions. For a tool that likely returns rich SERP data, this leaves critical gaps for an AI agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'keyword' and 'specified search engine,' which align with two parameters, but doesn't add meaningful context beyond the schema. With 100% schema description coverage, the schema already documents all parameters thoroughly (e.g., defaults, constraints, formats). The description provides no additional semantics, such as how parameters interact (e.g., 'depth' vs. 'max_crawl_pages'), so it meets the baseline but doesn't enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get organic search results for a keyword in specified search engine.' It specifies the verb ('get'), resource ('organic search results'), and key parameters ('keyword,' 'search engine'), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like 'serp_youtube_organic_live_advanced,' which might cause confusion in tool selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or comparisons to sibling tools, such as 'serp_youtube_organic_live_advanced' for YouTube searches or other SERP-related tools. This lack of context could lead to incorrect tool selection in complex scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Utility tool to get list of available locations for: serp_youtube_organic_live_advanced, serp_youtube_video_info_live_advanced, serp_youtube_video_comments_live_advanced, serp_youtube_video_subtitles_live_advanced.
| Name | Required | Description | Default |
|---|---|---|---|
| country_iso_code | Yes | ISO 3166-1 alpha-2 country code, for example: US, GB, MT | |
| location_type | No | Type of location. Possible variants: 'TV Region','Postal Code','Neighborhood','Governorate','National Park','Quarter','Canton','Airport','Okrug','Prefecture','City','Country','Province','Barrio','Sub-District','Congressional District','Municipality District','district','DMA Region','Union Territory','Territory','Colloquial Area','Autonomous Community','Borough','County','State','District','City Region','Commune','Region','Department','Division','Sub-Ward','Municipality','University' | |
| location_name | No | Name of location or it`s part. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. While it states this is a 'utility tool' that 'gets list of available locations,' it doesn't disclose important behavioral traits like whether this is a read-only operation, what authentication might be required, rate limits, or what format the location list returns. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that clearly communicates the tool's purpose and usage context. It's appropriately sized for a utility tool and front-loads the essential information without any wasted words or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a utility tool with 3 parameters (1 required), 100% schema coverage, and no output schema, the description provides adequate context about what the tool does and which tools it supports. However, it lacks information about return format and behavioral characteristics that would be helpful given the absence of annotations. The description is complete enough for basic understanding but could be more comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters well-documented in the schema itself. The description doesn't add any parameter-specific information beyond what the schema provides. According to scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to 'get list of available locations' for specific YouTube SERP tools. It specifies the verb ('get') and resource ('list of available locations'), but doesn't distinguish it from the similar 'serp_locations' sibling tool, which appears to serve a parallel function for non-YouTube SERP tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists the four specific tools this location utility supports: 'serp_youtube_organic_live_advanced, serp_youtube_video_info_live_advanced, serp_youtube_video_comments_live_advanced, serp_youtube_video_subtitles_live_advanced.' This provides clear guidance on when to use this tool versus alternatives - specifically for YouTube-related SERP tools rather than general SERP tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
provides top 20 blocks of youtube search engine results for a keyword
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | Search keyword | |
| location_name | Yes | full name of the location required field Location format - hierarchical, comma-separated (from most specific to least) Can be one of: 1. Country only: "United States" 2. Region,Country: "California,United States" 3. City,Region,Country: "San Francisco,California,United States" | |
| language_code | Yes | search engine language code (e.g., 'en') | |
| device | No | device type optional field can take the values:desktop, mobile default value: desktop | desktop |
| os | No | device operating system optional field if you specify desktop in the device field, choose from the following values: windows, macos default value: windows if you specify mobile in the device field, choose from the following values: android, ios default value: android | windows |
| block_depth | No | parsing depth optional field number of blocks of results in SERP max value: 700 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'top 20 blocks' and implies live results, but lacks critical details: it doesn't specify if results are real-time or cached, whether there are rate limits, authentication requirements, error handling, or the structure of returned data (since no output schema exists). For a tool with 6 parameters and no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core functionality ('provides top 20 blocks of youtube search engine results for a keyword'). It wastes no words and directly communicates the tool's purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no annotations, no output schema), the description is incomplete. It lacks behavioral context (e.g., live vs. cached, rate limits), usage guidelines compared to siblings, and details on output format. While the input schema is thorough, the description alone doesn't provide enough information for an agent to fully understand how to use this tool effectively in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning all parameters are well-documented in the input schema itself. The description adds no additional parameter semantics beyond implying keyword-based search. Since the schema handles the heavy lifting, the baseline score of 3 is appropriate—the description doesn't compensate but doesn't need to given the comprehensive schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'provides top 20 blocks of youtube search engine results for a keyword.' It specifies the verb ('provides'), resource ('youtube search engine results'), and scope ('top 20 blocks'), which is specific and actionable. However, it doesn't explicitly distinguish this tool from sibling tools like 'serp_organic_live_advanced' or 'serp_youtube_video_info_live_advanced', which might offer similar or overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or comparisons with sibling tools (e.g., 'serp_organic_live_advanced' for general SERP or other YouTube-specific tools). Without such context, an agent must infer usage based on the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
provides data on the video comments you specify
| Name | Required | Description | Default |
|---|---|---|---|
| video_id | Yes | ID of the video | |
| location_name | Yes | full name of the location required field Location format - hierarchical, comma-separated (from most specific to least) Can be one of: 1. Country only: "United States" 2. Region,Country: "California,United States" 3. City,Region,Country: "San Francisco,California,United States" | |
| language_code | Yes | search engine language code (e.g., 'en') | |
| device | No | device type optional field can take the values:desktop, mobile default value: desktop | desktop |
| os | No | device operating system optional field if you specify desktop in the device field, choose from the following values: windows, macos default value: windows if you specify mobile in the device field, choose from the following values: android, ios default value: android | windows |
| depth | No | parsing depth, number of results in SERP, max value: 700 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It fails to do so—it doesn't indicate whether this is a read-only or mutating operation, what permissions might be required, rate limits, or what the output format looks like (e.g., JSON structure, pagination). The term 'provides data' is too generic, offering no insight into the tool's behavior beyond the basic action implied by the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence ('provides data on the video comments you specify'), which is concise but under-specified—it lacks necessary detail to be truly helpful. While it avoids verbosity, it doesn't front-load critical information or structure content effectively, leaving the agent with insufficient context. It's not wasteful, but it's too minimal to earn a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what the tool returns (e.g., comment data format, error handling), behavioral aspects, or usage context. While the schema covers parameters well, the description fails to provide a holistic understanding, making it inadequate for a tool that likely involves data retrieval from an external service like YouTube SERP.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, meaning all parameters are well-documented in the schema itself (e.g., 'video_id', 'location_name' with format details, 'depth' with max value). The description adds no additional semantic context beyond what's in the schema, such as explaining why these parameters matter or how they affect the results. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, but the description doesn't compensate or enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'provides data on the video comments you specify' is vague and tautological—it essentially restates the tool name 'serp_youtube_video_comments_live_advanced' without specifying what kind of data (e.g., comment text, metadata, sentiment) or how it's retrieved. It lacks a clear verb-resource distinction and doesn't differentiate from sibling tools like 'serp_youtube_video_info_live_advanced' or 'serp_youtube_video_subtitles_live_advanced', which could also provide video-related data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context for use (e.g., for SEO analysis, sentiment tracking), or exclusions. Given the many sibling tools (e.g., 'serp_youtube_organic_live_advanced', 'serp_youtube_video_info_live_advanced'), the absence of comparative guidance is a significant gap, leaving the agent to guess based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
provides data on the video you specify
| Name | Required | Description | Default |
|---|---|---|---|
| video_id | Yes | ID of the video | |
| location_name | Yes | full name of the location required field Location format - hierarchical, comma-separated (from most specific to least) Can be one of: 1. Country only: "United States" 2. Region,Country: "California,United States" 3. City,Region,Country: "San Francisco,California,United States" | |
| language_code | Yes | search engine language code (e.g., 'en') | |
| device | No | device type optional field can take the values:desktop, mobile default value: desktop | desktop |
| os | No | device operating system optional field if you specify desktop in the device field, choose from the following values: windows, macos default value: windows if you specify mobile in the device field, choose from the following values: android, ios default value: android | windows |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states it 'provides data' without specifying if it's a read-only operation, requires authentication, has rate limits, or what the output format might be. This leaves critical behavioral aspects undefined, failing to compensate for the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
While concise with a single sentence, it is under-specified rather than efficiently structured. The description fails to front-load essential information (e.g., what data, from where) and wastes its brevity on a vague statement that doesn't help the agent understand the tool's purpose or usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, no annotations, no output schema), the description is incomplete. It lacks details on the tool's behavior, output format, and differentiation from siblings. Without annotations or output schema, the description should provide more context to guide the agent effectively, but it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (video_id, location_name, etc.) with detailed descriptions. The description adds no additional meaning beyond the schema, such as explaining why these parameters are needed or how they affect results, but the high schema coverage justifies a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'provides data on the video you specify' is vague and tautological—it essentially restates the tool name without specifying what type of data (e.g., metadata, analytics, rankings) or from what source (e.g., YouTube SERP). It fails to distinguish this tool from sibling tools like 'serp_youtube_organic_live_advanced' or 'serp_youtube_video_comments_live_advanced', leaving the agent unclear about its unique function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools (e.g., 'serp_youtube_organic_live_advanced', 'serp_youtube_video_comments_live_advanced'), there is no indication of context, prerequisites, or exclusions, making it impossible for an agent to choose appropriately without external knowledge.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
provides data on the video subtitles you specify
| Name | Required | Description | Default |
|---|---|---|---|
| video_id | Yes | ID of the video | |
| location_name | Yes | full name of the location required field Location format - hierarchical, comma-separated (from most specific to least) Can be one of: 1. Country only: "United States" 2. Region,Country: "California,United States" 3. City,Region,Country: "San Francisco,California,United States" | |
| language_code | Yes | search engine language code (e.g., 'en') | |
| subtitles_language | No | language code of original text (e.g., 'en') | |
| subtitles_translate_language | No | language code of translated text (e.g., 'en') | |
| device | No | device type optional field can take the values:desktop, mobile default value: desktop | desktop |
| os | No | device operating system optional field if you specify desktop in the device field, choose from the following values: windows, macos default value: windows if you specify mobile in the device field, choose from the following values: android, ios default value: android | windows |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but fails to disclose any behavioral traits. It doesn't mention whether this is a read-only operation, if it requires authentication, rate limits, or what the output looks like (e.g., structured data, raw text). The phrase 'provides data' is too generic to infer behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
While concise (one sentence), the description is under-specified and fails to front-load critical information. It doesn't earn its place by adding value; instead, it's overly brief for a complex tool, making it inefficient for agent understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no annotations, no output schema), the description is severely incomplete. It doesn't explain the tool's purpose, usage, behavior, or output, leaving major gaps that hinder effective agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 7 parameters with detailed descriptions and constraints. The description adds no additional meaning beyond the schema, but since coverage is high, the baseline score of 3 applies—adequate but no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'provides data on the video subtitles you specify' is vague and tautological—it essentially restates the tool name without specifying what kind of data (e.g., transcript text, timing, availability) or how it's retrieved. It lacks a clear verb-resource combination and doesn't distinguish from sibling tools like 'serp_youtube_video_info_live_advanced' or 'serp_youtube_organic_live_advanced'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description offers no context, prerequisites, or exclusions, leaving the agent to guess based on parameters alone. This is inadequate for a tool with 7 parameters and no annotations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.2kw_data_dfs_trends_demographykw_data_dfs_trends_explorekw_data_dfs_trends_subregion_interestskw_data_google_ads_locationskw_data_google_ads_search_volumekw_data_google_trends_categorieskw_data_google_trends_exploreon_page_content_parsingon_page_instant_pageson_page_lighthouseserp_locationsserp_organic_live_advancedserp_youtube_locationsserp_youtube_organic_live_advancedserp_youtube_video_comments_live_advancedserp_youtube_video_info_live_advancedserp_youtube_video_subtitles_live_advancedv1.0.0kw_data_dfs_trends_demographykw_data_dfs_trends_explorekw_data_dfs_trends_subregion_interestskw_data_google_ads_locationskw_data_google_ads_search_volumekw_data_google_trends_categorieskw_data_google_trends_exploreon_page_content_parsingon_page_instant_pageson_page_lighthouseserp_locationsserp_organic_live_advancedserp_youtube_locationsserp_youtube_organic_live_advancedserp_youtube_video_comments_live_advancedserp_youtube_video_info_live_advancedserp_youtube_video_subtitles_live_advancedv1.0.1keywords_data_dataforseo_trends_demographykeywords_data_dataforseo_trends_explorekeywords_data_dataforseo_trends_subregion_interestskeywords_data_google_ads_search_volumekeywords_data_google_trends_categorieskeywords_data_google_trends_explorekw_data_dfs_trends_demographykw_data_dfs_trends_explorekw_data_dfs_trends_subregion_interestskw_data_google_ads_locationskw_data_google_ads_search_volumekw_data_google_trends_categorieskw_data_google_trends_exploreon_page_content_parsing1 field changedInput schema / properties / custom_jsRemoved value: -{
- "description": "Custom JavaScript code to execute",
- "type": "string"
-}on_page_lighthouse1 field changedInput schema / properties / custom_jsRemoved value: -{
- "description": "Custom JavaScript code to execute",
- "type": "string"
-}ai_optimization_keyword_data_locations_and_languagesai_optimization_keyword_data_search_volumebacklinks_anchorsbacklinks_available_filtersbacklinks_backlinksbacklinks_bulk_backlinksbacklinks_bulk_new_lost_backlinksbacklinks_bulk_new_lost_referring_domainsbacklinks_bulk_pages_summarybacklinks_bulk_ranksbacklinks_bulk_referring_domainsbacklinks_bulk_spam_scorebacklinks_competitorsbacklinks_domain_intersectionbacklinks_domain_pagesbacklinks_domain_pages_summarybacklinks_page_intersectionbacklinks_referring_domainsbacklinks_referring_networksbacklinks_summarybacklinks_timeseries_new_lost_summarybacklinks_timeseries_summarybusiness_data_business_listings_searchcontent_analysis_phrase_trendscontent_analysis_searchcontent_analysis_summarydataforseo_labs_available_filtersdataforseo_labs_bulk_keyword_difficultydataforseo_labs_bulk_traffic_estimationdataforseo_labs_google_competitors_domaindataforseo_labs_google_domain_intersectiondataforseo_labs_google_domain_rank_overviewdataforseo_labs_google_historical_keyword_datadataforseo_labs_google_historical_rank_overviewdataforseo_labs_google_historical_serpdataforseo_labs_google_keyword_ideasdataforseo_labs_google_keyword_overviewdataforseo_labs_google_keyword_suggestionsdataforseo_labs_google_keywords_for_sitedataforseo_labs_google_page_intersectiondataforseo_labs_google_ranked_keywordsdataforseo_labs_google_related_keywordsdataforseo_labs_google_serp_competitorsdataforseo_labs_google_subdomainsdataforseo_labs_google_top_searchesdataforseo_labs_search_intentdomain_analytics_technologies_available_filtersdomain_analytics_technologies_domain_technologiesdomain_analytics_whois_available_filtersdomain_analytics_whois_overviewkeywords_data_google_trends_categories1 field changedInput schema / additionalPropertiesRemoved value: -falseon_page_lighthouseai_optimization_keyword_data_locations_and_languagesai_optimization_keyword_data_search_volumebacklinks_anchorsbacklinks_available_filtersbacklinks_backlinksbacklinks_bulk_backlinksbacklinks_bulk_new_lost_backlinksbacklinks_bulk_new_lost_referring_domainsbacklinks_bulk_pages_summarybacklinks_bulk_ranksbacklinks_bulk_referring_domainsbacklinks_bulk_spam_scorebacklinks_competitorsbacklinks_domain_intersectionbacklinks_domain_pagesbacklinks_domain_pages_summarybacklinks_page_intersectionbacklinks_referring_domainsbacklinks_referring_networksbacklinks_summarybacklinks_timeseries_new_lost_summarybacklinks_timeseries_summarybusiness_data_business_listings_searchcontent_analysis_phrase_trendscontent_analysis_searchcontent_analysis_summarydataforseo_labs_available_filtersdataforseo_labs_bulk_keyword_difficultydataforseo_labs_bulk_traffic_estimationdataforseo_labs_google_competitors_domaindataforseo_labs_google_domain_intersectiondataforseo_labs_google_domain_rank_overviewdataforseo_labs_google_historical_keyword_datadataforseo_labs_google_historical_rank_overviewdataforseo_labs_google_historical_serpdataforseo_labs_google_keyword_ideasdataforseo_labs_google_keyword_overviewdataforseo_labs_google_keyword_suggestionsdataforseo_labs_google_keywords_for_sitedataforseo_labs_google_page_intersectiondataforseo_labs_google_ranked_keywordsdataforseo_labs_google_related_keywordsdataforseo_labs_google_serp_competitorsdataforseo_labs_google_subdomainsdataforseo_labs_google_top_searchesdataforseo_labs_search_intentdomain_analytics_technologies_available_filtersdomain_analytics_technologies_domain_technologiesdomain_analytics_whois_available_filtersdomain_analytics_whois_overviewkeywords_data_dataforseo_trends_demographykeywords_data_dataforseo_trends_explorekeywords_data_dataforseo_trends_subregion_interestskeywords_data_google_ads_search_volumekeywords_data_google_trends_categorieskeywords_data_google_trends_exploreon_page_content_parsingon_page_instant_pagesserp_locationsserp_organic_live_advancedserp_youtube_locationsserp_youtube_organic_live_advancedserp_youtube_video_comments_live_advancedserp_youtube_video_info_live_advancedserp_youtube_video_subtitles_live_advancedScored across 17 tools
Most tools have distinct purposes across keyword data, on-page analysis, and SERP categories, with clear separation between Google Ads, Google Trends, and YouTube-specific tools. However, some overlap exists between kw_data_dfs_trends_explore and kw_data_google_trends_explore, both providing keyword popularity data from different sources, which could cause minor confusion.
The naming follows a consistent snake_case pattern with clear prefixes (kw_data_, on_page_, serp_) that group related tools logically. Minor inconsistencies include variations like 'availible' vs 'available' in descriptions and some utility tools having simpler names (e.g., serp_locations), but the overall structure is predictable and readable.
With 17 tools, the count is slightly high but reasonable for a comprehensive SEO data server covering keyword trends, on-page analysis, and SERP data across multiple platforms. It avoids being overwhelming by grouping tools into clear categories, though it borders on the upper limit of typical scoping.
The toolset provides thorough coverage for SEO analysis, including keyword research (volume, trends, demographics), on-page optimization (content parsing, Lighthouse metrics), and SERP data (organic results, YouTube video details, comments, subtitles). Utility tools for locations ensure no dead ends, and the surface supports end-to-end workflows without obvious gaps.
Live SEO workflow tools for Claude Code, Codex, and AI agents.
SEO MCP server for keyword research, SERP analysis, audits, and Search Console workflows.
Remote MCP server that gives Claude, ChatGPT, Cursor or any MCP client Google search volume, CPC, competition and similar keywords for 50+ countries. Works with no signup at 20 lookups a day; sign in with OAuth or an API key for higher limits, or $4.99 a month for unlimited.
Audit, rank-track and analyze SEO for sites via an authenticated MCP server.
