de en es ja ko ru zh

Serper MCP Server

Name: Serper MCP Server
Author: garylab

by garylab

Overview Schema Source Related Servers Discussions Admin

Python

Remote

Servidor Serper MCP

insignia de herrería

Un servidor de Protocolo de Contexto de Modelo (MLM) que proporciona la Búsqueda de Google a través de Serper . Este servidor permite a los LLM obtener información de los resultados de búsqueda de Google.

Herramientas disponibles

google_search - Establecer todos los parámetros
google_search_images - Establece todos los parámetros
google_search_videos - Establezca todos los parámetros
google_search_places - Establezca todos los parámetros
google_search_maps - Establezca todos los parámetros
google_search_reviews - Establezca todos los parámetros
google_search_news - Establecer todos los parámetros
google_search_shopping - Establezca todos los parámetros
google_search_lens - Establece todos los parámetros
google_search_scholar - Establecer todos los parámetros
google_search_parents - Establece todos los parámetros
google_search_autocomplete - Establece todos los parámetros
webpage_scrape - Establece todos los parámetros

Related MCP server: Scrapeless MCP Server

Uso

Instalación mediante herrería

Para instalar Serper MCP Server para Claude Desktop automáticamente a través de Smithery :

npx -y @smithery/cli install @garylab/serper-mcp-server --client claude

Uso de `uv` (recomendado)

Asegúrese de haber instalado uv en su sistema operativo.
En la configuración del código de cliente MCP o en la configuración de Claude (archivo claude_desktop_config.json ) agregue el servidor serper mcp:
```
{
    "mcpServers": {
        "serper": {
            "command": "uvx",
            "args": ["serper-mcp-server"],
            "env": {
                "SERPER_API_KEY": "<Your Serper API key>"
            }
        }
    }
}
```
uv descargará el servidor mcp automáticamente usando uvx desde pypi.org y lo aplicará a su cliente MCP.

Usando `pip` para el proyecto

Agregue serper-mcp-server a su archivo requirements.txt del código de cliente MCP.
```
serper-mcp-server
```
Instalar las dependencias.
```
pip install -r requirements.txt
```

Añade la configuración para tu cliente:

{
    "mcpServers": {
        "serper": {
            "command": "python3",
            "args": ["-m", "serper_mcp_server"],
            "env": {
                "SERPER_API_KEY": "<Your Serper API key>"
            }
        }
    }
}

Uso de `pip` para uso global

Asegúrese de que pip o pip3 esté en su sistema operativo.

pip install serper-mcp-server
# or
pip3 install serper-mcp-server

Configuración del código del cliente MCP o configuración de Claude , agregar servidor serper mcp:

{
    "mcpServers": {
        "serper": {
            "command": "python3",
            "args": ["serper-mcp-server"],
            "env": {
                "SERPER_API_KEY": "<Your Serper API key>"
            }
        }
    }
}

Depuración

Puede usar el inspector MCP para depurar el servidor. Para instalaciones uvx :

npx @modelcontextprotocol/inspector uvx serper-mcp-server

O si ha instalado el paquete en un directorio específico o está desarrollando en él:

cd path/to/servers/src/serper
npx @modelcontextprotocol/inspector uv run serper-mcp-server -e SERPER_API_KEY=<the key>

Licencia

serper-mcp-server cuenta con la licencia MIT. Esto significa que puede usar, modificar y distribuir el software libremente, sujeto a los términos y condiciones de la licencia MIT. Para más detalles, consulte el archivo de licencia en el repositorio del proyecto.

Available Tools

13 tools

google_searchC

Search Google for results

ParametersJSON Schema

Name	Required	Description	Default
`q`	Yes	The query to search for
`gl`	No	The country to search in, e.g. us, uk, ca, au, etc.
`location`	No	The location to search in, e.g. San Francisco, CA, USA
`hl`	No	The language to search in, e.g. en, es, fr, de, etc.
`page`	No	The page number to return, first page is 1 (integer value as string)	1
`tbs`	No	The time period to search in, e.g. d, w, m, y
`num`	No	The number of results to return, max is 100 (integer value as string)	10

TDQS

C2.5/5.0

Behavior2/5

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

