Skip to main content
Glama
Sign In
Serper Live

Serper Live

by serper-live
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Serper.live MCP server

Serper Live MCP server – quality and maintenance score on Glama Serper.live MCP on mcprush

Live Google search for AI agents. This Model Context Protocol server lets Claude, OpenAI Codex, Cursor, VS Code and other MCP clients run a real Google search through Serper.live for the country, language and device you choose, and check where a domain ranks right now.

Every search is fresh: nothing is cached, and a page of 10 results usually comes back in 2–3 seconds. Positions count organic results only, without ads, sitelinks, video or image blocks, so the number an agent reads is the number a rank tracker would store.

Tools

Tool

What it does

Cost

google_search

Live organic results for a keyword: position, title, url, domain, snippet, up to 100 per call, plus Google's "People also ask" questions and related searches

Billed per page of up to 10 results that received results

domain_position

Where a domain ranks for a keyword in a country and on a device; every position if it appears more than once, or "not in the top N"

Same as google_search for the depth checked

list_countries

Markets open right now and the default Google language of each

Free, no token

Arguments: query (2–120 characters), country (two-letter code such as US, GB, DE, FR, TR, UA), optional language (Google interface language, defaults to the country's), device (desktop or mobile) and limit / depth (1–100, default 10).

Related MCP server: Google Search Console MCP

Setup

  1. Create an account at serper.live: it starts with 100 free searches, no card needed. Then create an API token on API tokens. Add credit when the free searches run out: by card from $10 or in USDT or USDC from $5, no subscription, credit never expires.

  2. Add the server to your client with the token in SERPER_LIVE_TOKEN. It runs with npx, so Node.js 20 or newer is all you need; Claude Desktop can also install it in one click without Node.js.

Claude Code

claude mcp add serper-live -e SERPER_LIVE_TOKEN=sl_live_YOUR_TOKEN -- npx -y @serper-live/mcp

Claude Desktop

One click: download serper-live-mcp.mcpb from the latest release and open it. Claude Desktop shows an install dialog, asks for the API token once, stores it securely and runs the server with its own Node.js.

Or by hand, in claude_desktop_config.json:

{
  "mcpServers": {
    "serper-live": {
      "command": "npx",
      "args": ["-y", "@serper-live/mcp"],
      "env": {
        "SERPER_LIVE_TOKEN": "sl_live_YOUR_TOKEN"
      }
    }
  }
}

Cursor

~/.cursor/mcp.json or .cursor/mcp.json in a project:

{
  "mcpServers": {
    "serper-live": {
      "command": "npx",
      "args": ["-y", "@serper-live/mcp"],
      "env": {
        "SERPER_LIVE_TOKEN": "sl_live_YOUR_TOKEN"
      }
    }
  }
}

VS Code

.vscode/mcp.json — VS Code asks for the token once and keeps it out of the file:

{
  "inputs": [
    {
      "type": "promptString",
      "id": "serper-live-token",
      "description": "Serper.live API token",
      "password": true
    }
  ],
  "servers": {
    "serper-live": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@serper-live/mcp"],
      "env": {
        "SERPER_LIVE_TOKEN": "${input:serper-live-token}"
      }
    }
  }
}

OpenAI Codex

codex mcp add serper-live --env SERPER_LIVE_TOKEN=sl_live_YOUR_TOKEN -- npx -y @serper-live/mcp

Or by hand, in ~/.codex/config.toml (the Codex CLI, its IDE extension and the ChatGPT desktop app share this file):

[mcp_servers.serper-live]
command = "npx"
args = ["-y", "@serper-live/mcp"]

[mcp_servers.serper-live.env]
SERPER_LIVE_TOKEN = "sl_live_YOUR_TOKEN"

Any other MCP client: run npx -y @serper-live/mcp over stdio with SERPER_LIVE_TOKEN in the environment. Agents that set up servers from a repository, such as Cline, follow llms-install.md.

Environment

Variable

Required

Description

SERPER_LIVE_TOKEN

for searches

API token from API tokens. Without it list_countries still works

SERPER_LIVE_API_URL

no

API base URL, default https://api.serper.live

What to ask

  • "Where does example.com rank on Google in Germany on mobile for project management software? Check the top 30."

  • "Compare the top 10 Google results for best running shoes in the US and the UK."

  • "Which markets can you search in?"

Billing and retries

Searches are billed to your Serper.live balance per page of up to 10 organic results that received results, at the price of the market (pricing); desktop and mobile cost the same. The free searches of the account are used first, a search that finds nothing costs nothing, and a search that fails or runs out of time is never charged. Each call sends an Idempotency-Key, so a repeated call is never billed twice.

Development

npm install
npm run build
npx @modelcontextprotocol/inspector node dist/index.js
npm run bundle   # serper-live-mcp.mcpb: dist/, manifest.json, icon.png and the production dependencies

Releasing

The version lives in package.json, in version plus packages[0].version of server.json, which the MCP Registry checks against npm, and in manifest.json of the MCP Bundle. npm version sets all of them: its version script (scripts/sync-version.mjs) copies the new version into server.json and manifest.json.

A pushed v* tag runs .github/workflows/publish.yml: it checks that the tag matches every version field, builds, packs and validates the MCP Bundle, publishes to npm through trusted publishing (no npm token, with provenance), waits until npm serves the new version (up to 30 minutes), attaches serper-live-mcp.mcpb to the GitHub release and updates the MCP Registry through GitHub OIDC with two packages: npm and the bundle with its SHA-256. A failed run can be re-run as is: a version npm already has is not published again, and the release asset is replaced.

npm version x.y.z --no-git-tag-version   # package.json, package-lock.json, server.json, manifest.json
git commit -am "Release x.y.z"
git tag vx.y.z
git push && git push origin vx.y.z

