Skip to main content
Glama
Sign In
Serper Live

Serper Live

by serper-live
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Live Google search

google_search
Read-only

Run a live Google search by country, language and device to get organic results in ranking order with titles, URLs, snippets, plus People also ask and related searches.

Instructions

Run a live Google search for a country, language and device and return the organic results in Google's order: position, title, URL, domain and snippet, plus the questions of Google's "People also ask" block and its related searches. Ads, sitelinks, video and image blocks are left out, so position is the organic rank. Every call is a real, uncached search that usually takes 2–3 seconds and is billed to the Serper.live balance per page of up to 10 results that received results, after the free searches of the account (https://serper.live/pricing); a search that finds nothing costs nothing. Use it to see the whole result list; to check where one site ranks, use domain_position instead.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>",
      "country": "<country>"
    },
    "name": "google_search"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoHow many organic results to return, 1–100. Default: 10. Each page of 10 that receives results is billed.
queryYesSearch keyword, exactly as a person would type it into Google.
deviceNoBrowser persona Google sees. Desktop and mobile rankings often differ. Default: desktop.
countryYesTwo-letter code of the market to search in, e.g. "US", "GB", "DE", "FR", "TR": Google sees a visitor from this country. Call list_countries for the markets that are open right now.
languageNoGoogle interface language (hl), e.g. "en", "de", "fr", "uk". Defaults to the language of the country; the market itself is set by country.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.2.0
    • changedInput schema / properties / limit / description
      Previous value: -"How many organic results to return, 1–100. Default: 10. Each started page of 10 results is billed."New value: +"How many organic results to return, 1–100. Default: 10. Each page of 10 that receives results is billed."
  2. Changed3 schema fields changedv2.0.1
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • changedInput schema / properties / country / description
      Previous value: -"Two-letter code of the market to search in, e.g. \"US\", \"GB\", \"DE\", \"TR\". Call list_countries for the markets that are open right now."New value: +"Two-letter code of the market to search in, e.g. \"US\", \"GB\", \"DE\", \"FR\", \"TR\": Google sees a visitor from this country. Call list_countries for the markets that are open right now."
    • changedInput schema / properties / language / description
      Previous value: -"Google interface language (hl), e.g. \"en\", \"de\", \"uk\". Defaults to the language of the country."New value: +"Google interface language (hl), e.g. \"en\", \"de\", \"fr\", \"uk\". Defaults to the language of the country; the market itself is set by country."
  3. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the readOnly/openWorld/idempotent annotations, it discloses that every call is real and uncached, costs 2–3 seconds, is billed per page of up to 10 results that received results, is free when nothing is found, and draws against the account's free searches. It also names what is excluded (ads, sitelinks, video, image blocks), which explains why position is a clean organic rank.

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 output contract comes first, cost and latency next, and the routing to domain_position last, so nothing important is buried. It is dense and slightly long for a single flowing sentence chain, but every clause (exclusions, billing, latency) carries information an agent needs.

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?

With no output schema, the description carries the return-format burden fully: it enumerates returned fields plus the 'People also ask' and related-search blocks. Combined with cost, latency and sibling routing, an agent has everything needed to call it correctly.

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

Parameters4/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 earns an extra point by framing the parameters as the market/persona inputs ('for a country, language and device') and by explaining that the device persona changes rankings. It adds no syntax detail, which the schema already handles.

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

Purpose5/5

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

The description opens with a specific verb and resource ('Run a live Google search') and immediately scopes the output (organic results in Google's order, with position, title, URL, domain, snippet). It explicitly contrasts with the sibling domain_position, so the agent can distinguish both tools without opening either schema.

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

Usage Guidelines5/5

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

It states when to use it ('to see the whole result list') and names the alternative with its selecting condition ('to check where one site ranks, use domain_position'). The country parameter additionally routes the agent to list_countries for open markets, covering the second sibling.

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

Deploy Server

Other Tools