No annotations are provided, so the description should disclose behavioral traits. However, it only states 'search' without mentioning rate limits, authentication, or that results are organic web pages. This is insufficient for safe tool use.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is concise but lacks structure. It provides minimal information and does not differentiate from sibling tools effectively.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the parameter count (7) and lack of output schema, the description is incomplete. It does not explain return format, behavior, or why to choose this over specialized search tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers 100% of parameters with descriptions, so the description adds no value beyond the schema. Baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Search Google for results' indicates a generic web search tool, but it does not explicitly state that it returns organic web results. This could be confused with other tools like google_search_images or google_search_news. A more specific description like 'Search Google for web pages' would improve clarity.

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

Usage Guidelines2/5

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 its siblings (e.g., google_search_images, google_search_news). The agent must infer that this is the general web search tool without explicit instructions.

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

google_search_autocompleteC

Search Google for results

ParametersJSON Schema

Name	Required	Description	Default
`q`	Yes	The query to search for
`gl`	No	The country to search in, e.g. us, uk, ca, au, etc.
`location`	No	The location to search in, e.g. San Francisco, CA, USA
`hl`	No	The language to search in, e.g. en, es, fr, de, etc.
`page`	No	The page number to return, first page is 1 (integer value as string)	1
`autocorrect`	No	Automatically correct (boolean value as string: 'true' or 'false')	true

TDQS

C2.1/5.0

Behavior2/5

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

No annotations are present, and the description fails to disclose behavioral traits. It is unclear whether the tool returns autocomplete suggestions or full search results, which is misleading given the tool name.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely short but lacks essential information, making it under-specified rather than concise. It fails to earn its place by omitting key details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, no annotations, and a name-description mismatch, the description is completely inadequate. It does not explain the tool's purpose, return value, or differentiation from 11 siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema provides 100% coverage of parameter descriptions, so the description adds no additional meaning. Baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Search Google for results' is vague and does not differentiate from sibling tools like google_search. The name suggests autocomplete functionality, but the description contradicts that by implying general search results.

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

Usage Guidelines2/5

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 such as google_search. There is no mention of context or conditions for use.

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

google_search_imagesD

Search Google for results

ParametersJSON Schema

Name	Required	Description	Default
`q`	Yes	The query to search for
`gl`	No	The country to search in, e.g. us, uk, ca, au, etc.
`location`	No	The location to search in, e.g. San Francisco, CA, USA
`hl`	No	The language to search in, e.g. en, es, fr, de, etc.
`page`	No	The page number to return, first page is 1 (integer value as string)	1
`tbs`	No	The time period to search in, e.g. d, w, m, y
`num`	No	The number of results to return, max is 100 (integer value as string)	10

TDQS

D1.9/5.0

Behavior1/5

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

With no annotations, the description carries full burden for behavioral disclosure. It only says 'Search Google for results' without indicating pagination, result format, or that it returns images. Critical behavioral traits are missing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely short (5 words), but this is underspecification rather than conciseness. It fails to convey the tool's specific purpose or usage, so it is not effectively structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the 7 parameters and no output schema, the description is grossly incomplete. It provides no context on result handling, pagination, or image-specific behavior, leaving the agent underinformed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear parameter descriptions (q, gl, location, etc.). The description adds no additional meaning, but baseline 3 is appropriate since the schema is self-explanatory.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Search Google for results' is vague and does not specify that this tool searches for images. Among siblings like google_search_news and google_search_videos, it should differentiate by mentioning 'images'. It fails to clearly state the resource type.

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

Usage Guidelines2/5

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 its many siblings (e.g., google_search, google_search_images, etc.). There is no mention of context or alternatives, making it hard for an agent to decide.

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

google_search_lensC

Search Google for results

ParametersJSON Schema

Name	Required	Description
`url`	Yes	The url to search
`gl`	No	The country to search in, e.g. us, uk, ca, au, etc.
`hl`	No	The language to search in, e.g. en, es, fr, de, etc.

TDQS

C2.3/5.0

Behavior2/5

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

