Skip to main content
Glama
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

Billed per page of up to 10 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, add credit (from $5 in USDT or USDC, no subscription, credit never expires) and create an API token on API tokens.

  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, at the price of the market (pricing); desktop and mobile cost the same. 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 started 10 results of depth (https://serper.live/pricing).

ParametersJSON Schema
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.7/5.0
Behavior4/5

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

Annotations already declare readOnly/openWorld/idempotent=false, but the description adds real substance beyond them: billing model ('per started 10 results of depth' with a pricing link), the freshness claim ('right now'), and the subdomain-matching rule. It does not restate the return payload's structure in detail, so a 4 rather than 5.

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?

Four tight sentences with zero filler, front-loaded with purpose then the sibling comparison then the matching/billing caveats. Every sentence 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?

No output schema exists, but the description compensates by describing the return content ('that site's best position and every other position, or a note that the site is outside the checked depth'). Combined with 100% schema coverage and annotations, 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 baseline is 3; the description nevertheless adds a non-schema rule ('A subdomain counts as the domain: example.com also matches blog.example.com') that changes how the domain argument should be chosen.

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 + resource + scope ('Find where a domain ranks in Google's organic results for a keyword, in a country and on a device, right now') and explicitly contrasts itself with the sibling google_search. An agent can select it without opening the 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?

Gives an explicit selection rule: 'Prefer it over google_search when only one site matters.' It also routes to list_countries for open markets via the country param description, covering the alternative-tool decision.

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.

ParametersJSON Schema
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. 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."
  2. 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.6/5.0

Scored across 3 tools

Disambiguation5/5

The three tools target clearly distinct jobs: full result-list search (google_search), single-site rank lookup (domain_position), and market discovery (list_countries). The descriptions explicitly cross-reference each other, telling the agent when to prefer domain_position over google_search. No meaningful ambiguity remains.

Naming Consistency4/5

All names are snake_case and readable, but the internal pattern is mixed: list_countries is verb_noun, domain_position is noun_noun, and google_search is noun_verb. The convention isn't strictly uniform, though it stays predictable enough that an agent won't be confused.

Tool Count4/5

Three tools is on the lean side, but each covers a genuinely distinct capability (search, rank check, market enumeration) for a focused search API. Nothing feels redundant or missing for the stated scope.

Completeness4/5

The surface covers the core lifecycle: discover available markets, run a search, and check a specific domain's rank. There are minor gaps (e.g. no explicit pagination control or separate news/image search modes), but these are deliberate exclusions and agents can work around them.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Fetch MCP Server by modelcontextprotocol

    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.
    20
    1
    228,373 PyPI
    91,511
    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.
    8,896 PyPI
    1,979
    MIT