Enables searching Google Maps for places and services, retrieving Google Maps reviews, searching for Google Flights information, querying flight calendar prices, searching for Google Hotels information and property details, and fetching general Google search and video results.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@SearchAPI MCP Server search for hotels in Paris for next weekend"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Model Context Protocol (MCP) server for searchapi.io API
searchapi-mcp 是一个 Model Context Protocol (MCP) 服务器，它为 Claude 等 AI 助手提供了访问 searchapi.io API 的能力。通过这个工具，AI 助手可以搜索 Google 地图、航班、酒店等信息。
Related MCP server: Scrapeless MCP Server
搜索 Google 地图上的地点或服务
搜索 Google 航班信息
搜索 Google 酒店信息
搜索 Google 地图评论
查询 Google 酒店详细信息
查询 Google 航班日历价格
获取当前系统时间和旅行日期建议
搜索 Google 搜索结果
搜索 Google 视频结果
npm install -g searchapi-mcp在使用之前，你需要设置 SEARCHAPI_API_KEY 环境变量：
export SEARCHAPI_API_KEY="your_api_key"# 使用 stdio 传输启动服务器
searchapi-mcp
# 显示帮助信息
searchapi-mcp --help
# 显示版本信息
searchapi-mcp --version
# 指定传输类型
searchapi-mcp --transport stdio在 claude_desktop_config.json 中添加以下配置：
{
"mcpServers": {
"searchapi": {
"command": "npx",
"args": [
"-y",
"searchapi-mcp"
],
"env": {
"SEARCHAPI_API_KEY": "your_api_key",
"MCP_TRANSPORT": "stdio"
}
}
}
}搜索 Google 地图上的地点或服务。
参数：
query：搜索查询
location_ll（可选）：位置坐标，格式为"纬度,经度"
搜索 Google 航班信息。
必填参数：
departure_id：出发地 ID
arrival_id：目的地 ID
outbound_date：出发日期
flight_type：航班类型（默认：round_trip）
对于往返航班（round_trip），还需要：
return_date：返程日期
搜索 Google 酒店信息。
必填参数：
q：搜索查询
check_in_date：入住日期
check_out_date：退房日期
搜索 Google 地图上的评论数据。
必填参数（二选一）：
place_id：地点 ID
data_id：数据 ID
查询 Google 酒店详细信息。
必填参数：
property_token：物业令牌
check_in_date：入住日期
check_out_date：退房日期
查询 Google 航班日历价格。
必填参数：
flight_type：航班类型
departure_id：出发地 ID
arrival_id：目的地 ID
outbound_date：出发日期
对于往返航班（round_trip），还需要：
return_date：返程日期
获取当前系统时间和旅行日期建议。
参数：
format（可选）：日期格式（默认：iso）
days_offset（可选）：日期偏移量（默认：0）
return_future_dates（可选）：是否返回未来日期（默认：false）
future_days（可选）：未来天数（默认：7）
搜索 Google 搜索结果。
必填参数：
q：搜索查询
搜索 Google 视频结果。
必填参数：
q：搜索查询
本项目是基于 RmMargt/searchAPI-mcp Python 版本改编的 Node.js 实现。特别感谢 RmMargt 提供的原始 Python 实现和设计思路。
同时感谢：
Model Context Protocol - 提供协议规范
searchapi.io - 提供搜索服务 API
MIT
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | 日期格式 | iso |
| days_offset | No | 日期偏移量 | 0 |
| return_future_dates | No | 是否返回未来日期 | false |
| future_days | No | 未来天数 | 7 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no 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?
Tool has no description.
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?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no 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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | 搜索查询 | |
| device | No | 设备类型 | desktop |
| location | No | 位置 | |
| uule | No | 位置编码 | |
| google_domain | No | Google域名 | google.com |
| gl | No | 地理位置 | us |
| hl | No | 语言 | en |
| lr | No | 语言限制 | |
| cr | No | 国家限制 | |
| nfpr | No | 不进行拼写检查 | 0 |
| filter | No | 过滤结果 | 1 |
| safe | No | 安全搜索 | off |
| time_period | No | 时间段 | |
| time_period_min | No | 最小时间段 | |
| time_period_max | No | 最大时间段 | |
| num | No | 结果数量 | 10 |
| page | No | 页码 | 1 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no 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?
Tool has no description.
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?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no 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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| departure_id | Yes | 出发地ID | |
| arrival_id | Yes | 目的地ID | |
| outbound_date | Yes | 出发日期 | |
| flight_type | No | 航班类型 | round_trip |
| return_date | No | 返程日期 | |
| gl | No | 地理位置 | |
| hl | No | 语言 | |
| currency | No | 货币 | |
| travel_class | No | 舱位等级 | |
| stops | No | 中转次数 | |
| sort_by | No | 排序方式 | |
| adults | No | 成人数量 | |
| children | No | 儿童数量 | |
| multi_city_json | No | 多城市行程JSON | |
| show_cheapest_flights | No | 显示最便宜航班 | |
| show_hidden_flights | No | 显示隐藏航班 | |
| max_price | No | 最高价格 | |
| carry_on_bags | No | 随身行李 | |
| checked_bags | No | 托运行李 | |
| included_airlines | No | 包含的航空公司 | |
| excluded_airlines | No | 排除的航空公司 | |
| outbound_times | No | 出发时间范围 | |
| return_times | No | 返程时间范围 | |
| emissions | No | 排放量 | |
| included_connecting_airports | No | 包含的中转机场 | |
| excluded_connecting_airports | No | 排除的中转机场 | |
| layover_duration_min | No | 最短中转时间 | |
| layover_duration_max | No | 最长中转时间 | |
| max_flight_duration | No | 最长飞行时间 | |
| separate_tickets | No | 分开的机票 | |
| infants_in_seat | No | 占座婴儿数量 | |
| infants_on_lap | No | 不占座婴儿数量 | |
| departure_token | No | 出发令牌 | |
| booking_token | No | 预订令牌 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no 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?
Tool has no description.
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?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no 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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| flight_type | Yes | 航班类型 | |
| departure_id | Yes | 出发地ID | |
| arrival_id | Yes | 目的地ID | |
| outbound_date | Yes | 出发日期 | |
| return_date | No | 返程日期 | |
| outbound_date_start | No | 出发日期开始 | |
| outbound_date_end | No | 出发日期结束 | |
| return_date_start | No | 返程日期开始 | |
| return_date_end | No | 返程日期结束 | |
| gl | No | 地理位置 | |
| hl | No | 语言 | |
| currency | No | 货币 | |
| adults | No | 成人数量 | |
| children | No | 儿童数量 | |
| travel_class | No | 舱位等级 | |
| stops | No | 中转次数 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no 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?
Tool has no description.
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?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no 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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | 搜索查询 | |
| check_in_date | Yes | 入住日期 | |
| check_out_date | Yes | 退房日期 | |
| gl | No | 地理位置 | |
| hl | No | 语言 | |
| currency | No | 货币 | |
| property_type | No | 物业类型 | |
| sort_by | No | 排序方式 | |
| price_min | No | 最低价格 | |
| price_max | No | 最高价格 | |
| property_types | No | 物业类型列表 | |
| amenities | No | 设施 | |
| rating | No | 评分 | |
| free_cancellation | No | 免费取消 | |
| special_offers | No | 特别优惠 | |
| for_displaced_individuals | No | 为流离失所的个人 | |
| eco_certified | No | 生态认证 | |
| hotel_class | No | 酒店等级 | |
| brands | No | 品牌 | |
| bedrooms | No | 卧室数量 | |
| bathrooms | No | 浴室数量 | |
| adults | No | 成人数量 | |
| children_ages | No | 儿童年龄 | |
| next_page_token | No | 下一页令牌 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no 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?
Tool has no description.
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?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no 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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| property_token | Yes | 物业令牌 | |
| check_in_date | Yes | 入住日期 | |
| check_out_date | Yes | 退房日期 | |
| gl | No | 地理位置 | |
| hl | No | 语言 | |
| currency | No | 货币 | |
| adults | No | 成人数量 | |
| children | No | 儿童数量 | |
| children_ages | No | 儿童年龄 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no 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?
Tool has no description.
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?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no 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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 搜索查询 | |
| location_ll | No | 位置坐标，格式为"纬度,经度" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no 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?
Tool has no description.
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?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no 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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| place_id | No | 地点ID | |
| data_id | No | 数据ID | |
| topic_id | No | 主题ID | |
| next_page_token | No | 下一页令牌 | |
| sort_by | No | 排序方式 | |
| rating | No | 评分 | |
| hl | No | 语言 | |
| gl | No | 地理位置 | |
| reviews_limit | No | 评论数量限制 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no 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?
Tool has no description.
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?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no 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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | 搜索查询 | |
| device | No | 设备类型 | desktop |
| location | No | 位置 | |
| uule | No | 位置编码 | |
| google_domain | No | Google域名 | google.com |
| gl | No | 地理位置 | us |
| hl | No | 语言 | en |
| lr | No | 语言限制 | |
| cr | No | 国家限制 | |
| nfpr | No | 不进行拼写检查 | 0 |
| filter | No | 过滤结果 | 1 |
| safe | No | 安全搜索 | off |
| time_period | No | 时间段 | |
| time_period_min | No | 最小时间段 | |
| time_period_max | No | 最大时间段 | |
| num | No | 结果数量 | 10 |
| page | No | 页码 | 1 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no 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?
Tool has no description.
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?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no 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?
Tool has no description.
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?
Tool has no description.
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.
get_current_timesearch_googlesearch_google_flightssearch_google_flights_calendarsearch_google_hotelssearch_google_hotels_propertysearch_google_mapssearch_google_maps_reviewssearch_google_videosScored across 9 tools
Most tools are clearly distinct by their target resource (flights, hotels, maps, videos), but there is some ambiguity between search_google_flights and search_google_flights_calendar, and between search_google_hotels and search_google_hotels_property, which could cause confusion about when to use each. The get_current_time tool stands out as unrelated to the search domain, creating a minor disjunction.
All tool names follow a consistent snake_case pattern with a clear verb_noun structure, primarily using 'search_google_' as a prefix for most tools. This predictability makes it easy for an agent to understand and navigate the tool set without confusion over naming conventions.
With 9 tools, the count is reasonable for a search-focused API, though it feels slightly heavy due to the inclusion of get_current_time, which doesn't align with the core domain. The search tools are well-scoped, but the outlier tool slightly reduces the appropriateness.
The tool set covers various Google search domains (flights, hotels, maps, videos) but has notable gaps: there is no general web search tool (search_google is present but ambiguous without a description), and coverage is inconsistent (e.g., flights and hotels have multiple tools, while videos has only one). This may lead to agent failures for common search queries outside the specified categories.
A Model Context Protocol server for Wix AI tools
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
MCP server for Google search results via SERP API