Skip to main content
Glama
deenesjakoruzh
garylab

Serper MCP Server

by garylab
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Serper MCP サーバー

鍛冶屋のバッジ

Serper経由でGoogle検索を提供するモデルコンテキストプロトコルサーバー。このサーバーにより、LLMはGoogleから検索結果情報を取得できます。

利用可能なツール

Related MCP server: Scrapeless MCP Server

使用法

Smithery経由でインストール

Smithery経由で Claude Desktop 用の Serper MCP Server を自動的にインストールするには:

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

uvの使用（推奨）

  1. OS システムにuvがインストールされていることを確認してください。

  2. MCP クライアント コード構成またはClaude設定 (ファイルclaude_desktop_config.json ) に、 serper mcp サーバーを追加します。

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

    uvはpypi.orgからuvxを使用して mcp サーバーを自動的にダウンロードし、MCP クライアントに適用します。

プロジェクトにpipを使用する

  1. MCP クライアント コードのrequirements.txtファイルにserper-mcp-server追加します。

    serper-mcp-server

  2. 依存関係をインストールします。

    pip install -r requirements.txt

  3. クライアントの設定を追加します:

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

グローバル使用のためにpipを使用する

  1. pipまたはpip3 OS システム内にあることを確認してください。

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

  2. MCP クライアント コード構成またはClaude設定、 serper mcp サーバーを追加します。

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

デバッグ

uvxインスペクタを使用してサーバーをデバッグできます。UVXインストールの場合：

npx @modelcontextprotocol/inspector uvx serper-mcp-server

または、パッケージを特定のディレクトリにインストールした場合や、そのディレクトリで開発している場合は、次のようにします。

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

ライセンス

serper-mcp-server は MIT ライセンスに基づきライセンスされています。つまり、MIT ライセンスの条件に従って、ソフトウェアを自由に使用、改変、配布することができます。詳細については、プロジェクトリポジトリの LICENSE ファイルをご覧ください。

Available Tools

13 tools
google_search_autocompleteC

Search Google for results

ParametersJSON Schema
NameRequiredDescriptionDefault
qYesThe query to search for
glNoThe country to search in, e.g. us, uk, ca, au, etc.
locationNoThe location to search in, e.g. San Francisco, CA, USA
hlNoThe language to search in, e.g. en, es, fr, de, etc.
pageNoThe page number to return, first page is 1 (integer value as string)1
autocorrectNoAutomatically 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
NameRequiredDescriptionDefault
qYesThe query to search for
glNoThe country to search in, e.g. us, uk, ca, au, etc.
locationNoThe location to search in, e.g. San Francisco, CA, USA
hlNoThe language to search in, e.g. en, es, fr, de, etc.
pageNoThe page number to return, first page is 1 (integer value as string)1
tbsNoThe time period to search in, e.g. d, w, m, y
numNoThe 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
NameRequiredDescriptionDefault
urlYesThe url to search
glNoThe country to search in, e.g. us, uk, ca, au, etc.
hlNoThe 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
NameRequiredDescriptionDefault
qYesThe query to search for
llNoThe GPS position & zoom level
placeIdNoThe place ID to search in
cidNoThe CID to search in
glNoThe country to search in, e.g. us, uk, ca, au, etc.
hlNoThe language to search in, e.g. en, es, fr, de, etc.
pageNoThe 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
NameRequiredDescriptionDefault
qYesThe query to search for
glNoThe country to search in, e.g. us, uk, ca, au, etc.
locationNoThe location to search in, e.g. San Francisco, CA, USA
hlNoThe language to search in, e.g. en, es, fr, de, etc.
pageNoThe page number to return, first page is 1 (integer value as string)1
tbsNoThe time period to search in, e.g. d, w, m, y
numNoThe 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
NameRequiredDescriptionDefault
qYesThe query to search for
numNoThe number of results to return, max is 100 (integer value as string)10
pageNoThe 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
NameRequiredDescriptionDefault
qYesThe query to search for
glNoThe country to search in, e.g. us, uk, ca, au, etc.
locationNoThe location to search in, e.g. San Francisco, CA, USA
hlNoThe language to search in, e.g. en, es, fr, de, etc.
pageNoThe page number to return, first page is 1 (integer value as string)1
autocorrectNoAutomatically 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
NameRequiredDescriptionDefault
fidYesThe FID
cidNoThe CID to search in
placeIdNoThe place ID to search in
sortByNoThe sort order to use (enum value as string: 'mostRelevant', 'newest', 'highestRating', 'lowestRating')mostRelevant
topicIdNoThe topic ID to search in
nextPageTokenNoThe next page token to use
glNoThe country to search in, e.g. us, uk, ca, au, etc.
hlNoThe 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
NameRequiredDescriptionDefault
qYesThe query to search for
glNoThe country to search in, e.g. us, uk, ca, au, etc.
locationNoThe location to search in, e.g. San Francisco, CA, USA
hlNoThe language to search in, e.g. en, es, fr, de, etc.
pageNoThe page number to return, first page is 1 (integer value as string)1
autocorrectNoAutomatically 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
NameRequiredDescriptionDefault
qYesThe query to search for
glNoThe country to search in, e.g. us, uk, ca, au, etc.
locationNoThe location to search in, e.g. San Francisco, CA, USA
hlNoThe language to search in, e.g. en, es, fr, de, etc.
pageNoThe page number to return, first page is 1 (integer value as string)1
autocorrectNoAutomatically correct (boolean value as string: 'true' or 'false')true
numNoThe 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
NameRequiredDescriptionDefault
qYesThe query to search for
glNoThe country to search in, e.g. us, uk, ca, au, etc.
locationNoThe location to search in, e.g. San Francisco, CA, USA
hlNoThe language to search in, e.g. en, es, fr, de, etc.
pageNoThe page number to return, first page is 1 (integer value as string)1
tbsNoThe time period to search in, e.g. d, w, m, y
numNoThe 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
NameRequiredDescriptionDefault
urlYesThe url to scrape
includeMarkdownNoInclude 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.

  1. 13 tool updatesv1.0.0
    • 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"
  2. 13 tool updates
    • 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 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

Related MCP Connectors

Related MCP Servers

  • MCP Google Custom 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.
    1
    47
    MIT

  • Google Search MCP Server

    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.
    2
    Apache 2.0

  • Tavily Search MCP Server

    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.
    3
    -

Appeared in Searches