The npm package lists this workflow as its trusted publisher (package settings → Trusted Publisher → GitHub Actions: serper-live/serper-live-mcp, workflow publish.yml, with Allow npm publish ticked under Allowed actions).

Links

License

MIT

Available Tools

3 tools
domain_positionDomain position in GoogleA
Read-only

Find where a domain ranks in Google's organic results for a keyword, in a country and on a device, right now. Prefer it over google_search when only one site matters: it returns that site's best position and every other position, or a note that the site is outside the checked depth. A subdomain counts as the domain: example.com also matches blog.example.com. Billed like google_search, per page of 10 results of depth that received results (https://serper.live/pricing).

NameRequiredDescriptionDefault
depthNoHow many organic results to check, 1–100. Default: 10. Use 30 or more to see positions beyond the first page.
queryYesSearch keyword, exactly as a person would type it into Google.
deviceNoBrowser persona Google sees. Desktop and mobile rankings often differ. Default: desktop.
domainYesDomain to look for, e.g. "example.com". Scheme, path and a leading www are ignored.
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.

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the readOnly/openWorld/idempotent annotations: it discloses the subdomain matching rule, that results are a live snapshot ('right now'), that a below-depth note is returned instead of silence, and the billing model (per page of 10 results at the depth that actually returned results). Cost and edge-case semantics are exactly the kind of context annotations cannot carry.

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?

Four sentences, all load-bearing, with the core purpose front-loaded before alternatives and caveats. The final pricing sentence is slightly run-on ('per page of 10 results of depth that received results'), which costs a point but not comprehension.

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 six parameters, no output schema, and an open-world read, the description supplies everything an agent needs: what it returns (best position plus other positions), the no-match case, matching rules, and cost. Nothing essential is left to inference.

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, but the description adds real semantics the schema lacks: subdomain matching ('example.com also matches blog.example.com') disambiguates the domain parameter, and the depth/billing interaction clarifies what changing depth costs.

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 first sentence states a specific verb+resource+scope: rank lookup for a domain in Google organic results, parameterized by keyword, country, and device, at a point in time. It also names the sibling (google_search) it is not, so an agent can route between them 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?

Explicit selection rule: 'Prefer it over google_search when only one site matters.' The description also covers the degenerate case ('or a note that the site is outside the checked depth'), so the agent knows behavior when no match is found rather than inferring an empty result.

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

list_countriesOpen Serper.live marketsA
Read-onlyIdempotent

List the countries Serper.live can search right now, with the default Google interface language of each. Call it when unsure whether a market is open, then pass a returned code as country to google_search or domain_position. Desktop and mobile are available in every market. Free, no token needed.

NameRequiredDescriptionDefault

No parameters

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnly=true, idempotent=true and openWorld=true. The description adds real context beyond them: that every market supports desktop and mobile, and that the call is free with no token required, which lowers the agent's hesitation to call it. It does not describe the response shape, but with no parameters there is little else to disclose.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, each carrying distinct information (what it returns, when to call it and what to do next, availability/cost). Nothing is padded or repeated from the title.

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?

No output schema exists, and the description compensates by describing what is returned (country codes plus default interface language) and the availability guarantees. With no input parameters and only an open lookup role, nothing an agent needs is missing.

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?

The tool takes zero parameters, so the baseline is 4. The description goes slightly further by explaining the semantics of the returned code (usable as the `country` argument of sibling tools), which is the only 'value' semantics this parameterless tool needs.

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?

States a specific verb and resource ('List the countries Serper.live can search') and adds the scope of what each entry carries (default Google interface language). It is immediately distinguishable from google_search and domain_position, which it references as consumers.

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?

Gives an explicit trigger ('Call it when unsure whether a market is open') and the follow-up flow ('pass a returned code as country to google_search or domain_position'). The agent knows both when to call it and what to do with the result.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev2.2.0
    • Changedgoogle_search1 field changed
      • 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. 2 tool updatesv2.0.1
    • Changeddomain_position3 fields changed
      • 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."
    • Changedgoogle_search3 fields changed
      • 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. 3 tool updatesv0.1.0
    • First observeddomain_position
    • First observedgoogle_search
    • First observedlist_countries
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.7/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clearly distinct role: full organic search results, supported-country metadata, and single-domain rank lookup. google_search and domain_position overlap only superficially, and the descriptions explicitly direct the agent to the right tool for each case.

Naming Consistency4/5

All names are snake_case and readable, but the pattern is not fully uniform: list_countries is verb_noun, while google_search and domain_position are noun phrases. This is a minor deviation rather than a source of confusion.

Tool Count5/5

Three tools is well scoped for a focused live-search server, and each tool earns its place by covering search, market discovery, and domain-rank checking. There is no redundant surface area.

Completeness4/5

The core lifecycle for live Google organic search is covered: country availability, full result retrieval, and domain-specific rank checking. Minor gaps exist for adjacent search modes such as news, images, or video, but those are intentionally outside the stated organic-search purpose.

Maintenance

ActivityMaintained
ResponsivenessSyncing

Resources

Related MCP Connectors

Related MCP Servers

  • Fetch MCP Server

    Fetch MCP Serverofficial

    modelcontextprotocol
    A
    license
    A
    quality
    A
    maintenance
    This server enables LLMs to retrieve and process content from web pages, converting HTML to markdown for easier consumption.
    28
    1
    288,522 PyPI
    91,812
    MIT

  • Google Search Console MCP

    AminForou
    A
    license
    B
    quality
    C
    maintenance
    Connects Google Search Console with Claude AI to enable SEO professionals to analyze their SEO data through natural language conversations, providing access to property information, search analytics, URL inspection, and sitemap management.
    9,053 PyPI
    2,090
    MIT