With no annotations, the description should disclose key behavioral traits. It fails to explain what 'results' means (likely image recognition results) and does not indicate whether it performs a visual search or a standard web search.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (one sentence) but overly vague. Conciseness should not sacrifice clarity; here it does.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 3 parameters, no output schema, and no annotations, the description is insufficient for an agent to correctly decide when to use this tool. The presence of many sibling tools increases the need for specificity, which is lacking.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond the schema, but the schema itself adequately describes the parameters (url, gl, hl).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Search Google for results' is vague and does not specify that this tool is for Google Lens (visual search) as opposed to general web search. Given sibling tools like 'google_search' and 'google_search_images', the purpose is unclear.

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

Usage Guidelines2/5

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 does not mention image-based search or any specific use case.

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

google_search_mapsC

Search Google for results

ParametersJSON Schema

Name	Required	Description	Default
`q`	Yes	The query to search for
`ll`	No	The GPS position & zoom level
`placeId`	No	The place ID to search in
`cid`	No	The CID to search in
`gl`	No	The country to search in, e.g. us, uk, ca, au, etc.
`hl`	No	The language to search in, e.g. en, es, fr, de, etc.
`page`	No	The page number to return, first page is 1 (integer value as string)	1

TDQS

C2.1/5.0

Behavior2/5

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

No annotations and the description provides no behavioral details such as what results are returned, any rate limits, or authentication needs. The description is too generic.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very short, but it lacks essential details. It is not appropriately sized for the tool's complexity; it is under-specified.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 7 parameters and no output schema, the description is completely inadequate. It does not explain return values, pagination, or how this maps search differs from other searches.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so each parameter has a description. The tool description adds no additional meaning beyond the schema, earning a baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Search Google for results' is vague and does not specify that this tool searches Google Maps specifically. It does not distinguish from siblings like google_search (generic), google_search_images, etc.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives. No mention of context or exclusions.

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

google_search_newsD

Search Google for results

ParametersJSON Schema

Name	Required	Description	Default
`q`	Yes	The query to search for
`gl`	No	The country to search in, e.g. us, uk, ca, au, etc.
`location`	No	The location to search in, e.g. San Francisco, CA, USA
`hl`	No	The language to search in, e.g. en, es, fr, de, etc.
`page`	No	The page number to return, first page is 1 (integer value as string)	1
`tbs`	No	The time period to search in, e.g. d, w, m, y
`num`	No	The number of results to return, max is 100 (integer value as string)	10

TDQS

D1.4/5.0

Behavior1/5

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

With no annotations provided, the description carries the full burden of disclosing behavior. It gives no information about return type, pagination, or that it specifically returns news articles.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short but lacks substance. It is under-specified, not concise in a helpful way.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is completely inadequate for a tool with 7 parameters. It does not mention that it searches news, how to use time filtering (tbs), or what results to expect.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the parameters are well-documented in the schema. The description adds no additional meaning, but the baseline is 3 per the guidelines.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Search Google for results' is a tautology of the tool name and does not specify that it searches for news. It fails to distinguish from siblings like google_search (general web) or google_search_images.

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

Usage Guidelines1/5

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

No guidance on when to use this tool versus alternatives. The description does not mention that it is for news or provide any context for selection among the many sibling search tools.

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

google_search_patentsC

Search Google for results

ParametersJSON Schema

Name	Required	Description	Default
`q`	Yes	The query to search for
`num`	No	The number of results to return, max is 100 (integer value as string)	10
`page`	No	The page number to return, first page is 1 (integer value as string)	1

TDQS

C2.2/5.0

Behavior2/5

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

No annotations provided. The description does not disclose any behavioral traits beyond a generic search. No mention of scoping, limitations, or output behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely short but lacks essential detail. Conciseness is not beneficial when it omits critical context (e.g., that it searches patents).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of patent search and many sibling tools, the description fails to provide enough information for an agent to understand what the tool does. No output schema, so missing return value info.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers 100% of parameters with descriptions. The description adds no extra meaning, but schema already handles parameter semantics adequately. Baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description is 'Search Google for results' which is generic and does not specify patents. The tool name indicates patents, but the description could apply to any search, failing to distinguish from siblings.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like google_search or google_search_scholar. The description provides no context for selection.

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

google_search_placesD

