Un servidor alojado del Model Context Protocol (MCP) que ofrece a Claude, Cursor, Windsurf y a cualquier otro cliente MCP ocho herramientas de Google Search de solo lectura. Obtén la SEp en vivo con su AI Overview y People Also Ask, ejecuta una consulta de Google AI Mode y lee resultados de noticias, compras, fichas de producto y vídeos cortos, todo como JSON estructurado, sin proyecto de Google Cloud y sin configuración de buscador.
https://mcp.hasdata.com/api/mcp?apis=google_serp
"SEp" y "Google Search" son el mismo producto aquí. Este servidor devuelve páginas de resultados del moto de búsqueda de Google, procesadas.
Related MCP server: DuckDuckGo MCP Server
Un cliente MCP que hable HTTP streamable con cabeceras personalizadas. Una clave de API de HasData desde el panel de control, que puedes crear gratis y sin tarjeta, y la prueba cubre entre 100 y 200 llamadas según la herramienta. Nada más. Este es un servidor remoto, así que el camino más simple es una URL y una cabecera, sin proyecto de Google Cloud ni Programmable Search Engine que configurar. Un cliente solo stdio puede usar el lanzador @hasdata/google-search-mcp (npm) o hasdata-google-search-mcp (PyPI) en su lugar.
URL |
|
Transporte | HTTP, streamable |
Cabecera de autenticación |
|
La URL del servidor es la misma para todos los clientes. Lo usamos directamente en Claude Code y Claude Desktop. Los demás bloques siguen el formato documentado de cada cliente para un servidor remoto.
Los clientes con soporte de OAuth pueden añadir la misma URL como conector e iniciar sesión sin poner una clave en un archivo de configuración.
claude mcp add --transport http google-search "https://mcp.hasdata.com/api/mcp?apis=google_serp" \
--header "x-api-key: HASDATA_API_KEY"Claude Desktop carga solo servidores locales (stdio) desde su archivo de configuración, así que accede a un servidor remoto mediante un lanzador stdio. El paquete @hasdata/google-search-mcp es ese lanzador, y lee la clave del entorno.
claude_desktop_config.json:
{
"mcpServers": {
"google-search": {
"command": "npx",
"args": ["-y", "@hasdata/google-search-mcp"],
"env": { "HASDATA_API_KEY": "YOUR_KEY" }
}
}
}¿Python en lugar de Node? Cambia el lanzador por el paquete de PyPI, que uvx ejecuta sin instalación manual:
{
"mcpServers": {
"google-search": {
"command": "uvx",
"args": ["hasdata-google-search-mcp"],
"env": { "HASDATA_API_KEY": "YOUR_KEY" }
}
}
}Un cliente con soporte de OAuth puede, en su lugar, añadir la URL como conector personalizado y omitir el lanzador.
.cursor/mcp.json:
{
"mcpServers": {
"google-search": {
"url": "https://mcp.hasdata.com/api/mcp?apis=google_serp",
"headers": { "x-api-key": "HASDATA_API_KEY" }
}
}
}~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"google-search": {
"serverUrl": "https://mcp.hasdata.com/api/mcp?apis=google_serp",
"headers": { "x-api-key": "HASDATA_API_KEY" }
}
}
}{
"mcpServers": {
"google-search": {
"url": "https://mcp.hasdata.com/api/mcp?apis=google_serp",
"type": "streamableHttp",
"headers": { "x-api-key": "HASDATA_API_KEY" },
"disabled": false
}
}
}.vscode/mcp.json:
{
"servers": {
"google-search": {
"type": "http",
"url": "https://mcp.hasdata.com/api/mcp?apis=google_serp",
"headers": { "x-api-key": "HASDATA_API_KEY" }
}
}
}~/.gemini/settings.json:
{
"mcpServers": {
"google-search": {
"httpUrl": "https://mcp.hasdata.com/api/mcp?apis=google_serp",
"headers": { "x-api-key": "HASDATA_API_KEY" }
}
}
}Busca en Google
best running shoesy dame el top diez orgánico más la AI Overview.
Una llamada, 10 créditos. La respuesta SERP trae la AI Overview en línea junto a los resultados orgánicos.
Para la misma consulta, toma cada pregunta de People Also Ask y obtén su respuesta de AI Overview con las fuentes.
Una llamada por pregunta, 5 cráditos cada una. Cada entrada relatedQuestions contiene un aiOverview.pageToken, y la herramienta AI Overview conviierte ese token en los bloques de respuesta y sus referencias.
Pregunta a Google AI Mode
what is the Model Context Protocoly dame la respuesta con sus citas.
Una llamada, 10 cráditos. AI Mode devuelve la respuesta generada como bloques de texto con una lista de referencias.
Busca en Google Shopping
nike air max, luego extrae la ficha de producto completa del primer resultado: cada tienda que lo vende, el rango de precios y el desglose de reseñas.
Dos llamadas. Shopping cuesta 10 cráditos y devuelve un token por producto, y la herramienta de producto inmersivo gasta 5 para expandir ese token en tiendas, variantes y reseñas.
Obtén las últimas noticias de Google News para
artificial intelligencey, por separado, los resultados de vídeos cortos paracooking pasta.
Dos llamadas, 10 cráditos cada una.
El flujo de trabajo se apoya en dos cadenas. Una respuesta SERP devuelve un aiOverview en línea y un pageToken en cada pregunta de People Also Ask, por lo que extraer las respuestas generativas de Google es o bien gratis con la búsqueda o bien una llamada de seguimiento de 5 cráditos por pregunta. Un resultado de shopping iguamente devuelve un token por producto, así que el salto de un listado a su ficha completa de varias tiendas es una sola llamada.
Ocho herramientas, todas de solo lectura. Las muestras de abajo están recortadas de llamadas reales, y los resultados cambian a medida que cambia Google, así que tómalas como representativas de la forma. Cada nombre de herramienta enlaza a su referencia de endpoint.
Las muestras son la carga útil, no la respuesta completa. Un resultado de tools/call contiene un bloque de texto, y ese texto es en sí mismo JSON con url, status, text y json, con los datos extraídos bajo json. Desde una respuesta JSON-RPC sin procesar, la ruta es result.content[0].text, una vez parseado, y después .json. Un cliente de chat lo desempaqueta por ti, y el código que habla directamente con el endpoint no lo hace.
hasdata_google_serp_serp_getSearchResults
La página de resultados completa para una consulta.
Parámetro | Tipo | Obligatorio | Notas |
| string | sí | La consulta de búsqueda, exactamente como la escribiría un usuario |
| string | Códigos de país e idioma de dos letras | |
| string | Ubicación geográfica de la búsqueda, por nombre o como una cadena | |
| number | Número aproximado de resultados por página. Google ahora limita una página a unos diez e ignora cualquier valor superior, así que | |
| number | Desplazamiento de resultados para paginar | |
| string | Tipo de búsqueda y filtros avanzados, los parámetros de Google en bruto | |
| string |
|
Devuelve searchInformation, organicResults, aiOverview, relatedQuestions, relatedSearches, perspectives, immersiveProducts y pagination, con los bloques que Google muestre para la consulta. Las entradas orgánicas incluyen position, title, link, displayedLink, source, snippet, snippetHighlitedWords, date e images.
La AI Overview llega de dos maneras. Normalmente
aiOverviewestá integrada, contextBlocksyreferencesque puedes leer directamente. A veces Google la protege tras un token, y entoncesaiOverviewcontiene unpageTokeny unhasdataLinken lugar de los bloques. Cada entradarelatedQuestionses también ese segundo caso. Contiene unquestiony unaiOverviewcon el mismopageTokenyhasdataLink, que la herramienta AI Overview de más abajo expande. Así que las respuestas de People Also Ask son AI Overviews que obtienes token a token. LaaiOverviewde nivel superior está integrada en la mayoría de las consultas y es un token en unas pocas, así que léela de ambas maneras.
{
"organicResults": [
{
"position": 1,
"title": "The 15 Best Running Shoes of 2026",
"link": "https://www.runnersworld.com/gear/a19663621/best-running-shoes/",
"source": "Runner's World",
"snippet": "The Brooks Ghost is our No. 1 shoe when we recommend new trainers…"
}
],
"aiOverview": {
"textBlocks": [ { "type": "paragraph", "snippet": "The best running shoes depend on your goal…" } ],
"references": [ { "index": 0, "title": "7 Best Running Shoes in 2026 - RunRepeat", "link": "https://runrepeat.com/guides/best-running-shoes" } ]
},
"relatedQuestions": [
{ "question": "What are the top 5 best running shoes?", "aiOverview": { "pageToken": "eyJpZCI6…", "hasdataLink": "https://api.hasdata.com/scrape/google/ai-overview?pageToken=eyJpZCI6…" } }
],
"pagination": { "next": "…" }
}hasdata_google_serp_ai_overview_getAiOverviewResponse
Expande un token de AI Overview en su respuesta.
Parámetro | Tipo | Obligatorio | Notas |
| string | sí | Un |
Devuelve aiOverview con textBlocks y references. Así es como se lee la AI Overview cuando la SERP te ha dado un token en lugar de los bloques, y como conviertes cada pregunta de People Also Ask en una respuesta citada.
Los tokens son válidos durante unos 4 minutos. Uno caducado no vuelve vacío, sino que falla como error de herramienta,
isError: truecon el textoHasData API error: 400 Bad Request. Trátalo como tratarías una clave incorrecta y vuelve a ejecutar la SERP para obtener un token nuevo.
{
"aiOverview": {
"textBlocks": [ { "type": "paragraph", "snippet": "The top five running shoes feature versatile options for daily training and racing…" } ],
"references": [ { "index": 0, "title": "…", "link": "https://…" } ]
}
}hasdata_google_serp_ai_mode_getAiModeResponse
La respuesta del AI Mode de Google para una consulta, el resultado de búsqueda conversacional.
Parámetro | Tipo | Obligatorio | Notas |
| string | sí | La pregunta que se le hace a AI Mode |
| string | Códigos de país e idioma | |
| string | Ubicación geográfica | |
| boolean | Establécelo en true para que la respuesta se pueda continuar en una llamada de seguimiento | |
| string | Token de una respuesta anterior de AI Mode, para continuar el hilo |
Devuelve textBlocks y references, la respuesta generada y las fuentes que cita.
hasdata_google_serp_serp_light_getSearchResults
Una búsqueda más económica que devuelve lo esencial de la página.
Parámetro | Tipo | Obligatorio | Notas |
| string | sí | La consulta de búsqueda |
| string | Códigos de país e idioma | |
| string | Ubicación geográfica | |
| number | Tamaño de página y desplazamiento |
Devuelve organicResults, aiOverview, relatedSearches, filters, appliedLocation, searchInformation y pagination. Cuesta la mitad de créditos que el SERP completo, para cuando quieres los resultados orgánicos y el AI Overview sin los bloques adicionales.
hasdata_google_serp_news_getGoogleNews
Los resultados de Google News para una consulta o una sección de noticias.
Parámetro | Tipo | Obligatorio | Notas |
| string | Una consulta. Omítela para leer una sección en su lugar | |
| string | Códigos de país e idioma | |
| string | Profundiza en un tema, sección, noticia o publicación usando un token de una respuesta anterior |
Devuelve newsResults, menuLinks, relatedTopics y relatedPublications. Cada entrada de noticias incluye position, title, link, source con un name y un icon, thumbnail y date.
hasdata_google_serp_shopping_getSearchResults
Resultados de compra para una consulta.
Parámetro | Tipo | Obligatorio | Notas |
| string | sí | La consulta de producto |
| string | Códigos de país e idioma | |
| string | Ubicación geográfica | |
| number | Desplazamiento de resultados para paginar | |
| string | Filtros avanzados de compra, el parámetro de Google sin procesar |
Devuelve shoppingResults, filters, refineSearchFilters, searchInformation y pagination. Cada resultado incluye position, title, productId, price, extractedPrice, rating, reviews, source, category, thumbnail y un immersiveProductPageToken.
immersiveProductPageTokenes la entrada de la herramienta de producto inmersivo que aparece a continuación. Es un token temporal, así que expándelo mientras esté reciente si quieres los datos del producto, y vuelve a ejecutar la llamada de compra para obtener uno nuevo si un token antiguo falla.
{
"shoppingResults": [
{
"position": 1,
"title": "Men's Nike Alphafly 3",
"productId": "13366226642799457284",
"price": "$285.00",
"extractedPrice": 285,
"rating": 4.5,
"reviews": 120,
"source": "Nike",
"immersiveProductPageToken": "eyJyZHMiOiJQQ18…"
}
]
}hasdata_google_serp_immersive_product_getImmersive_e29f691177
La tarjeta de producto completa que hay detrás de un resultado de compra.
Parámetro | Tipo | Obligatorio | Notas |
| string | sí | El |
| boolean | Solicitar más tiendas | |
| string | Recorre la lista de tiendas usando |
Devuelve un objeto productResults con title, brand, rating, reviews, priceRange, un array stores con cada vendedor y su precio y enlace, además de variants, reviewsImages, userReviews, topInsights, aboutTheProduct y discussionsAndForums. Esta es la única llamada que convierte un único listado en el panorama completo de todas las tiendas.
{
"productResults": {
"title": "Men's Nike Alphafly 3",
"brand": "Nike",
"rating": 4.4,
"reviews": 1077,
"priceRange": "$221-$295",
"stores": [ { "name": "eBay", "link": "https://www.ebay.com/itm/…", "price": "$221" } ],
"storesNextPageToken": "Mw=="
}
}Vuelve a pasar storesNextPageToken como parámetro nextPageToken para recorrer las tiendas.
hasdata_google_serp_short_videos_getShortVideosSearchResults
Los resultados de vídeos cortos que Google muestra para una consulta.
Parámetro | Tipo | Obligatorio | Notas |
| string | sí | La consulta |
| string | Códigos de país, idioma y región de contenido | |
| array | Una o más restricciones de idioma | |
| number | Página de resultados | |
| string |
|
Devuelve shortVideos, cada uno con position, title, link, source, sourceLogo, profileName, duration, clip y thumbnail.
Tu cliente casi nunca ve un código de error HTTP en una llamada de herramienta. La capa MCP responde con 200 y pone el fallo dentro del resultado, con isError establecido en true y el motivo como texto. El agente lee un mensaje donde cabría esperar una línea de estado.
Una clave incorrecta aparece como salida de herramienta, no como una conexión fallida. El listado de herramientas acepta cualquier clave no vacía, y el cliente completa el protocolo de enlace y se pone en verde. La primera llamada de herramienta devuelve entonces isError: true y el texto HasData API error: 401 Unauthorized. Vigila esa cadena, porque nada antes en el flujo informa del problema.
El único error HTTP real es una clave ausente. La autorización se ejecuta antes de cualquier herramienta, y la propia conexión falla con 401.
Un argumento que rompe el esquema se rechaza antes de convertirse en una búsqueda. Una búsqueda sin q devuelve isError: true y el texto MCP error -32602: Input validation error, nombrando el campo. No se obtiene nada y no se cobra nada.
Un token de AI Overview obsoleto falla como error. Un token de respuesta del SERP es válido durante unos 4 minutos. Expandir uno que guardaste antes devuelve isError: true y el texto HasData API error: 400 Bad Request, con la misma forma que una clave incorrecta. Detéctalo y vuelve a ejecutar el SERP para obtener un token nuevo.
Un bloque que Google no mostró está ausente, no vacío. Una consulta sin AI Overview, sin panel de compras o sin People Also Ask devuelve una respuesta sin esas claves, en lugar de con claves vacías. Comprueba la clave antes de leerla.
Los resultados que contienen datos también contienen un requestMetadata.id que conviene citar al contactar con soporte, además de enlaces html y json al artefacto almacenado de esa llamada concreta.
Los créditos son por herramienta. El SERP completo, AI Mode, News, Shopping y los vídeos cortos cuestan 10 créditos por llamada. SERP Light, el producto inmersivo y la herramienta de AI Overview cuestan 5. El AI Overview que viene integrado en una respuesta del SERP es gratuito, parte de esa llamada de 10 créditos, pero expandir un token con la herramienta de AI Overview, incluido cada token de People Also Ask, es una llamada aparte de 5 créditos. El tamaño de la respuesta no cambia el precio.
La prueba gratuita es de 1.000 créditos durante 30 días sin tarjeta, lo que equivale a 100 llamadas de SERP completo o 200 de las llamadas de 5 créditos. Después, una cuenta activa sigue recibiendo una recarga de 100 créditos cada día siempre que su saldo baje de 100, por lo que un agente de bajo volumen funciona en el plan gratuito indefinidamente.
Los planes de pago empiezan en $49 al mes por 200.000 créditos. El precio por crédito baja con el volumen, y las cifras actuales están en la página de precios.
Tu plan también define la concurrencia. La prueba gratuita permite 1 solicitud a la vez, Startup 15, Business 30, Growth 50, y los planes de alto volumen van de 200 a 1.500. La concurrencia es el único límite. No hay un tope separado de solicitudes por minuto. Gestiona el caso de desbordamiento de forma defensiva en cualquier proceso desatendido, porque un agente que se ramifica en varias consultas llegará al techo antes que tú.
?apis=google_serp expone estas ocho herramientas. El parámetro acepta una lista, y ?apis=google_serp,google_maps añade las herramientas de Google Maps junto a la búsqueda. Si omites el parámetro, obtienes todo lo que HasData expone, que actualmente son 57 herramientas.
Una lista reducida suele ser la mejor opción por defecto. Un modelo que elige entre ocho herramientas acierta con más frecuencia que uno que elige entre cincuenta y siete, y las propias descripciones de las herramientas consumen contexto en cada turno.
Google ya no ofrece una API de búsqueda general. La vía oficial es la Custom Search JSON API, y responde a una pregunta distinta de esta.
La Custom Search JSON API busca en un Programmable Search Engine que tú configuras, sobre los sitios que enumeras o sobre el índice completo de la web si lo activas. Está limitada a 100 consultas gratuitas al día y luego cobra por cada mil hasta un tope diario, y devuelve un conjunto de resultados reducido. No devuelve el AI Overview, People Also Ask, el paquete local, compras, noticias ni vídeos cortos, porque son funciones de la página de resultados en vivo, no de la API. Es la herramienta adecuada cuando quieres buscar en tu propio sitio o en un conjunto fijo de sitios y mantenerte dentro de los términos oficiales de Google para ello.
Este servidor devuelve la página de resultados en vivo de Google tal como la ve un visitante, ya analizada. No hay nada que configurar: la consulta se ejecuta contra todo Google, no contra un motor seleccionado, y el AI Overview, People Also Ask, compras y el resto vuelven como bloques estructurados.
Custom Search JSON API | Este servidor | |
Qué busca | Un Programmable Search Engine que configuras | La página de resultados en vivo de Google |
Configuración | Un proyecto de Cloud y un motor de búsqueda | Una clave de API |
AI Overview y People Also Ask | No se devuelven | Integrados, o mediante token |
Compras, noticias, vídeos cortos, local | No se devuelven | Herramientas dedicadas |
Plan gratuito | 100 consultas al día | 1.000 créditos durante 30 días y luego una recarga diaria |
Dos filas lo deciden. Si solo necesitas buscar en tus propios sitios y quieres la API oficial de Google para eso, la Custom Search JSON API es la opción adecuada. Si necesitas el SERP real, su AI Overview o cualquiera de los paneles que Google muestra a quien busca, la API oficial no los devuelve y esta sí.
Lo que este servidor no hace. Nada de rastreo de las páginas detrás de los resultados, ni historial de posiciones, ni nada que escriba. Devuelve la página de resultados procesada.
Un servidor que expone los resultados de búsqueda de Google como herramientas que un cliente de IA puede llamar. El cliente envía una llamada a una herramienta mediante el Model Context Protocol, el servidor obtiene la página de resultados y devuelve JSON estructurado, y el modelo trabaja con el resultado y nunca ve una página de HTML. Este expone ocho herramientas de solo lectura y se ejecuta de forma remota, por lo que el cliente se conecta a una URL y no inicia ningún proceso local.
Sí. Una SERP es una página de resultados del motor de búsqueda. Estas herramientas devuelven las páginas de resultados de Google, por lo que "SERP API" y "Google Search API" significan lo mismo en este repositorio.
Google no publica ningún servidor MCP ni una API de búsqueda general. El producto oficial más cercano es la API JSON de Custom Search, que busca en un Programmable Search Engine que tú configuras. Varios servidores MCP de la comunidad, este entre ellos, devuelven en su lugar la página de resultados en vivo.
Ejecuta una llamada SERP. El aiOverview suele estar en línea con sus textBlocks y references. Cuando en su lugar vuelve como pageToken, y en cada pregunta de People Also Ask, pasa ese token a la herramienta AI Overview para obtener la respuesta. Los tokens caducan rápido, así que expándelos desde una llamada reciente.
No. La única credencial es tu clave de HasData. No hay nada que crear en Google Cloud y ninguna cuota por API que gestionar.
No. La clave no caduca. Rótala en el panel siempre que lo necesites.
En vivo. Cada llamada obtiene la página de resultados en el momento de la solicitud y lleva su propio requestMetadata.id. Dos llamadas idénticas son dos recuperaciones independientes, no una reproducción de una copia almacenada.
No. HasData es un servicio independiente y no está afiliado a Google, ni respaldado ni patrocinado por Google. Google es una marca comercial de su respectivo propietario. Las herramientas trabajan únicamente con datos disponibles públicamente, y tú eres responsable de usar los resultados de acuerdo con los términos de Google y la ley que te sea aplicable.
Página del producto y generador de solicitudes | |
Documentación del servidor | |
Las 57 herramientas en un solo servidor | |
Tutoriales para clientes | |
Las otras superficies que analizamos | |
Planes y costes de crédito | |
Claves y uso | |
Lanzador de Node en npm | |
Lanzador de Python en PyPI |
Este repositorio es configuración y documentación para un servidor remoto. No hay paso de compilación ni nada que contenerizar.
Aun así incluye una prueba de contrato. El README documenta ocho herramientas con parámetros específicos, y la lista de herramientas upstream puede cambiar sin un commit aquí, lo que dejaría que este archivo te mintiera en silencio. La prueba verifica que las herramientas documentadas existen con los parámetros indicados, y se ejecuta semanalmente en CI y también en cada push.
HASDATA_API_KEY=your_key_here npm testEn PowerShell:
$env:HASDATA_API_KEY = "your_key_here"; npm testLa última comprobación realiza una búsqueda real y cuesta 10 créditos, que es el precio de un canario que puede fallar por la razón correcta. Enumerar las herramientas funciona con cualquier clave no vacía, por lo que una prueba que solo enumera herramientas sigue en verde con una clave revocada.
Las correcciones de las tablas de herramientas y de las muestras de respuesta son la contribución más útil, porque son las partes que tienden a desviarse. Incluye la llamada que hiciste y la respuesta que obtuviste. Las pull requests de forks ejecutan la suite sin clave, y las comprobaciones en vivo se omiten en lugar de ponerse en rojo.
MIT. Consulta LICENSE.
Get AI Mode SERP Results
Captures Gemini-powered AI Mode answers from Google Search. Returns the conversational response text, cited source links, subtopic breakdowns, follow-up suggestions, and a subsequentRequestToken for multi-turn continuation. Use for next-gen search interfaces, AI-answer monitoring, citation tracking, content research agents, building question-answering pipelines grounded in live Google results, and person/company data enrichment — e.g. asking Who is the CEO of HasData?, What is Roman Milyushkevich's LinkedIn?, HasData founder email, HasData Instagram handle to get a synthesized answer plus source URLs in one call, ideal for lead enrichment, sales research, people search, and filling in contact/attribute gaps for CRM records.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Specify the search term for which you want to scrape the SERP. | |
| gl | No | The two-letter country code for the country you want to limit the search to. Provide one exact documented value (245 allowed), e.g. `ac`, `af`. | |
| hl | No | The two-letter language code for the language you want to use for the search. Provide one exact documented value (159 allowed), e.g. `af`, `ak`. | |
| uule | No | The encoded location parameter. | |
| location | No | Google canonical location for the search. | |
| continuable | No | Whether to continue an existing AI Mode conversation. | |
| subsequentRequestToken | No | Token used to continue a previous AI Mode request. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description clearly explains the output and the continuation mechanism, making behavior transparent.
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 detailed and informative, though slightly verbose with repeated examples; it is still well-structured and front-loaded.
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?
The description fully explains what the tool does, its output, and its multi-turn continuation feature, making it complete for the given complexity.
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 covers all parameters with descriptions; the tool description does not add additional meaning beyond the schema, so a neutral score.
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?
Clearly states it gets AI Mode SERP results from Google, distinguishing from other Google SERP tools like AI Overview.
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?
Provides explicit use cases and examples, but does not explicitly compare with alternative tools, so slightly less than perfect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get AI Overview Results
Fetches the lazy-loaded Google AI Overview block via a pageToken returned by the Google SERP API (token valid for 4 minutes). Returns the AI-generated answer text, referenced source URLs, and expanded subtopic sections. Use as a follow-up call to Google SERP for tracking AI citations in SEO, fact-checking answers against sources, and LLM retrieval pipelines grounded in live Google results.
| Name | Required | Description | Default |
|---|---|---|---|
| pageToken | Yes | Token from `aiOverview` block in Google SERP API. Valid for 4 minutes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the block is lazy-loaded, the token is valid for only 4 minutes, and it returns specific content. While it doesn't explicitly state read-only behavior, the description implies a safe fetch operation.
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 concise and well-structured: a clear title line, a brief explanation of what is fetched, the returned contents, and explicit use cases. No redundant or extraneous text.
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 simple input (one parameter, no nested objects) and no output schema, the description is complete. It explains the purpose, parameter source and validity, expected return contents, and appropriate use cases, giving the agent everything needed to decide and invoke correctly.
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 sole parameter, pageToken, is fully described in the input schema ('Token from aiOverview block... Valid for 4 minutes'), and the tool description repeats this same information without adding new meaning. Since schema coverage is 100%, baseline is 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 clearly states the tool's action ('Get AI Overview Results') and resource (Google AI Overview block), distinguishes it from sibling tools by specifying it's a follow-up using a pageToken, and details the returned data (answer text, source URLs, subtopic sections).
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 provides use cases: 'tracking AI citations in SEO, fact-checking answers against sources, and LLM retrieval pipelines grounded in live Google results.' It also implies the prerequisite of having a pageToken from a prior SERP call, making it clear when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Google Events Results
Scrapes the Google Events vertical for a query plus location (or uule) with date filters (today, tomorrow, this/next week, weekend, this/next month), virtual-event toggle, domain/country/language targeting, and pagination. Returns event title, start date/time, venue name and address, ticket/source links, description, and thumbnail. Use for event-discovery chatbots, local aggregators, calendar sync, competitive monitoring of event listings, and pulling upcoming shows/conferences for a region.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Specify the search term for which you want to scrape the SERP. | |
| gl | No | The two-letter country code for the country you want to limit the search to. Provide one exact documented value (245 allowed), e.g. `ac`, `af`. | |
| hl | No | The two-letter language code for the language you want to use for the search. Provide one exact documented value (159 allowed), e.g. `af`, `ak`. | |
| uule | No | The encoded location parameter. | |
| start | No | This parameter specifies the number of search results to skip and is used for implementing pagination. For example, a value of 0 (default) indicates the first page of results, 10 refers to the second page, and 20 to the third page. | |
| domain | No | Google domain to use. Default is google.com. Provide one exact documented value (195 allowed), e.g. `google.ac`, `google.ad`. | |
| htichips | No | Filter parameter for refining event search results. Supports various filters for events. Multiple filters can be passed using a comma. The available filters are: - `date:today`: Today's Events - `date:tomorrow`: Tomorrow's Events - `date:week`: This Week's Events - `date:weekend`: This Weekend's Events - `date:next_week`: Next Week's Events - `date:month`: This Month's Events - `date:next_month`: Next Month's Events - `event_type:Virtual-Event`: Online Events For example, to filter for today's online events, use: `event_type:Virtual-Event,date:today`. | |
| location | No | Google canonical location for the search. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool 'scrapes' data, implying a read-only operation, but does not mention rate limits, authentication, or potential blocks. The description is adequate but not fully transparent about operational 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 concise and well-structured, starting with a brief summary, followed by functional details and use cases. It avoids excessive verbosity while covering essential aspects.
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, the description provides sufficient context about functionality, parameters, and intended use cases. It does not describe return values, but no output schema is provided, so that is not required. It is complete enough for an agent to decide when and how to invoke it.
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 already provides descriptions for all 8 parameters, including detailed explanation of htichips filters. The tool description adds no additional parameter semantics beyond what is already in the schema, so it meets the baseline but does not exceed it.
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 scrapes the Google Events vertical, listing specific filters and use cases. This distinguishes it from generic search and other vertical tools, such as general SERP or image search.
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?
It explicitly mentions use cases like event-discovery chatbots and local aggregators, implying when to use this tool. It does not name alternative tools, but the context makes it clear this is for event-specific searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Immersive Product Information
Expands the Google Shopping Immersive Product pop-up given an immersiveProductPageToken from the Google Shopping API, with optional moreStores (up to ~13 merchants instead of 3–5) and nextPageToken for paginating stores. Returns multi-store offers (merchant, price, shipping, condition, URL), product specs, images, ratings, and the nextPageToken. Use for price-comparison bots, merchant discovery, dropshipping research, and aggregating full offer lists per product.
| Name | Required | Description | Default |
|---|---|---|---|
| pageToken | Yes | Token for displaying more product info in the Google immersive pop-up, available in the Google Shopping API response as the `immersiveProductPageToken` property. | |
| moreStores | No | Fetch additional store results in a single search. By default it returns 3–5 stores, and when true it returns up to 13 or the maximum available for the product. | |
| nextPageToken | No | Token used to retrieve the next page of store results. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It describes the read-like behavior (expands, returns) and mentions pagination and optional store expansion, but it does not explicitly state that it is a read-only operation or disclose any potential side effects, auth requirements, or rate limits. The description is informative but not fully explicit.
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 concise and well-structured, with the core purpose front-loaded. It includes a useful list of return fields and use cases without excessive verbosity.
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 there is no output schema, the description adequately explains what is returned (offers, specs, images, ratings, nextPageToken). It also covers key parameters and use cases. It does not mention error handling or token lifecycle, but these are not critical for a simple read 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 coverage is 100%, so the schema already documents all parameters. The description adds minor context (e.g., moreStores expands from 3–5 to up to 13, nextPageToken paginates) but largely repeats what the schema says. It adds value but not significantly beyond the 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 states a clear verb and resource: it expands the Google Shopping Immersive Product pop-up given a token. It distinguishes itself by focusing on the immersive product view, but it does not explicitly name sibling tools or contrast with them, so it misses the top 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?
It provides clear use cases (price-comparison bots, merchant discovery, dropshipping research) but does not explicitly state when to avoid it or name alternatives. The context is clear but exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Google News Results
Retrieves Google News results by free-text query, topicToken (World, Business, Technology, etc.), sectionToken, publicationToken (e.g. CNN, BBC), or storyToken (full-coverage cluster with sort by relevance/date). Returns article title, snippet, source publisher, published date, thumbnail, and URL, plus tokens for navigating topics, sub-sections, and story clusters. Use for news monitoring, brand/PR tracking, topical aggregators, publisher-specific feeds, and drilling into full story coverage.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Free-text query as used on news.google.com. Not allowed with `topicToken`, `storyToken`, or `publicationToken`. | |
| gl | No | The two-letter country code for the country you want to limit the search to. Provide one exact documented value (245 allowed), e.g. `ac`, `af`. | |
| hl | No | The two-letter language code for the language you want to use for the search. Provide one exact documented value (159 allowed), e.g. `af`, `ak`. | |
| so | No | Sort order for articles in a story. Use only with storyToken. | |
| storyToken | No | Token for a single news story cluster (the “Full coverage” page). | |
| topicToken | No | Token for a Google News topic such as World, Business, or Technology. Not allowed with `q`, `storyToken`, or `publicationToken`. | |
| sectionToken | No | Token for a sub-section under a topic, for example Business → Economy. Use only when `topicToken` or `publicationToken` is present. | |
| publicationToken | No | Token for a specific publisher such as CNN or BBC. Not allowed with `q`, `storyToken`, or `topicToken`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It transparently describes the return payload (title, snippet, source publisher, published date, thumbnail, URL) and the navigation tokens, and notes that storyToken supports sorting by relevance/date. It does not mention limits, errors, or rate restrictions, but for a read-oriented GET endpoint the description provides solid 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 compact, front-loaded with the core purpose, and every sentence adds useful information about retrieval modes, output, and use cases. It is dense but not bloated, and it avoids unnecessary repetition of schema details.
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 8-parameter schema with full descriptions and no output schema, the description adequately covers what the tool returns, the main input modes, and appropriate usage scenarios. It does not cover pagination or result limits, but the schema and stated output fields give an agent enough to invoke and interpret the tool correctly.
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% and every parameter has a meaningful description with mutual-exclusion constraints. The tool description adds value by grouping the parameter types and explaining the story-cluster sort, but it mostly paraphrases what the schema already documents. Baseline 3 is appropriate since 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 a specific verb ('Retrieves Google News results') and resource, listing the distinct retrieval modes (free-text query, topicToken, sectionToken, publicationToken, storyToken) and the returned fields. It distinguishes itself from the general google_serp_serp_getSearchResults sibling by focusing specifically on Google News and its token-based navigation.
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 enumerates intended use cases: 'news monitoring, brand/PR tracking, topical aggregators, publisher-specific feeds, and drilling into full story coverage.' It does not explicitly name a sibling as an alternative or state when not to use this tool, but the use-case framing gives an agent clear selection context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Product Information
Pulls detailed product data from Google Shopping by productId with searchType (offers, specs, reviews) and rich filters (free shipping, used-condition, sort by price/total price/deals/seller rating, reviews count). Returns product title, images, price, ratings, specs, merchant offers (seller, shipping, condition, total price), and review text depending on searchType. Use for price intelligence, catalog enrichment, review mining, competitor spec comparison, and building shopping assistants that surface the cheapest or highest-rated offer.
| Name | Required | Description | Default |
|---|---|---|---|
| gl | No | The two-letter country code for the country you want to limit the search to. Provide one exact documented value (245 allowed), e.g. `ac`, `af`. | |
| hl | No | The two-letter language code for the language you want to use for the search. Provide one exact documented value (159 allowed), e.g. `af`, `ak`. | |
| uule | No | The encoded location parameter. | |
| start | No | This parameter specifies the number of search results to skip and is used for pagination. For example, a value of 0 (default) indicates the first page of results, 10 refers to the second page, and 20 to the third page. This parameter is applicable only when `searchType=offers` is specified. For reviews pagination use `filter` parameter. | |
| domain | No | Google domain to use. Default is google.com. Provide one exact documented value (195 allowed), e.g. `google.ac`, `google.ad`. | |
| filter | No | Filter parameter for refining search results. Supports various filters for offers and reviews. Multiple filters can be passed using a comma. The available filters are: Offers filters: - `freeship:1`: Show only products with free shipping. - `ucond:1`: Show only used products. - `scoring:p`: Sort by base price. - `scoring:tp`: Sort by total price. - `scoring:cpd`: Sort by current promotion deals (special offers). - `scoring:mrd`: Sort by seller's rating. Reviews filters: - `rnum:{number}`: Number of results (100 is max). | |
| location | No | Google canonical location for the search. | |
| productId | Yes | The product ID to get results for. | |
| searchType | No | Parameter for fetching specific product information, such as 'offers', 'specs', or 'reviews'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly frames the operation as read-only ('Pulls') and discloses searchType-dependent return content: title, images, price, ratings, specs, merchant offers, and review text. It does not cover rate limits, auth, or errors, but the core behavioral contract is present.
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 compact and front-loaded: a one-line summary, then the detailed behavior, then use cases. Every sentence contributes value, and there is no meaningful 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?
For a 9-parameter tool with no output schema, the description provides a strong high-level output contract and common use cases, while the schema covers parameter details. The main gap is that optional searchType has no documented default behavior, and pagination guidance relies entirely on the schema rather than the description.
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%, and the schema already explains filters, pagination, enums, and parameter constraints. The description paraphrases searchType and filters but adds no new parameter-level semantics, so the baseline of 3 applies.
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 a specific verb and resource: 'Pulls detailed product data from Google Shopping by productId' with searchType variants and filters. This clearly distinguishes it from sibling search tools like shopping_getSearchResults, which are search-oriented rather than product-ID lookups.
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 task-based use cases: price intelligence, catalog enrichment, review mining, competitor spec comparison, and building shopping assistants. It does not name exclusions or alternative sibling tools, but it gives clear context for when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Google Search Results
Full-featured Google Search scraper with location/uule, country (gl), language (hl, lr), domain, device type, safesearch, time/date filters (qdr, cdr), knowledge-graph IDs, and tbm vertical selection (images, videos, news, shopping, local), plus offset/num pagination. Returns organic results (title, link, snippet, position), ads, knowledge graph, related searches, People Also Ask, local pack, featured snippets, AI Overview pageToken, and rich SERP features. Use for SEO rank tracking, keyword research, SERP-feature monitoring, competitor analysis, grounding LLMs with fresh location-aware search data, and especially for person/company data enrichment — e.g. finding a person's LinkedIn/Instagram/Twitter profile (Roman Milyushkevich LinkedIn, HasData Instagram), a company's CEO/founder/leadership (HasData CEO, HasData founder), contact emails (Roman Milyushkevich HasData email), phone numbers, GitHub profiles, press mentions, or any public attribute of a person or business by running a targeted query and parsing the top organic results.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Specify the search term for which you want to scrape the SERP. | |
| gl | No | The two-letter country code for the country you want to limit the search to. Provide one exact documented value (245 allowed), e.g. `ac`, `af`. | |
| hl | No | The two-letter language code for the language you want to use for the search. Provide one exact documented value (159 allowed), e.g. `af`, `ak`. | |
| lr | No | The 'lr' parameter specifies the language of the websites to return results from. This parameter filters results based on the language of the web content. | |
| si | No | Google Cached Search Parameters ID. | |
| num | No | Number of results per page, ranging from 10 to 100. | |
| tbm | No | Specify the type of search. | |
| tbs | No | This parameter supports various filters that can be combined by separating them with a comma. Here are examples of these filters: - Specific Time Range: `cdr:1,cd_min:10/17/2018,cd_max:3/8/2021` - Filter results to show only those within the defined date range. - Sort by Date: `sbd:1` - Results are sorted by date, from the most recent to the oldest. - Sort by Relevance: `sbd:0` - Results are sorted by relevance to the search query. - Sites with Images: `img:1` - Only show results from webpages that contain images. Quick Date Range (qdr): - `qdr:h` - Show results from the past hour. - `qdr:d` - Limit results to the past day. - `qdr:w` - Filter results from the week. - `qdr:m` - Display results from the past month. - `qdr:y` - Show results from the past year. - `qdr:h10`, `qdr:d10`, `qdr:w10`, `qdr:m10`, `qdr:y10` - Specify a number to show results from the last 10 hours, days, weeks, months, or years respectively. These filters enhance the control over search results, allowing for precise retrieval of information based on specific criteria. | |
| lsig | No | Additional Google Place ID. | |
| nfpr | No | Controls if auto-corrected results are shown. 0 includes them (default), 1 shows only the original query. Google may still return auto-corrected results if no others are available. | |
| safe | No | Adult Content Filtering option. | |
| uule | No | The encoded location parameter. | |
| kgmid | No | Google Knowledge Graph ID. | |
| start | No | This parameter specifies the number of search results to skip and is used for implementing pagination. For example, a value of 0 (default) indicates the first page of results, 10 refers to the second page, and 20 to the third page. For Google Local Results, the start value must be in multiples of 20, such as 20 for the second page, 40 for the third page, etc. | |
| domain | No | Google domain to use. Default is google.com. Provide one exact documented value (195 allowed), e.g. `google.ac`, `google.ad`. | |
| filter | No | Defines whether to enable or disable the filters for 'Similar Results' and 'Omitted Results'. Set to 1 (default) to enable these filters, or 0 to disable them. | |
| ludocid | No | The Google Place ID for a specific location. | |
| location | No | Google canonical location for the search. | |
| deviceType | No | Specify the device type for the search. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It does disclose that this is a scraper, enumerates filtering capabilities, and lists returned elements including organic results, ads, knowledge graph, People Also Ask, local pack, and AI Overview pageToken. However, it does not mention operational caveats such as rate limits, authentication needs, blocking risks, or pagination limits beyond offset/num.
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 front-loaded with a one-line summary and then organized into capability, return-value, and use-case sections. It is long, but the length is justified by the tool's 19 parameters and rich feature set; the examples are concrete rather than filler.
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 complex 19-parameter tool with no annotations and no output schema, the description is fairly complete: it explains what the tool returns and gives practical invocation examples. It does not discuss alternatives or limitations, but an agent has enough information to select and call the tool correctly.
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 all 19 parameters are already documented in the input schema. The description only groups them into capability families like location/uule, country, language, tbm, and offset/num pagination, adding no parameter-level meaning beyond what the schema already provides.
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 names the operation ('Get Google Search Results') and identifies the tool as a 'full-featured Google Search scraper', listing parameter families and returned SERP components. It clearly conveys that this is the generic Google web-search endpoint rather than an image, news, or shopping variant, though it does not explicitly distinguish itself from the sibling serp_light tool.
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 gives concrete use cases: SEO rank tracking, keyword research, SERP-feature monitoring, competitor analysis, grounding LLMs, and person/company data enrichment with example queries. It does not explicitly state when not to use it or when to prefer serp_light, google_images, or AI-overview siblings, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Google Light Search Results
Lightweight Google Search scraper that returns only organic results and basic pagination, omitting AI Overview, knowledge graph, PAA, and other rich SERP blocks for faster, cheaper responses. Supports location/uule, country (gl), language (hl/lr), domain, safesearch, and time/date filters (qdr, cdr) with offset/num pagination. Returns title, link, snippet, and position per result. Use for high-volume keyword monitoring, bulk rank tracking, backlink discovery, and any workflow where only the ten blue links matter.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Specify the search term for which you want to scrape the SERP. | |
| gl | No | The two-letter country code for the country you want to limit the search to. Provide one exact documented value (245 allowed), e.g. `ac`, `af`. | |
| hl | No | The two-letter language code for the language you want to use for the search. Provide one exact documented value (159 allowed), e.g. `af`, `ak`. | |
| lr | No | The 'lr' parameter specifies the language of the websites to return results from. This parameter filters results based on the language of the web content. | |
| num | No | Number of results per page, ranging from 10 to 100. | |
| tbs | No | This parameter supports various filters that can be combined by separating them with a comma. Here are examples of these filters: - Specific Time Range: `cdr:1,cd_min:10/17/2018,cd_max:3/8/2021` - Filter results to show only those within the defined date range. - Sort by Date: `sbd:1` - Results are sorted by date, from the most recent to the oldest. - Sort by Relevance: `sbd:0` - Results are sorted by relevance to the search query. - Sites with Images: `img:1` - Only show results from webpages that contain images. Quick Date Range (qdr): - `qdr:h` - Show results from the past hour. - `qdr:d` - Limit results to the past day. - `qdr:w` - Filter results from the week. - `qdr:m` - Display results from the past month. - `qdr:y` - Show results from the past year. - `qdr:h10`, `qdr:d10`, `qdr:w10`, `qdr:m10`, `qdr:y10` - Specify a number to show results from the last 10 hours, days, weeks, months, or years respectively. These filters enhance the control over search results, allowing for precise retrieval of information based on specific criteria. | |
| safe | No | Adult Content Filtering option. | |
| uule | No | The encoded location parameter. | |
| start | No | This parameter specifies the number of search results to skip and is used for implementing pagination. For example, a value of 0 (default) indicates the first page of results, 10 refers to the second page, and 20 to the third page. For Google Local Results, the start value must be in multiples of 20, such as 20 for the second page, 40 for the third page, etc. | |
| domain | No | Google domain to use. Default is google.com. Provide one exact documented value (195 allowed), e.g. `google.ac`, `google.ad`. | |
| filter | No | Defines whether to enable or disable the filters for 'Similar Results' and 'Omitted Results'. Set to 1 (default) to enable these filters, or 0 to disable them. | |
| location | No | Google canonical location for the search. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it does disclose key traits: it omits rich blocks, returns only organic results, and supports specific filters. However, it doesn't mention error handling, rate limits, or potential staleness of data—common concerns for scraping tools. It adds value but isn't exhaustive.
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 well-structured and front-loaded: it states the core purpose, then omissions, capabilities, return format, and use cases. Every sentence contributes value, but it's slightly long given the detailed schema already available. Still, no 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 12 parameters, detailed schema, and no output schema, the description covers the essential decision-making info: what it returns, key filtering options, and typical use cases. It doesn't explicitly explain pagination mechanics (though schema does) or edge cases, but the provided context is sufficient for an agent to select and invoke it correctly.
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 coverage is 100%, so baseline is 3, but the description groups parameters into meaningful categories (location/uule, country, language, filters, pagination), giving agents a high-level understanding of how they combine. It adds conceptual clarity beyond the schema's individual parameter descriptions.
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 is a lightweight Google Search scraper that returns only organic results, explicitly listing what it omits (AI Overview, knowledge graph, PAA, etc.) and what it returns (title, link, snippet, position). This makes it readily distinguishable from siblings like serp_getSearchResults or news/shopping 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?
Explicit use cases are given: high-volume keyword monitoring, bulk rank tracking, backlink discovery, and any workflow where only the ten blue links matter. This implies when not to use it (when rich SERP blocks are needed), though it doesn't explicitly name the alternative tool like hasdata_google_serp_serp_getSearchResults. Clear context but no formal exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Shopping Search Results
Scrapes Google Shopping listings for a query with location/uule, country/language/domain, time/date filters, device type, shoprs filter-helper IDs, and offset pagination. Returns product title, price, merchant/source, rating, reviews count, thumbnail, product link, productId, immersiveProductPageToken, and filter chips with hasdata_link for refining by brand/price/condition/promotions. Use for e-commerce price tracking, catalog building, promotion discovery, and feeding productIds into the Product API or tokens into the Immersive Product API for deeper data.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Specify the search term for which you want to scrape the SERP. | |
| gl | No | The two-letter country code for the country you want to limit the search to. Provide one exact documented value (245 allowed), e.g. `ac`, `af`. | |
| hl | No | The two-letter language code for the language you want to use for the search. Provide one exact documented value (159 allowed), e.g. `af`, `ak`. | |
| tbs | No | This parameter supports various filters that can be combined by separating them with a comma. Here are examples of these filters: - Specific Time Range: `cdr:1,cd_min:10/17/2018,cd_max:3/8/2021` - Filter results to show only those within the defined date range. - Sort by Date: `sbd:1` - Results are sorted by date, from the most recent to the oldest. - Sort by Relevance: `sbd:0` - Results are sorted by relevance to the search query. - Sites with Images: `img:1` - Only show results from webpages that contain images. Quick Date Range (qdr): - `qdr:h` - Show results from the past hour. - `qdr:d` - Limit results to the past day. - `qdr:w` - Filter results from the week. - `qdr:m` - Display results from the past month. - `qdr:y` - Show results from the past year. - `qdr:h10`, `qdr:d10`, `qdr:w10`, `qdr:m10`, `qdr:y10` - Specify a number to show results from the last 10 hours, days, weeks, months, or years respectively. These filters enhance the control over search results, allowing for precise retrieval of information based on specific criteria. | |
| uule | No | The encoded location parameter. | |
| start | No | This parameter specifies the number of search results to skip and is used for implementing pagination. For example, a value of 0 (default) indicates the first page of results, 40 refers to the second page, and 80 to the third page. | |
| domain | No | Google domain to use. Default is google.com. Provide one exact documented value (195 allowed), e.g. `google.ac`, `google.ad`. | |
| shoprs | No | Specifies the helper ID for applying search filters. Must be used with the updated `q` parameter, which includes the selected filter (e.g., Coffee sale). To apply filters, use the `hasdata_link` from `filters[index].options[index]` in the JSON. Apply multiple filters by following each `hasdata_link` one by one. To remove a filter, follow its specific `hasdata_link`. | |
| location | No | Google canonical location for the search. | |
| deviceType | No | Specify the device type for the search. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full responsibility for disclosing behavioral traits. It does not explicitly state whether the operation is read-only or if there are side effects, rate limits, or permissions. The phrasing 'Scrapes Google Shopping listings' implies a passive retrieval, but it lacks an explicit statement about non-destructiveness or data handling.
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 concise and well-structured, with a clear opening statement, a summary of output, and a list of use cases. It avoids redundancy and stays focused, making it easy for users to quickly grasp the tool's function and applications. The structure is efficient with no unnecessary 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?
Despite lacking an output schema, the description compensates by enumerating the expected return fields (e.g., product title, price, merchant) and explaining how to apply filters via 'hasdata_link'. It also covers parameter interactions for shoprs and pagination. Given the tool's moderate complexity, the description provides a complete picture for invocation without leaving critical gaps.
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 already provides detailed descriptions for all 10 parameters, covering their semantics thoroughly. The tool description does not add significant extra meaning beyond summarizing the overall purpose and mentioning a few output fields. Since schema coverage is 100%, the baseline score of 3 is appropriate, as the description adds marginal 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 clearly states that the tool scrapes Google Shopping listings for a search query and returns detailed product information. It explicitly mentions the output fields, such as product title, price, and merchant, making the tool's purpose unambiguous. The name 'Get Shopping Search Results' further reinforces its 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 specific use cases like e-commerce price tracking, catalog building, and promotion discovery, which guide when to employ the tool. It also hints at integration with other tools by mentioning feeding product IDs into the Product API or tokens into the Immersive Product API. However, it does not explicitly contrast it with sibling tools, leaving a small gap in direct alternative selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Short Videos Search Results
Scrapes the Google Short Videos carousel (TikTok, YouTube Shorts, Instagram Reels, etc.) for a query with location/uule, country (gl/cr), language (hl/lr), device type, and page-based pagination. Returns video title, thumbnail, duration, source platform, channel/creator, publish date, and direct video URL. Use for short-form content discovery, viral-trend monitoring, influencer research, cross-platform video aggregation, and sourcing short clips to summarize or embed in LLM responses.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Search query term for retrieving short videos results. | |
| cr | No | The country code for the country you want to limit the search to. Provide one exact documented value (237 allowed), e.g. `countryAF`, `countryAL`. | |
| gl | No | The two-letter country code for the country you want to limit the search to. Provide one exact documented value (245 allowed), e.g. `ac`, `af`. | |
| hl | No | The two-letter language code for the language you want to use for the search. Provide one exact documented value (159 allowed), e.g. `af`, `ak`. | |
| lr | No | The 'lr' parameter specifies the language of the websites to return results from. This parameter filters results based on the language of the web content. | |
| page | No | Page number for paginated results, where 0 is the first page. | |
| uule | No | The encoded location parameter. | |
| location | No | Google canonical location for the search. | |
| deviceType | No | Specify the device type for the search. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It explains that the tool scrapes a live Google carousel and returns specific fields, implying a read-only network operation. It does not mention rate limits, auth, or failure modes, but these are less critical for this non-mutating scraper.
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 reasonably short and front-loaded, with the core scraping behavior in the first sentence and output fields and use cases following. The opening heading repeats the tool name and the use-case list is slightly expansive, but the overall text is efficient and relevant.
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 9-parameter tool with no output schema, the description compensates by listing return fields and mentioning pagination plus location/country/language options. It does not specify result count, maximum page, or exact response structure, but the schema fully documents the parameters and required query.
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 input schema already describes 100% of the parameters, so the baseline is 3. The description adds only high-level grouping such as 'country (gl/cr), language (hl/lr), device type' without clarifying relationships, formats, or usage beyond what the schema already provides.
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 uses a specific verb ('scrapes') and a specific resource ('Google Short Videos carousel'), and names the content sources (TikTok, YouTube Shorts, Instagram Reels). This clearly distinguishes it from sibling SERP tools like general search or news results.
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 explicit use cases such as 'short-form content discovery, viral-trend monitoring, influencer research, cross-platform video aggregation' and sourcing clips for LLM responses. However, it does not explicitly contrast with sibling tools or state when not to use this tool.
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.0hasdata_google_serp_ai_mode_getAiModeResponsehasdata_google_serp_ai_overview_getAiOverviewResponsehasdata_google_serp_events_getEventInformationhasdata_google_serp_immersive_product_getImmersive_e29f691177hasdata_google_serp_news_getGoogleNewshasdata_google_serp_product_getProductInformationhasdata_google_serp_serp_getSearchResultshasdata_google_serp_serp_light_getSearchResultshasdata_google_serp_shopping_getSearchResultshasdata_google_serp_short_videos_getShortVideosSearchResultsScored across 10 tools
Each tool addresses a distinct Google Search vertical (web, shopping, news, events, short videos, AI mode/overview) with clear boundaries. Even where two tools are similar (full vs. light SERP, shopping search vs. product info), their purposes are explicitly differentiated.
All tools follow the pattern `hasdata_google_serp_<category>_<Action>`, with snake_case categories and camelCase actions. The only deviation is the immersive product tool's hash suffix (`getImmersive_e29f691177`), which breaks the clean convention but does not obscure intent.
With 10 tools, the server covers all major Google Search verticals without redundancy or bloat. Each tool serves a distinct scraping need, making the count well-scoped for its purpose.
The tool surface covers web search (both full and lightweight), shopping (search, product details, immersive offers), news, events, short videos, and AI-generated responses. Minor gaps like a dedicated maps/images tool are mitigated by the full SERP tool's `tbm` parameter, making the coverage strong overall.
Live AI-native web search with citations. One tool for every MCP client. Flat per-request pricing.
17 data tools in one MCP server, run on Apify: Google Shopping, Flights, Hotels, News, Images, Videos, Ads Transparency, Jobs and Trends; YouTube transcripts; AI visibility checks; Google Maps leads; App Store and Google Play reviews. Pay per result. Sign in with Apify (OAuth) or an API token.
Your agent needs the Google results page as it actually renders — organic and paid, the AI overview, maps, images, news, jobs and the finance panel — not a scraped guess. **What you can ask for** • "What does the SERP for this keyword look like in Germany, on mobile?" • "Does this query trigger an AI overview, and what does it say?" • "Who is advertising against our brand name?" • "Find local results and the map pack for this phrase." • "Search Google by this image and tell me where else it appears." **How to use it** Point any MCP client at https://mcp.aisa.one/seo-serp/mcp and sign in with OAuth — there is no key to create or paste. 38 tools across Google's surfaces: organic, ads and advertisers, AI mode, autocomplete, images, news, maps and local, events, jobs, datasets, scholar, finance quotes and markets, plus Semrush's organic and paid result sets. **Why this rather than the source** Location and language are parameters, so you can read the page a customer in another country sees. **It is also a door to the rest** The same login reaches 26 sources and 580+ operations. Read the SERP here, then ask the same agent who links to the winner or how much traffic they get — without adding a second server. **What it costs** Finding and inspecting an operation is free. Running one is billed per call at API prices, with no seat and no monthly minimum, and every call takes max_price_usd so an agent cannot overspend by accident. **Where else it reaches** https://mcp.aisa.one/seo-serp-other-engines/mcp for Bing, Yahoo, Baidu, Naver, Seznam and YouTube. https://mcp.aisa.one/seo/mcp for all of it at once — rankings, keywords, backlinks, site health and AI-answer visibility across DataForSEO, Semrush and Ahrefs.
Scrape Google search results with SERP data, ads, and knowledge panels
