AceDataCloud API를 통해 SERP API를 사용하는 Model Context Protocol (MCP) 서버입니다.
Claude, VS Code 또는 MCP 호환 클라이언트에서 직접 Google 검색을 수행하고 구조화된 결과를 얻을 수 있습니다.
웹 검색 - 구조화된 결과를 제공하는 일반 Google 웹 검색
이미지 검색 - URL 및 썸네일이 포함된 이미지 검색
뉴스 검색 - 모든 주제에 대한 최신 뉴스 기사 검색
비디오 검색 - YouTube 및 기타 소스의 비디오 찾기
장소 검색 - 지역 업체 및 장소 검색
지도 검색 - 위치 및 지리 정보 찾기
지식 그래프 - 구조화된 엔티티 정보 가져오기
지역화 - 여러 국가 및 언어 지원
시간 필터링 - 시간 범위별 결과 필터링
Related MCP server: SerpApi MCP Server
도구 | 설명 |
| Google을 검색하고 SERP API를 사용하여 구조화된 결과를 가져옵니다. |
| Google 이미지를 검색하고 이미지 결과를 가져옵니다. |
| Google 뉴스를 검색하고 뉴스 기사 결과를 가져옵니다. |
| Google 비디오를 검색하고 비디오 결과를 가져옵니다. |
| 지역 장소 및 업체를 위해 Google을 검색합니다. |
| 위치를 위해 Google 지도를 검색합니다. |
| 사용 가능한 모든 Google 검색 유형을 나열합니다. |
| Google 검색에 일반적으로 사용되는 국가 코드를 나열합니다. |
| Google 검색에 일반적으로 사용되는 언어 코드를 나열합니다. |
| Google 검색에 사용 가능한 시간 범위 필터를 나열합니다. |
| Google SERP 도구 사용을 위한 포괄적인 가이드를 가져옵니다. |
AceDataCloud 플랫폼에 가입합니다.
API 문서 페이지로 이동합니다.
**"Acquire"**를 클릭하여 API 토큰을 받습니다.
아래에서 사용할 토큰을 복사합니다.
AceDataCloud는 관리형 MCP 서버를 호스팅하며, 로컬 설치가 필요하지 않습니다.
엔드포인트: https://serp.mcp.acedata.cloud/mcp
모든 요청에는 Bearer 토큰이 필요합니다. 1단계에서 받은 API 토큰을 사용하세요.
OAuth를 사용하여 Claude.ai에 직접 연결하세요. API 토큰이 필요하지 않습니다:
Claude.ai 설정 → 통합 → 더 추가하기로 이동합니다.
서버 URL 입력: https://serp.mcp.acedata.cloud/mcp
OAuth 로그인 흐름을 완료합니다.
대화에서 도구 사용을 시작합니다.
설정 파일(~/Library/Application Support/Claude/claude_desktop_config.json, macOS 기준)에 추가하세요:
{
"mcpServers": {
"serp": {
"type": "streamable-http",
"url": "https://serp.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}MCP 설정(.cursor/mcp.json 또는 .windsurf/mcp.json)에 추가하세요:
{
"mcpServers": {
"serp": {
"type": "streamable-http",
"url": "https://serp.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}VS Code MCP 설정(.vscode/mcp.json)에 추가하세요:
{
"servers": {
"serp": {
"type": "streamable-http",
"url": "https://serp.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}또는 VS Code용 Ace Data Cloud MCP 확장 프로그램을 설치하세요. 15개의 모든 MCP 서버를 클릭 한 번으로 설정할 수 있습니다.
**설정 → 도구 → AI Assistant → Model Context Protocol (MCP)**로 이동합니다.
추가 → HTTP를 클릭합니다.
붙여넣기:
{
"mcpServers": {
"serp": {
"url": "https://serp.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}Claude Code는 MCP 서버를 기본적으로 지원합니다:
claude mcp add serp --transport http https://serp.mcp.acedata.cloud/mcp \
-h "Authorization: Bearer YOUR_API_TOKEN"또는 프로젝트의 .mcp.json에 추가하세요:
{
"mcpServers": {
"serp": {
"type": "streamable-http",
"url": "https://serp.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}Cline의 MCP 설정(.cline/mcp_settings.json)에 추가하세요:
{
"mcpServers": {
"serp": {
"type": "streamable-http",
"url": "https://serp.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}MCP 구성에 추가하세요:
{
"mcpServers": {
"serp": {
"type": "streamable-http",
"url": "https://serp.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}Roo Code MCP 설정에 추가하세요:
{
"mcpServers": {
"serp": {
"type": "streamable-http",
"url": "https://serp.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}.continue/config.yaml에 추가하세요:
mcpServers:
- name: serp
type: streamable-http
url: https://serp.mcp.acedata.cloud/mcp
headers:
Authorization: "Bearer YOUR_API_TOKEN"Zed 설정(~/.config/zed/settings.json)에 추가하세요:
{
"language_models": {
"mcp_servers": {
"serp": {
"url": "https://serp.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}
}# Health check (no auth required)
curl https://serp.mcp.acedata.cloud/health
# MCP initialize
curl -X POST https://serp.mcp.acedata.cloud/mcp \
-H "Content-Type: application/json" \
-H "Accept: application/json" \
-H "Authorization: Bearer YOUR_API_TOKEN" \
-d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"test","version":"1.0"}}}'자신의 컴퓨터에서 서버를 실행하려는 경우:
# Install from PyPI
pip install mcp-serp
# or
uvx mcp-serp
# Set your API token
export ACEDATACLOUD_API_TOKEN="your_token_here"
# Run (stdio mode for Claude Desktop / local clients)
mcp-serp
# Run (HTTP mode for remote access)
mcp-serp --transport http --port 8000{
"mcpServers": {
"serp": {
"command": "uvx",
"args": ["mcp-serp"],
"env": {
"ACEDATACLOUD_API_TOKEN": "your_token_here"
}
}
}
}docker pull ghcr.io/acedatacloud/mcp-serp:latest
docker run -p 8000:8000 ghcr.io/acedatacloud/mcp-serp:latest클라이언트는 자신의 Bearer 토큰으로 연결하며, 서버는 각 요청의 Authorization 헤더에서 토큰을 추출합니다.
도구 | 설명 |
| 모든 옵션을 포함한 유연한 Google 검색 |
| 이미지 검색 |
| 뉴스 기사 검색 |
| 비디오 검색 |
| 지역 장소/업체 검색 |
| 지도 위치 검색 |
도구 | 설명 |
| 사용 가능한 검색 유형 나열 |
| 지역화를 위한 국가 코드 나열 |
| 지역화를 위한 언어 코드 나열 |
| 시간 범위 필터 옵션 나열 |
| 포괄적인 사용 가이드 가져오기 |
User: Search for information about artificial intelligence
Claude: I'll search for information about AI.
[Calls serp_google_search with query="artificial intelligence"]User: What's the latest news about technology?
Claude: I'll search for recent tech news.
[Calls serp_google_news with query="technology", time_range="qdr:d"]User: Find popular restaurants in Tokyo
Claude: I'll search for restaurants in Tokyo.
[Calls serp_google_places with query="popular restaurants Tokyo", country="jp"]User: Find images of the Northern Lights
Claude: I'll search for aurora borealis images.
[Calls serp_google_images with query="Northern Lights aurora borealis"]유형 | 설명 |
| 일반 웹 검색 (기본값) |
| 이미지 검색 |
| 뉴스 기사 |
| 지도 결과 |
| 지역 업체 |
| 비디오 결과 |
코드 | 시간 범위 |
| 지난 1시간 |
| 지난 1일 |
| 지난 1주 |
| 지난 1개월 |
코드 | 국가 |
| 미국 |
| 영국 |
| 중국 |
| 일본 |
| 독일 |
| 프랑스 |
코드 | 언어 |
| 영어 |
| 중국어 (간체) |
| 일본어 |
| 스페인어 |
| 프랑스어 |
| 독일어 |
knowledge_graph: 엔티티 정보 (회사, 인물 등)
answer_box: 직접적인 답변
organic: 제목, 링크, 스니펫이 포함된 일반 검색 결과
people_also_ask: 관련 질문
related_searches: 관련 쿼리
images: URL 및 썸네일이 포함된 이미지 결과
news: 출처 및 날짜가 포함된 뉴스 기사
변수 | 설명 | 기본값 |
| AceDataCloud의 API 토큰 | 필수 |
| API 기본 URL |
|
| OAuth 클라이언트 ID (호스팅 모드) | — |
| 플랫폼 기본 URL |
|
| 요청 시간 제한 (초) |
|
| 로깅 레벨 |
|
mcp-serp --help
Options:
--version Show version
--transport Transport mode: stdio (default) or http
--port Port for HTTP transport (default: 8000)# Clone repository
git clone https://github.com/AceDataCloud/SerpMCP.git
cd SerpMCP
# Create virtual environment
python -m venv .venv
source .venv/bin/activate # or `.venv\Scripts\activate` on Windows
# Install with dev dependencies
pip install -e ".[dev,test]"# Run unit tests
pytest
# Run with coverage
pytest --cov=core --cov=tools
# Run integration tests (requires API token)
pytest tests/test_integration.py -m integration# Format code
ruff format .
# Lint code
ruff check .
# Type check
mypy core tools# Install build dependencies
pip install -e ".[release]"
# Build package
python -m build
# Upload to PyPI
twine upload dist/*SerpMCP/
├── core/ # Core modules
│ ├── __init__.py
│ ├── client.py # HTTP client for SERP API
│ ├── config.py # Configuration management
│ ├── exceptions.py # Custom exceptions
│ └── server.py # MCP server initialization
├── tools/ # MCP tool definitions
│ ├── __init__.py
│ ├── search_tools.py # Search tools
│ └── info_tools.py # Information tools
├── prompts/ # MCP prompt templates
│ └── __init__.py
├── tests/ # Test suite
│ ├── conftest.py
│ ├── test_client.py
│ └── test_config.py
├── deploy/ # Deployment configs
│ └── production/
│ ├── deployment.yaml
│ ├── ingress.yaml
│ └── service.yaml
├── .env.example # Environment template
├── .gitignore
├── CHANGELOG.md
├── Dockerfile # Docker image for HTTP mode
├── docker-compose.yaml # Docker Compose config
├── LICENSE
├── main.py # Entry point
├── pyproject.toml # Project configuration
└── README.md이 서버는 AceDataCloud Google SERP API를 래핑합니다:
기여를 환영합니다! 다음 단계를 따라주세요:
저장소를 포크합니다.
기능 브랜치를 생성합니다 (git checkout -b feature/amazing).
변경 사항을 커밋합니다 (git commit -m 'Add amazing feature').
브랜치에 푸시합니다 (git push origin feature/amazing).
Pull Request를 엽니다.
MIT 라이선스 - 자세한 내용은 LICENSE를 참조하세요.
AceDataCloud에서 사랑을 담아 제작함
Get a comprehensive guide for using the Google SERP tools.
Provides detailed information on how to use the SERP search tools
effectively, including parameters, examples, and best practices.
Returns:
Complete usage guide for SERP tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It discloses that the tool returns a guide with detailed information, which is adequate for a read-only informational tool. However, it does not mention any limitations (e.g., output length, rate limits).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the purpose. It uses clear structure (overview, details, return description) without unnecessary words. Minor improvement possible by tightening the second paragraph.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and the presence of an output schema, the description covers the essential purpose and content of the tool. It is complete enough for an agent to understand when to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, meeting the baseline of 4. The description adds value by describing the content of the output (parameters, examples, best practices), which goes beyond what the empty schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool provides a comprehensive guide for using Google SERP tools, including parameters, examples, and best practices. This distinctly differentiates it from sibling tools that perform actual searches or list data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this guide should be consulted before using other SERP tools, but it does not explicitly state when to use it vs. alternatives. The context is clear, but exclusions or when-not-to-use guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Google Images and get image results.
Performs a Google Image search and returns structured image results.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for pagination (default: 1). | |
| query | Yes | The search query string for image search. Required. | |
| number | No | Number of results per page (default: 10). Note: More than 10 results may incur additional credits. | |
| country | No | Country code for localized results (e.g., 'us', 'cn', 'uk'). Default is 'us'. | |
| language | No | Language code for results (e.g., 'en', 'zh-cn', 'fr'). Default is 'en'. | |
| image_size | No | Image size filter for image search. Options: large, medium, icon, 2mp, 4mp, 6mp, 8mp, 10mp, 12mp, 15mp, 20mp, 40mp, 70mp. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'returns structured image results,' which is a basic outcome but does not mention pagination behavior, credit implications, or any quirks such as rate limits or result metadata format. The description adds minimal value beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the main verb and resource. It is efficient and has no redundant filler. However, it is somewhat tautological ('Search Google Images and get image results' restates the tool name), but for conciseness this is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and fully documented parameters, the description is incomplete for a tool with six parameters and no annotations. It lacks guidance on typical use cases, interaction with filters, pagination, or credit costs (though schema mentions credits). The description is too sparse to provide the agent with a complete behavioral picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning all six parameters are already documented with meanings (e.g., 'country' for localized results, 'image_size' for filtering). The description itself adds no parameter details, so the baseline of 3 is appropriate. The schema does the heavy lifting, and no additional value is contributed by the prose description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Search Google Images and get image results' and 'Performs a Google Image search and returns structured image results.' This clearly identifies the tool's function (searching images) and differentiates it from sibling tools like serp_google_search (web search) and serp_google_news. It could be more explicit about the 'image-specific' nature, but the resource and verb are clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that this is for image results specifically, nor does it reference sibling tools or exclusions. The usage context is only implied by the tool name and generic description, leaving the agent to infer when to choose this over other search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Google Maps for locations.
Performs a Google Maps search and returns structured map results.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for pagination (default: 1). | |
| query | Yes | The search query string for maps/location search. Required. | |
| number | No | Number of results per page (default: 10). Note: More than 10 results may incur additional credits. | |
| country | No | Country code for localized results (e.g., 'us', 'cn', 'uk'). Default is 'us'. | |
| language | No | Language code for results (e.g., 'en', 'zh-cn', 'fr'). Default is 'en'. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It only mentions 'returns structured map results' but fails to mention pagination, rate limits, cost implications, or any side effects. The schema notes that more than 10 results may incur additional credits, but this is not reflected 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, front-loaded with the main action. The second sentence adds clarity about output format but is somewhat redundant with the first. Overall, it is well-structured and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, output schema), the description is adequate for basic understanding but lacks usage context and differentiation from siblings. It also omits behavioral details like pagination and credit usage that would help an agent select and invoke the tool correctly without relying solely on the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions, so the description adds no value beyond the schema. The description does not explain how parameters like country or language affect results, but the schema already handles this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb and resource: 'Search Google Maps for locations.' This distinguishes it from sibling tools like google_search and google_images, which target other result types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through the description ('Search Google Maps for locations'), but there is no explicit guidance on when to use this tool versus alternatives such as google_places or google_search. No use cases or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Google News and get news article results.
Performs a Google News search and returns structured news results.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for pagination (default: 1). | |
| query | Yes | The search query string for news search. Required. | |
| number | No | Number of results per page (default: 10). Note: More than 10 results may incur additional credits. | |
| country | No | Country code for localized results (e.g., 'us', 'cn', 'uk'). Default is 'us'. | |
| language | No | Language code for results (e.g., 'en', 'zh-cn', 'fr'). Default is 'en'. | |
| time_range | No | Time filter for results. Options: 'h'/'qdr:h' (past hour), 'd'/'qdr:d' (past day), 'w'/'qdr:w' (past week), 'm'/'qdr:m' (past month), 'y'/'qdr:y' (past year), or None for no time restriction (default). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral transparency. It only adds that results are 'structured news results,' which is a minimal behavioral hint. It does not disclose pagination behavior, credit implications, default country/language behavior, or any side effects, leaving a significant gap for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences and front-loaded with the core purpose. However, the second sentence ('Performs a Google News search...') largely restates the first, making it slightly redundant. It is still concise and easy to scan, but not zero-waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having six parameters and several sibling search tools, the description is under-specified. It omits mention of localization options (country/language), time range filtering, and any nuances of Google News vs. general web search. The output schema exists, but the narrative context is minimal and does not help the agent understand when or how to fully leverage the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all six parameters, covering meaning, defaults, and constraints (e.g., 'number' notes additional credits beyond 10). Since schema_description_coverage is 100%, the description does not need to compensate, and it adds no extra parameter information beyond restating the tool's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool performs a Google News search and returns news article results, specifying both the verb ('search') and the resource ('Google News'). This clearly distinguishes it from sibling tools like serp_google_search or serp_google_images, even though the two sentences are slightly redundant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied by the tool name and description—use for Google News searches—but there is no explicit guidance on when to choose this over sibling tools or any exclusions. No alternatives are mentioned, leaving the agent to infer the use case without clear direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Google for local places and businesses.
Performs a Google Places search and returns structured place results.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for pagination (default: 1). | |
| query | Yes | The search query string for local places/businesses search. Required. | |
| number | No | Number of results per page (default: 10). Note: More than 10 results may incur additional credits. | |
| country | No | Country code for localized results (e.g., 'us', 'cn', 'uk'). Default is 'us'. | |
| language | No | Language code for results (e.g., 'en', 'zh-cn', 'fr'). Default is 'en'. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only mentions that it 'returns structured place results,' but does not disclose pagination behavior, default country/language, credit implications, or any other operational characteristics. Minimal value beyond the function itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, with the main action front-loaded in the first sentence. The second sentence is somewhat redundant with the first, but the overall length is appropriate and there is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 params, required query, no annotations) and the existence of sibling tools like serp_google_maps, the description is incomplete. It lacks usage guidance and behavioral details, though the output schema presumably covers return values. The description alone does not provide enough context for an agent to choose this tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, as all five parameters have descriptions in the input schema. The tool description itself adds no parameter-level detail beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Search') and resource ('local places and businesses'), and notes it returns structured place results. This distinguishes it from general web search or image search, though it does not explicitly compare to the similar serp_google_maps tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like serp_google_search or serp_google_maps. The description only states what it does, without context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Google and get structured results using the SERP API.
Performs a Google search and returns the complete JSON response from the API,
preserving all available fields and data.
Args:
query: The search query string. Required.
search_type: Type of search to perform. Options:
- "search": Regular web search (default)
- "images": Image search
- "news": News articles
- "maps": Map results
- "places": Local business/place results
- "videos": Video results
country: Country code for localized results (e.g., "us", "cn", "uk").
Default is "us".
language: Language code for results (e.g., "en", "zh-cn", "fr").
Default is "en".
time_range: Time filter for results. Options:
- "qdr:h": Past hour
- "qdr:d": Past day
- "qdr:w": Past week
- "qdr:m": Past month
- None: No time restriction (default)
number: Number of results per page (default: 10).
Note: More than 10 results may incur additional credits.
page: Page number for pagination (default: 1).
Returns:
Complete JSON response from the SERP API containing all available data.
Example:
serp_google_search(query="artificial intelligence", search_type="news")
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for pagination (default: 1). | |
| query | Yes | The search query string. Required. | |
| number | No | Number of results per page (default: 10). Note: More than 10 results may incur additional credits. | |
| country | No | Country code for localized results (e.g., 'us', 'cn', 'uk'). Default is 'us'. | |
| language | No | Language code for results (e.g., 'en', 'zh-cn', 'fr'). Default is 'en'. | |
| image_size | No | Image size filter. Only valid when search_type is 'images'. Options: large, medium, icon, 2mp, 4mp, 6mp, 8mp, 10mp, 12mp, 15mp, 20mp, 40mp, 70mp. | |
| time_range | No | Time filter for results. Options: 'h'/'qdr:h' (past hour), 'd'/'qdr:d' (past day), 'w'/'qdr:w' (past week), 'm'/'qdr:m' (past month), 'y'/'qdr:y' (past year), or None for no time restriction (default). | |
| search_type | No | Type of search to perform. Options: 'search' (regular web search, default), 'images' (image search), 'news' (news articles), 'maps' (map results), 'places' (local business/place results), 'videos' (video results). | search |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that it returns the complete JSON response preserving all fields and warns about additional credits for number >10. However, it does not explicitly state read-only behavior, rate limits, or error handling. This is adequate but not comprehensive for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with Args, Returns, and Example sections, making it easy to scan. However, it redundantly repeats the schema's parameter descriptions, extending the length without adding much new information. The example is useful, but the duplication lowers the efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, full schema coverage, and an output schema), the description covers all essential aspects: purpose, parameters, return format, and an example. The only notable omission is the lack of guidance on sibling tools, but the description is otherwise complete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% description coverage for all 8 parameters. The tool description largely duplicates these descriptions, but adds a concrete example and a credit warning for the 'number' parameter. This adds marginal value beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search Google and get structured results using the SERP API' with a specific verb and resource. It also enumerates search types (web, images, news, etc.), distinguishing it from generic API tools. However, it does not explicitly differentiate from the specialized sibling tools like serp_google_images or serp_google_news, so it misses the full 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the specialized sibling tools (serp_google_images, serp_google_news, etc.). It implies generality through the search_type parameter but does not mention alternatives, exclusions, or when to choose a sibling. This lack of comparative guidance leaves the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Google Videos and get video results.
Performs a Google Video search and returns structured video results.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for pagination (default: 1). | |
| query | Yes | The search query string for video search. Required. | |
| number | No | Number of results per page (default: 10). Note: More than 10 results may incur additional credits. | |
| country | No | Country code for localized results (e.g., 'us', 'cn', 'uk'). Default is 'us'. | |
| language | No | Language code for results (e.g., 'en', 'zh-cn', 'fr'). Default is 'en'. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'returns structured video results,' which is minimal and does not disclose behavioral traits such as pagination behavior, potential rate limits, or any caveats about result content. This falls short for a search tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, but the second sentence largely restates the first ('Performs a Google Video search and returns structured video results' vs 'Search Google Videos and get video results'). This redundancy means it is not maximally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with a comprehensive input schema and an output schema indicated, the description covers the core purpose and return type. It could add usage context, but the structured fields already provide parameter and result details, making it adequate overall.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all five parameters (query, page, number, country, language). The description adds no extra parameter meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a Google Video search and returns structured video results. The verb 'search' and resource 'Google Videos' are specific, and it distinguishes from sibling tools like serp_google_images or serp_google_news.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: the tool is for searching Google Videos. However, it does not explicitly mention when to prefer this over alternatives or provide any exclusions. The context signals list sibling search tools, but the description offers no comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List commonly used country codes for Google search.
Shows common country codes that can be used to localize search results.
Returns:
Table of country codes and their countries.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description honestly states that the tool returns a table of country codes, implying a read-only operation. It is straightforward and does not hide any behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loads the purpose, and includes a return description. Every sentence is relevant and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an output schema, the description is largely complete. It could mention the output format or that it lists only 'common' codes, but overall it suffices for the simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description cannot add meaning beyond the schema. Per guidelines, this is a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states verb ('list'/'shows') and resource ('country codes for Google search'), and it is distinct from sibling tools that list other types (languages, search types, time ranges).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the purpose is clear, the description provides no explicit guidance on when to use this tool over its siblings or when not to use it. The usage context is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List commonly used language codes for Google search.
Shows common language codes that can be used to get results in specific languages.
Returns:
Table of language codes and their languages.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description only states that it returns a table of language codes and languages. It omits potential behavioral traits such as whether the list is exhaustive, if it requires authentication, or any rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with only two short sentences and a returns line, conveying the purpose and output without any unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an output schema, the description covers the essential information: what the tool does and what it returns. It is self-contained and clear, though it could briefly address when to use it among sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. The description adds no parameter information, but this is acceptable as the baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists commonly used language codes for Google search, specifying the verb and resource. It differentiates from sibling listing tools like serp_list_countries by focusing on languages, but does not explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing language codes for search localization, but it lacks explicit guidance on when to use this tool versus alternatives like serp_list_countries or serp_list_time_ranges.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available Google search types.
Shows all available search types and their use cases.
Use this to understand which search type to use for your query.
Returns:
Table of all search types with descriptions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description mentions it returns a table of search types with descriptions, which is adequate. It does not disclose potential side effects or permissions, but given the read-only nature, it is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, clearly stating the action, purpose, and return value. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and includes an output schema, the description is complete. It explains the purpose, usage context, and output format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters and the input schema has 100% coverage. The description does not need to add parameter information; a baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all available Google search types with their use cases. It distinguishes itself from sibling tools that perform specific searches by serving as a preliminary reference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using this tool to understand which search type to use, implying it is a pre-step to other search tools. It does not explicitly state when not to use, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available time range filters for Google search.
Shows all time range options that can be used to filter results by date.
Returns:
Table of time range codes and their meanings.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses that the tool returns a table of codes and meanings, and the verb 'List' implies a read-only operation. However, it lacks details on whether the list is static or dynamic, or if any authentication is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the key action, and contains no superfluous words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, has output schema), the description is complete. It states the purpose, the scope, and the return format, which is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and schema description coverage is 100% implicitly. The description does not need to add parameter details. The baseline for 0 parameters is 4, and the description meets that adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists available time range filters for Google search, with a specific verb 'List' and a well-defined resource. It distinguishes itself from sibling tools like serp_google_search and serp_list_countries by focusing on time range options.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing time range filters, but does not explicitly state when to use this tool versus alternatives, such as before invoking serp_google_search. No when-not or exclusion guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.49serp_google_images8 fields changedInput schema / properties / country / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maxLength": 32,
+ "minLength": 1,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / image_sizeAdded value: +{
+ "anyOf": [
+ {
+ "enum": [
+ "large",
+ "medium",
+ "icon",
+ "2mp",
+ "4mp",
+ "6mp",
+ "8mp",
+ "10mp",
+ "12mp",
+ "15mp",
+ "20mp",
+ "40mp",
+ "70mp"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Image size filter for image search. Options: large, medium, icon, 2mp, 4mp, 6mp, 8mp, 10mp, 12mp, 15mp, 20mp, 40mp, 70mp.",
+ "title": "Image Size"
+}Input schema / properties / language / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maxLength": 32,
+ "minLength": 1,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / number / anyOfPrevious value: -[
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maximum": 100,
+ "minimum": 1,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / page / anyOfPrevious value: -[
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maximum": 100,
+ "minimum": 1,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / query / maxLengthAdded value: +2048Input schema / properties / query / minLengthAdded value: +1Input schema / properties / query / patternAdded value: +".*\\S.*"serp_google_maps7 fields changedInput schema / properties / country / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maxLength": 32,
+ "minLength": 1,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / language / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maxLength": 32,
+ "minLength": 1,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / number / anyOfPrevious value: -[
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maximum": 100,
+ "minimum": 1,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / page / anyOfPrevious value: -[
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maximum": 100,
+ "minimum": 1,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / query / maxLengthAdded value: +2048Input schema / properties / query / minLengthAdded value: +1Input schema / properties / query / patternAdded value: +".*\\S.*"serp_google_news9 fields changedInput schema / properties / country / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maxLength": 32,
+ "minLength": 1,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / language / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maxLength": 32,
+ "minLength": 1,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / number / anyOfPrevious value: -[
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maximum": 100,
+ "minimum": 1,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / page / anyOfPrevious value: -[
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maximum": 100,
+ "minimum": 1,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / query / maxLengthAdded value: +2048Input schema / properties / query / minLengthAdded value: +1Input schema / properties / query / patternAdded value: +".*\\S.*"Input schema / properties / time_range / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "enum": [
+ "h",
+ "d",
+ "w",
+ "m",
+ "y",
+ "qdr:h",
+ "qdr:d",
+ "qdr:w",
+ "qdr:m",
+ "qdr:y"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / time_range / descriptionPrevious value: -"Time filter for results. Options: 'qdr:h' (past hour), 'qdr:d' (past day), 'qdr:w' (past week), 'qdr:m' (past month), or None for no time restriction (default)."New value: +"Time filter for results. Options: 'h'/'qdr:h' (past hour), 'd'/'qdr:d' (past day), 'w'/'qdr:w' (past week), 'm'/'qdr:m' (past month), 'y'/'qdr:y' (past year), or None for no time restriction (default)."serp_google_places7 fields changedInput schema / properties / country / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maxLength": 32,
+ "minLength": 1,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / language / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maxLength": 32,
+ "minLength": 1,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / number / anyOfPrevious value: -[
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maximum": 100,
+ "minimum": 1,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / page / anyOfPrevious value: -[
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maximum": 100,
+ "minimum": 1,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / query / maxLengthAdded value: +2048Input schema / properties / query / minLengthAdded value: +1Input schema / properties / query / patternAdded value: +".*\\S.*"serp_google_search10 fields changedInput schema / properties / country / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maxLength": 32,
+ "minLength": 1,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / image_sizeAdded value: +{
+ "anyOf": [
+ {
+ "enum": [
+ "large",
+ "medium",
+ "icon",
+ "2mp",
+ "4mp",
+ "6mp",
+ "8mp",
+ "10mp",
+ "12mp",
+ "15mp",
+ "20mp",
+ "40mp",
+ "70mp"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Image size filter. Only valid when search_type is 'images'. Options: large, medium, icon, 2mp, 4mp, 6mp, 8mp, 10mp, 12mp, 15mp, 20mp, 40mp, 70mp.",
+ "title": "Image Size"
+}Input schema / properties / language / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maxLength": 32,
+ "minLength": 1,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / number / anyOfPrevious value: -[
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maximum": 100,
+ "minimum": 1,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / page / anyOfPrevious value: -[
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maximum": 100,
+ "minimum": 1,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / query / maxLengthAdded value: +2048Input schema / properties / query / minLengthAdded value: +1Input schema / properties / query / patternAdded value: +".*\\S.*"Input schema / properties / time_range / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "enum": [
+ "h",
+ "d",
+ "w",
+ "m",
+ "y",
+ "qdr:h",
+ "qdr:d",
+ "qdr:w",
+ "qdr:m",
+ "qdr:y"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / time_range / descriptionPrevious value: -"Time filter for results. Options: 'qdr:h' (past hour), 'qdr:d' (past day), 'qdr:w' (past week), 'qdr:m' (past month), or None for no time restriction (default)."New value: +"Time filter for results. Options: 'h'/'qdr:h' (past hour), 'd'/'qdr:d' (past day), 'w'/'qdr:w' (past week), 'm'/'qdr:m' (past month), 'y'/'qdr:y' (past year), or None for no time restriction (default)."serp_google_videos7 fields changedInput schema / properties / country / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maxLength": 32,
+ "minLength": 1,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / language / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maxLength": 32,
+ "minLength": 1,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / number / anyOfPrevious value: -[
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maximum": 100,
+ "minimum": 1,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / page / anyOfPrevious value: -[
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maximum": 100,
+ "minimum": 1,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / query / maxLengthAdded value: +2048Input schema / properties / query / minLengthAdded value: +1Input schema / properties / query / patternAdded value: +".*\\S.*"v0.1.46serp_get_usage_guideserp_google_imagesserp_google_mapsserp_google_newsserp_google_placesserp_google_searchserp_google_videosserp_list_countriesserp_list_languagesserp_list_search_typesserp_list_time_rangesv0.1.45serp_get_usage_guideserp_google_imagesserp_google_mapsserp_google_newsserp_google_placesserp_google_searchserp_google_videosserp_list_countriesserp_list_languagesserp_list_search_typesserp_list_time_rangesScored across 11 tools
Most tools are clearly distinct (search types, countries, languages, time ranges, usage guide), but serp_google_search with search_type='images' overlaps with serp_google_images, and similarly for news/videos/places/maps. The generic search tool's search_type parameter makes the dedicated tools somewhat redundant, though the dedicated ones likely return more structured results.
All tools follow a consistent serp_ prefix with verb_noun naming (serp_list_*, serp_google_*, serp_get_*). Minor inconsistency: serp_get_usage_guide uses 'get' while others use 'list' or 'google', but the pattern is still highly predictable.
11 tools is a reasonable count for a SERP API server. However, the dedicated search tools (images, news, videos, places, maps) overlap with the search_type parameter in serp_google_search, so a few could be consolidated without losing functionality.
The server covers the main Google search verticals (web, images, news, videos, places, maps) plus supporting metadata tools (countries, languages, time ranges, search types, usage guide). Missing obvious search types like scholar or shopping, but the core SERP use cases are well covered.
One MCP server that gives your AI agent search, AI answer, social, ad and lead data.
Live Google Maps business search, review, and photo data for AI agents over MCP.
Your agent needs the Google results page as it actually renders — organic and paid, the AI overview, maps, images, news, jobs and the finance panel — not a scraped guess. **What you can ask for** • "What does the SERP for this keyword look like in Germany, on mobile?" • "Does this query trigger an AI overview, and what does it say?" • "Who is advertising against our brand name?" • "Find local results and the map pack for this phrase." • "Search Google by this image and tell me where else it appears." **How to use it** Point any MCP client at https://mcp.aisa.one/seo-serp/mcp and sign in with OAuth — there is no key to create or paste. 38 tools across Google's surfaces: organic, ads and advertisers, AI mode, autocomplete, images, news, maps and local, events, jobs, datasets, scholar, finance quotes and markets, plus Semrush's organic and paid result sets. **Why this rather than the source** Location and language are parameters, so you can read the page a customer in another country sees. **It is also a door to the rest** The same login reaches 26 sources and 580+ operations. Read the SERP here, then ask the same agent who links to the winner or how much traffic they get — without adding a second server. **What it costs** Finding and inspecting an operation is free. Running one is billed per call at API prices, with no seat and no monthly minimum, and every call takes max_price_usd so an agent cannot overspend by accident. **Where else it reaches** https://mcp.aisa.one/seo-serp-other-engines/mcp for Bing, Yahoo, Baidu, Naver, Seznam and YouTube. https://mcp.aisa.one/seo/mcp for all of it at once — rankings, keywords, backlinks, site health and AI-answer visibility across DataForSEO, Semrush and Ahrefs.
Official SerpApi MCP server for Google, Bing, and other search engines.