Search Google for results

ParametersJSON Schema

Name	Required	Description	Default
`q`	Yes	The query to search for
`gl`	No	The country to search in, e.g. us, uk, ca, au, etc.
`location`	No	The location to search in, e.g. San Francisco, CA, USA
`hl`	No	The language to search in, e.g. en, es, fr, de, etc.
`page`	No	The page number to return, first page is 1 (integer value as string)	1
`autocorrect`	No	Automatically correct (boolean value as string: 'true' or 'false')	true

TDQS

D1.9/5.0

Behavior1/5

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

No annotations are provided, and the description gives no behavioral details such as rate limits, output format, pagination behavior, or the nature of results (e.g., places). The description is effectively empty.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that conveys almost no information. It is not concise in a helpful way; it wastes the sentence on a generic statement.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 6 parameters, no output schema, and 12 sibling tools, the description is severely incomplete. It lacks essential context about what the tool does, how results are returned, and how to use parameters effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond what the schema already provides. No parameter-specific insights are given.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Search Google for results' is vague and does not specify that this tool is for searching places specifically. It reads like a tautology of the name and fails to distinguish from siblings like google_search or google_search_maps.

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

Usage Guidelines2/5

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. There is no mention of context, scenarios, or exclusions.

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

google_search_reviewsD

Search Google for results

ParametersJSON Schema

Name	Required	Description	Default
`fid`	Yes	The FID
`cid`	No	The CID to search in
`placeId`	No	The place ID to search in
`sortBy`	No	The sort order to use (enum value as string: 'mostRelevant', 'newest', 'highestRating', 'lowestRating')	mostRelevant
`topicId`	No	The topic ID to search in
`nextPageToken`	No	The next page token to use
`gl`	No	The country to search in, e.g. us, uk, ca, au, etc.
`hl`	No	The language to search in, e.g. en, es, fr, de, etc.

TDQS

D1.9/5.0

Behavior1/5

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

No annotations provided. The description does not disclose any behavioral traits (e.g., that it fetches reviews, pagination behavior, or data availability).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Overly brief single sentence that omits critical details; under-specification rather than conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 8 parameters and no output schema, the description is completely inadequate. It does not explain what the tool does (search reviews), how it relates to sibling tools, or any behavioral details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with parameter descriptions already provided. The description adds no additional meaning beyond what's in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Search Google for results' is vague and does not specify that this tool is for reviews. It fails to distinguish from siblings like google_search or google_search_places that also search Google for results.

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

Usage Guidelines2/5

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

No guidelines on when to use this tool versus alternatives. No context on prerequisites or use cases.

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

google_search_scholarC

Search Google for results

ParametersJSON Schema

Name	Required	Description	Default
`q`	Yes	The query to search for
`gl`	No	The country to search in, e.g. us, uk, ca, au, etc.
`location`	No	The location to search in, e.g. San Francisco, CA, USA
`hl`	No	The language to search in, e.g. en, es, fr, de, etc.
`page`	No	The page number to return, first page is 1 (integer value as string)	1
`autocorrect`	No	Automatically correct (boolean value as string: 'true' or 'false')	true

TDQS

C2.2/5.0

Behavior2/5

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

With no annotations, the description must reveal behavioral traits. It only says 'Search Google' without clarifying that the tool targets scholarly content, nor does it mention pagination, rate limits, or result structure. This is insufficient for an agent to understand the tool's behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single short sentence, but it is under-specified rather than concise. It omits critical information about the tool's purpose and usage, making it ineffective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of 6 parameters and no output schema, the description fails to provide sufficient context about the tool's return values, result format, or how it differs from siblings. It is incomplete for an agent to use effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers all 6 parameters with descriptions, so the description does not need to add meaning. However, it does not clarify how parameters interact (e.g., country vs. location). 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.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Search Google for results' is vague and fails to distinguish this tool from sibling tools like 'google_search' which also searches Google. The name 'scholar' suggests academic content, but the description does not specify this, leading to ambiguity.

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

Usage Guidelines2/5

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 like 'google_search' or 'google_search_images'. The description lacks any context about the tool's specific domain (scholarly articles) or when it should be preferred.

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

