SerpApi MCP Server

Overview Schema Source Related Servers Discussions Admin

SerpApi search

search

Read-only

Retrieve live structured SERP data from multiple engines for any query: web, news, flights, hotels, shopping, and more. Specify engine and parameters to get accurate results.

Instructions

Universal search tool supporting all SerpApi engines and result types.

When to use:
    - Any query needing live, structured SERP data: web results, news, product listings, job postings, local businesses, flight/hotel prices, video results, images, stock/weather cards, knowledge graph entities.

Engine discovery via MCP resources:
    - serpapi://engines lists all engines supported by this tool.
    - serpapi://engines/<engine> provides engine-specific parameters and supported options.
    - Example: serpapi://engines/google_news

Input schema:
    params: JSON object containing SerpApi engine parameters.
        Common parameters:
            - q: Search query. Required for most engines.
            - engine: SerpApi engine name. Defaults to "google_light".
            - location: Optional geographic location for localized results.
            - output: Optional response format. Omit for JSON (default), or set to "md" for Markdown.

        Engine-specific parameters are available via MCP resources:
            - serpapi://engines lists all supported engines.
            - serpapi://engines/<engine> provides parameters and options for one engine.

    mode: Response mode. Defaults to "complete".
        - "complete": Return the full SerpApi response.
        - "compact": Remove metadata fields from JSON responses. Markdown is returned unchanged.

Output schema:
    structuredContent.result contains the response string: serialized JSON or unchanged Markdown.
    The same string is included in text content. Tool failures preserve this wrapper and set isError to true.

Guided search:
    Searches can request missing engine parameters from supporting clients using the engine catalog and engine-specific rules.
    Flights collect airports and dates, hotels collect the destination and stay dates, and directions collect missing endpoints.
    Other clients receive a missing-parameter error. Cancellation does not run a search.

Examples:
    Weather: {"params": {"q": "weather in London", "engine": "google"}, "mode": "complete"}
    Stock: {"params": {"q": "AAPL stock", "engine": "google"}, "mode": "complete"}
    General: {"params": {"q": "coffee shops", "engine": "google_light", "location": "Austin, TX"}, "mode": "complete"}
    Compact: {"params": {"q": "news"}, "mode": "compact"}
    Markdown: {"params": {"q": "news", "output": "md"}}

Supported engines include (not limited to):
    - google
    - google_light
    - google_flights
    - google_hotels
    - google_images
    - google_news
    - google_local
    - google_shopping
    - google_jobs
    - bing
    - yahoo
    - duckduckgo
    - youtube_search
    - baidu
    - ebay

Input Schema

TableJSON Schema

Name	Required	Description	Default
`mode`	No	Response mode (default: "complete") - "complete": Returns the full response - "compact": Removes metadata fields from JSON responses; Markdown is unchanged	complete
`params`	No	Dictionary of SerpApi engine-specific parameters. Common parameters include: - q: Search query (required for most engines) - engine: Search engine to use (default: "google_light") - location: Geographic location filter - output: Response format; omit for JSON or set to "md" for Markdown

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv2.0.0Sep 22, 2026
- removedInput schema / properties / params / additionalProperties
```
Removed value: -true
```
- addedInput schema / properties / params / anyOf
```
Added value: +[
+  {
+    "additionalProperties": true,
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]
```
- removedInput schema / properties / params / type
```
Removed value: -"object"
```
First observedv1.0.3Sep 15, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds substantial behavioral context beyond that: compact versus complete response modes, Markdown behavior, output wrapper structure, guided-search interaction for missing parameters, cancellation semantics, and failure wrapper behavior. This goes well beyond what annotations or schema alone provide.

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 long but well-organized with clear sections, bullet lists, and examples. The engine-discovery instructions are repeated twice, which is mildly redundant, but the overall structure is scannable and every major section earns its place given the tool's breadth.

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

Completeness5/5

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

For a broad, engine-flexible tool, the description is remarkably complete: it covers when to use the tool, how to discover supported engines, parameter conventions, response modes, output schema, guided-search behavior, and realistic examples. With a rich output schema and annotations present, no critical operational detail is missing.

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

Parameters5/5

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

Schema coverage is 100%, but the description adds meaningful guidance beyond the schema: it explains which parameters are common, notes 'q' is required for most engines, gives concrete JSON examples, and points to MCP resources for engine-specific parameter discovery. This helps an agent construct valid params far better than the raw schema alone.

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 states a specific verb and resource: a universal search tool covering 'all SerpApi engines and result types.' It clearly enumerates the kinds of live structured SERP data it retrieves. However, it never explicitly contrasts itself with the sibling tools search_dashboard and search_table, so the differentiation is implicit rather than stated.

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

Usage Guidelines4/5

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

The 'When to use' section explicitly lists concrete scenarios such as web results, news, product listings, flights, and videos, giving an agent clear selection criteria. It does not mention when not to use the tool or point to sibling alternatives, but the listed conditions are specific enough to guide invocation.

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

Deploy Server