google_search_shoppingD

Search Google for results

ParametersJSON Schema

Name	Required	Description	Default
`q`	Yes	The query to search for
`gl`	No	The country to search in, e.g. us, uk, ca, au, etc.
`location`	No	The location to search in, e.g. San Francisco, CA, USA
`hl`	No	The language to search in, e.g. en, es, fr, de, etc.
`page`	No	The page number to return, first page is 1 (integer value as string)	1
`autocorrect`	No	Automatically correct (boolean value as string: 'true' or 'false')	true
`num`	No	The number of results to return, max is 100 (integer value as string)	10

TDQS

D1.6/5.0

Behavior2/5

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

No annotations are present, so the description must fully cover behavioral traits. It states 'Search Google for results' which implies a read operation, but does not disclose any specifics about pagination, rate limits, or result structure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single short sentence, which is concise but at the expense of completeness and clarity. It sacrifices necessary detail for brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

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, many siblings, no output schema), the description is woefully inadequate. It does not explain what the tool returns or how to use it effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond the schema; it does not reference or clarify any parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description simply says 'Search Google for results', which is extremely generic. It does not mention shopping, products, or commerce, failing to clarify the tool's specific purpose relative to its name and siblings.

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

Usage Guidelines1/5

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 like google_search, google_search_shopping is not differentiated. The description offers no context about when to choose this tool.

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

google_search_videosC

Search Google for results

ParametersJSON Schema

Name	Required	Description	Default
`q`	Yes	The query to search for
`gl`	No	The country to search in, e.g. us, uk, ca, au, etc.
`location`	No	The location to search in, e.g. San Francisco, CA, USA
`hl`	No	The language to search in, e.g. en, es, fr, de, etc.
`page`	No	The page number to return, first page is 1 (integer value as string)	1
`tbs`	No	The time period to search in, e.g. d, w, m, y
`num`	No	The number of results to return, max is 100 (integer value as string)	10

TDQS

C2.2/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose behavior such as response format, pagination, or video-specific fields. The description carries the full burden but offers no detail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is too brief to be useful. While concise, it sacrifices necessary detail and does not front-load key information about the tool's specialization for videos.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and 7 parameters including pagination and filters, the description should explain return values and structure. It does not, leaving the agent without context on what to expect from the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the parameters are well-documented in the input schema. The description adds no extra meaning, but the schema already provides sufficient clarity for each parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Search Google for results' is vague and does not specify that this tool returns video results. Given sibling tools like google_search_images and google_search_news, it fails to differentiate what makes this tool unique to video searches.

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

Usage Guidelines2/5

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 other search tools (e.g., images, news). There is no mention of appropriate contexts or alternatives.

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

webpage_scrapeC

Scrape webpage by url

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	The url to scrape
`includeMarkdown`	No	Include markdown in the response (boolean value as string: 'true' or 'false')	false

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description must fully disclose behavior. It only states 'Scrape webpage by url' without mentioning what is scraped (e.g., text, full HTML), rate limits, authentication, or error handling. The includeMarkdown parameter hints at output format but is not explained in the description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single short sentence, efficiently conveying the core purpose without unnecessary words. It is appropriately frontloaded, but could benefit from slight expansion for clarity (e.g., 'extract content').

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (2 parameters, no output schema, no annotations), the description is incomplete. It does not describe the return format, any limits or constraints, or what constitutes a successful scrape. The optional 'includeMarkdown' parameter suggests Markdown output, but this is not confirmed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with descriptions for both 'url' and 'includeMarkdown'. The description adds no additional meaning beyond the schema, meeting the baseline of 3. No extra context is provided for parameter usage or constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Scrape webpage by url' clearly states the action (scrape) and resource (webpage by url). It distinguishes from sibling tools, which are all Google search related. However, it could be more specific about what 'scrape' entails (e.g., extract content, metadata).

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

Usage Guidelines2/5

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. Siblings are search tools, but the description does not explicitly state when scraping is preferred over searching. No exclusions or context for use are given.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

13 tool updatesv1.0.0Jan 3, 2026

Changedgoogle_search8 fields changed

changedInput schema / properties / num / default
```
Previous value: -10New value: +"10"
```

changedInput schema / properties / num / description

Previous value: -"The number of results to return, max is 100"New value: +"The number of results to return, max is 100 (integer value as string)"

removedInput schema / properties / num / maximum
```
Removed value: -100
```
addedInput schema / properties / num / pattern
```
Added value: +"^([1-9]|[1-9]\\d|100)$"
```

changedInput schema / properties / num / type

Previous value: -"integer"New value: +"string"

changedInput schema / properties / page / anyOf

Previous value: -[
-  {
-    "minimum": 1,
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "pattern": "^[1-9]\\d*$",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / page / default
```
Previous value: -1New value: +"1"
```

changedInput schema / properties / page / description

Previous value: -"The page number to return, first page is 1"New value: +"The page number to return, first page is 1 (integer value as string)"

Changedgoogle_search_autocomplete6 fields changed

changedInput schema / properties / autocorrect / anyOf

Previous value: -[
-  {
-    "type": "boolean"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "pattern": "^(true|false)$",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / autocorrect / default
```
Previous value: -trueNew value: +"true"
```

changedInput schema / properties / autocorrect / description

Previous value: -"Automatically correct"New value: +"Automatically correct (boolean value as string: 'true' or 'false')"

changedInput schema / properties / page / anyOf

Previous value: -[
-  {
-    "minimum": 1,
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "pattern": "^[1-9]\\d*$",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / page / default
```
Previous value: -1New value: +"1"
```

changedInput schema / properties / page / description

Previous value: -"The page number to return, first page is 1"New value: +"The page number to return, first page is 1 (integer value as string)"

Changedgoogle_search_images8 fields changed

changedInput schema / properties / num / default
```
Previous value: -10New value: +"10"
```

changedInput schema / properties / num / description

Previous value: -"The number of results to return, max is 100"New value: +"The number of results to return, max is 100 (integer value as string)"

removedInput schema / properties / num / maximum
```
Removed value: -100
```
addedInput schema / properties / num / pattern
```
Added value: +"^([1-9]|[1-9]\\d|100)$"
```

changedInput schema / properties / num / type

Previous value: -"integer"New value: +"string"

changedInput schema / properties / page / anyOf

Previous value: -[
-  {
-    "minimum": 1,
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "pattern": "^[1-9]\\d*$",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / page / default
```
Previous value: -1New value: +"1"
```

changedInput schema / properties / page / description

Previous value: -"The page number to return, first page is 1"New value: +"The page number to return, first page is 1 (integer value as string)"

Changedgoogle_search_maps3 fields changed

changedInput schema / properties / page / anyOf

Previous value: -[
-  {
-    "minimum": 1,
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "pattern": "^[1-9]\\d*$",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / page / default
```
Previous value: -1New value: +"1"
```

changedInput schema / properties / page / description

Previous value: -"The page number to return, first page is 1"New value: +"The page number to return, first page is 1 (integer value as string)"

Changedgoogle_search_news8 fields changed

changedInput schema / properties / num / default
```
Previous value: -10New value: +"10"
```

changedInput schema / properties / num / description

Previous value: -"The number of results to return, max is 100"New value: +"The number of results to return, max is 100 (integer value as string)"

removedInput schema / properties / num / maximum
```
Removed value: -100
```
addedInput schema / properties / num / pattern
```
Added value: +"^([1-9]|[1-9]\\d|100)$"
```

changedInput schema / properties / num / type

Previous value: -"integer"New value: +"string"

changedInput schema / properties / page / anyOf

Previous value: -[
-  {
-    "minimum": 1,
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "pattern": "^[1-9]\\d*$",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / page / default
```
Previous value: -1New value: +"1"
```

changedInput schema / properties / page / description

Previous value: -"The page number to return, first page is 1"New value: +"The page number to return, first page is 1 (integer value as string)"

Removedgoogle_search_parents
Addedgoogle_search_patents

Changedgoogle_search_places6 fields changed

changedInput schema / properties / autocorrect / anyOf

Previous value: -[
-  {
-    "type": "boolean"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "pattern": "^(true|false)$",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / autocorrect / default
```
Previous value: -trueNew value: +"true"
```

changedInput schema / properties / autocorrect / description

Previous value: -"Automatically correct"New value: +"Automatically correct (boolean value as string: 'true' or 'false')"

changedInput schema / properties / page / anyOf

Previous value: -[
-  {
-    "minimum": 1,
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "pattern": "^[1-9]\\d*$",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / page / default
```
Previous value: -1New value: +"1"
```

changedInput schema / properties / page / description

Previous value: -"The page number to return, first page is 1"New value: +"The page number to return, first page is 1 (integer value as string)"

Changedgoogle_search_reviews4 fields changed

removedInput schema / $defs

Removed value: -{
-  "ReviewSortBy": {
-    "enum": [
-      "mostRelevant",
-      "newest",
-      "highestRating",
-      "lowestRating"
-    ],
-    "title": "ReviewSortBy",
-    "type": "string"
-  }
-}

changedInput schema / properties / sortBy / anyOf

Previous value: -[
-  {
-    "$ref": "#/$defs/ReviewSortBy"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "pattern": "^(mostRelevant|newest|highestRating|lowestRating)$",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / sortBy / description

Previous value: -"The sort order to use"New value: +"The sort order to use (enum value as string: 'mostRelevant', 'newest', 'highestRating', 'lowestRating')"

addedInput schema / properties / sortBy / title
```
Added value: +"Sortby"
```

Changedgoogle_search_scholar6 fields changed

changedInput schema / properties / autocorrect / anyOf

Previous value: -[
-  {
-    "type": "boolean"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "pattern": "^(true|false)$",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / autocorrect / default
```
Previous value: -trueNew value: +"true"
```

changedInput schema / properties / autocorrect / description

Previous value: -"Automatically correct"New value: +"Automatically correct (boolean value as string: 'true' or 'false')"

changedInput schema / properties / page / anyOf

Previous value: -[
-  {
-    "minimum": 1,
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "pattern": "^[1-9]\\d*$",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / page / default
```
Previous value: -1New value: +"1"
```

changedInput schema / properties / page / description

Previous value: -"The page number to return, first page is 1"New value: +"The page number to return, first page is 1 (integer value as string)"

Changedgoogle_search_shopping11 fields changed

changedInput schema / properties / autocorrect / anyOf

Previous value: -[
-  {
-    "type": "boolean"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "pattern": "^(true|false)$",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / autocorrect / default
```
Previous value: -trueNew value: +"true"
```

changedInput schema / properties / autocorrect / description

Previous value: -"Automatically correct"New value: +"Automatically correct (boolean value as string: 'true' or 'false')"

changedInput schema / properties / num / default
```
Previous value: -10New value: +"10"
```

changedInput schema / properties / num / description

Previous value: -"The number of results to return, max is 100"New value: +"The number of results to return, max is 100 (integer value as string)"

removedInput schema / properties / num / maximum
```
Removed value: -100
```
addedInput schema / properties / num / pattern
```
Added value: +"^([1-9]|[1-9]\\d|100)$"
```

changedInput schema / properties / num / type

Previous value: -"integer"New value: +"string"

changedInput schema / properties / page / anyOf

Previous value: -[
-  {
-    "minimum": 1,
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "pattern": "^[1-9]\\d*$",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / page / default
```
Previous value: -1New value: +"1"
```

changedInput schema / properties / page / description

Previous value: -"The page number to return, first page is 1"New value: +"The page number to return, first page is 1 (integer value as string)"

Changedgoogle_search_videos8 fields changed

changedInput schema / properties / num / default
```
Previous value: -10New value: +"10"
```

changedInput schema / properties / num / description

Previous value: -"The number of results to return, max is 100"New value: +"The number of results to return, max is 100 (integer value as string)"

removedInput schema / properties / num / maximum
```
Removed value: -100
```
addedInput schema / properties / num / pattern
```
Added value: +"^([1-9]|[1-9]\\d|100)$"
```

changedInput schema / properties / num / type

Previous value: -"integer"New value: +"string"

changedInput schema / properties / page / anyOf

Previous value: -[
-  {
-    "minimum": 1,
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "pattern": "^[1-9]\\d*$",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / page / default
```
Previous value: -1New value: +"1"
```

changedInput schema / properties / page / description

Previous value: -"The page number to return, first page is 1"New value: +"The page number to return, first page is 1 (integer value as string)"

Changedwebpage_scrape4 fields changed

changedInput schema / properties / includeMarkdown / anyOf

Previous value: -[
-  {
-    "type": "boolean"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "pattern": "^(true|false)$",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / includeMarkdown / default
```
Previous value: -falseNew value: +"false"
```

addedInput schema / properties / includeMarkdown / description

Added value: +"Include markdown in the response (boolean value as string: 'true' or 'false')"

addedInput schema / properties / url / description
```
Added value: +"The url to scrape"
```

13 tool updatesAug 15, 2025
- First observedgoogle_search
- First observedgoogle_search_autocomplete
- First observedgoogle_search_images
- First observedgoogle_search_lens
- First observedgoogle_search_maps
- First observedgoogle_search_news
- First observedgoogle_search_parents
- First observedgoogle_search_places
- First observedgoogle_search_reviews
- First observedgoogle_search_scholar
- First observedgoogle_search_shopping
- First observedgoogle_search_videos
- First observedwebpage_scrape

Deploy Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

C2.6/5.0

Scored 2026-05-04 04:00 across 13 tools

Disambiguation5/5

Each tool targets a distinct search vertical (web, images, news, etc.) as indicated by the tool name, making them clearly distinguishable. The identical descriptions are a minor issue but do not cause ambiguity because the names are self-explanatory.

Naming Consistency4/5

All search tools follow a consistent 'google_search_<type>' pattern, but 'webpage_scrape' breaks this pattern with a different verb and structure, causing a slight inconsistency.

Tool Count5/5

13 tools is well within the recommended 3-15 range and covers the major Google search verticals plus scraping, which fits the server's purpose without being excessive.

Completeness4/5

The tool set covers most common search types (web, images, news, maps, etc.) and includes scraping. Minor omissions like books or finance searches exist but do not significantly hinder typical usage.

Maintenance

ActivityInactive

ResponsivenessUnresponsive

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Serper A
io.github.pipeworx-io
Serper MCP — wraps the Serper Google Search API (serper.dev)
Search RAG Systems
342
mcp-serpOAuth
io.github.AceDataCloud
MCP server for Google search results via SERP API
Search Browser Automation Web Scraping
21
mcp COAuth
com.wix
A Model Context Protocol server for Wix AI tools
Developer Tools Content Management Systems App Automation
216
hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237

Related MCP Servers

MCP Google Custom Search
RAG Systems Search
limklister
A
license
B
quality
D
maintenance
A Model Context Protocol server that enables LLMs to perform web searches using Google's Custom Search API through a standardized interface.
Updated a year ago (2025-10-12 15:46 UTC)
1
47
MIT
Scrapeless MCP Server
Search Browser Automation RAG Systems
scrapeless-ai
A
license
C
quality
C
maintenance
A Model Context Protocol server implementation that enables AI assistants like Claude to perform Google searches and retrieve web data directly through natural language requests.
Updated 5 days ago (2026-09-08 07:31 UTC)
1
120
168
MIT
Google Search MCP Server
Search Browser Automation
moritalous
A
license
Not graded
quality
D
maintenance
A Model Context Protocol server that enables AI assistants to perform web searches using Google Search API, returning up to 20 search results in JSON format.
Updated a year ago (2025-05-05 00:37 UTC)
2
Apache 2.0
Tavily Search MCP Server
Search RAG Systems
mwalker-tmd
F
license
C
quality
D
maintenance
A Model Context Protocol server that enables web search capabilities using the Tavily API, allowing AI models to retrieve current information from the internet through natural language commands.
Updated a year ago (2025-05-30 00:24 UTC)
3
-

Appeared in Searches

Using Google Search to Generate Answers

Servidor Serper MCP

Herramientas disponibles

Uso

Instalación mediante herrería

Uso de uv (recomendado)

Usando pip para el proyecto

Uso de pip para uso global

Depuración

Licencia

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Uso de `uv` (recomendado)

Usando `pip` para el proyecto

Uso de `pip` para uso global