Provides real-time Google search results including organic results and knowledge graph, with support for country targeting, language, and time filters.
Click on "Install 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., "@Google Cheap Search search for latest AI news from last week"
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.
Real-time Google SERP results as an MCP tool: organic results + knowledge graph, with country targeting, language, time filters and pagination. From $0.60 per 1,000 searches (cache hits cost half).
Tool: google_search
npm: @serpcheap/mcp · bin: serpcheap-mcp
Transports: stdio (local, default) and Streamable HTTP (remote, https://mcp.serp.cheap/mcp)
Get an API key at app.serp.cheap.
claude mcp add google-cheap-search -e SERPCHEAP_API_KEY=your-key -- npx -y @serpcheap/mcp{
"mcpServers": {
"google-cheap-search": {
"command": "npx",
"args": ["-y", "@serpcheap/mcp"],
"env": { "SERPCHEAP_API_KEY": "your-key" }
}
}
}{
"mcpServers": {
"google-cheap-search": {
"url": "https://mcp.serp.cheap/mcp",
"headers": { "Authorization": "Bearer your-key" }
}
}
}The remote server is stateless: your key is forwarded per request to the API and never stored.
Related MCP server: Serpapi Universal MCP Server
google_search toolArgument | Type | Default | Description |
| string (1–500) | — | The search query. |
| enum |
| Country: |
| string | country native | Result language, BCP-47 style ( |
| enum | all time | Time filter: |
| int (1–99) |
| Result page, ~10 organic results each. |
Returns structured content (same shape as the REST API) and a markdown rendering:
{
"search": "mount everest",
"page": 1,
"knowledgeGraph": { "title": "Mount Everest", "description": "…", "attributes": { } },
"organic": [
{ "position": 1, "title": "…", "link": "…", "snippet": "…", "sitelinks": [] }
],
"stats": { "balance": 9970, "cost": 6, "cached": false }
}Env var | Default | Description |
| — | API key. Required for stdio; HTTP fallback when no header is sent. |
|
| API base URL override. |
|
| Upstream request timeout (1000–120000). |
serpcheap-mcp [--stdio | --http] [--host 127.0.0.1] [--port 7100] [-v] [-h]--http serves Streamable HTTP at /mcp (plus /healthz), stateless JSON-response
mode — safe to run behind a load balancer. Per-request auth via Authorization: Bearer
or X-API-Key headers.
The server never stores user keys; each request's key is forwarded to the API and dropped.
Request bodies are capped at 1 MB (413 beyond that).
/mcp is POST-only; GET/DELETE get 405 (no idle SSE streams to pin connections with).
The SERPCHEAP_API_KEY env fallback is denied to browser-originated requests (any
request carrying an Origin header): a malicious web page hitting a self-hosted
instance via DNS rebinding cannot spend your key. Browser-based MCP clients are
unaffected — they send their own key via headers. Non-browser clients (curl,
server-side SDKs) don't send Origin and keep the fallback. If you self-host with a
fallback key, still bind to localhost or front it with your own auth: anyone who can
reach the port can use the key.
npm install
npm test # vitest + coverage gate (95% lines / 90% branches)
npm run typecheck
npm run buildThis package lives in the serp.cheap monorepo. test/parity.test.ts pins the tool schema
to the public API contract (api/src/schemas/search.ts) — contract drift fails CI.
Search Google and get organic results plus knowledge-graph data, via serp.cheap. Call this whenever the answer depends on current or external web information — recent events, prices, product/library versions, niche facts, anything past your knowledge cutoff — or when the user explicitly asks to search or google something. Supports country targeting (gl), result language (hl), time filtering (tbs: past hour/day/week) and pagination (page).
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | The search query, exactly as you would type it into Google. | |
| gl | No | Country to search from (Google country code). Controls result localization and which Google domain is queried. | us |
| hl | No | Result language, BCP-47 style: "en", "pt-BR", "de". Defaults to the native language of the chosen country. | |
| tbs | No | Time filter: "qdr:h" = past hour, "qdr:d" = past day, "qdr:w" = past week. Omit for all-time results. | |
| page | No | Result page, 1-indexed. Each page carries ~10 organic results. |
| Name | Required | Description |
|---|---|---|
| page | Yes | The page that was fetched (1-indexed). |
| stats | No | Billing info: credits charged, remaining balance, cache hit. |
| search | Yes | The query that was executed. |
| organic | Yes | Organic results in ranking order. |
| knowledgeGraph | No | Google's entity panel for the query, when one exists. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true and openWorldHint=true, lowering the burden. The description adds useful behavioral context beyond annotations: the data source (serp.cheap), the return types (organic results plus knowledge-graph data), and supported controls (country, language, time filtering, pagination). It does not contradict the annotations.
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?
The description is three sentences, front-loaded with the core purpose, then usage guidance, then parameter capabilities. Every sentence adds distinct value and there is no fluff or repetition of the tool name. It is concise for the amount of guidance it provides.
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?
Given the presence of a rich schema, an output schema, and annotations, the description covers the main contextual needs: what it does, when to call it, and what key parameters are supported. It does not mention rate limits, costs, or failure modes, but those are not essential here since the tool is a straightforward read-only search and an output schema exists.
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?
Schema description coverage is 100%, so the schema already fully documents the parameters. The description reinforces the mapping by saying it 'Supports country targeting (gl), result language (hl), time filtering (tbs: past hour/day/week) and pagination (page),' but it adds only marginal meaning beyond the schema's own parameter descriptions. Baseline 3 is appropriate.
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?
The description opens with a specific verb and resource: 'Search Google and get organic results plus knowledge-graph data, via serp.cheap.' This clearly states what the tool does and what it returns. Even with no sibling tools, the purpose is unambiguous and distinguishable from a generic search by naming the concrete output types.
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?
The description gives explicit guidance on when to use the tool: 'whenever the answer depends on current or external web information — recent events, prices, product/library versions, niche facts, anything past your knowledge cutoff — or when the user explicitly asks to search or google something.' This is strong contextual guidance, though it does not mention when not to use it or list alternatives, since no siblings exist.
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. Dates show when Glama detected each change.
v0.1.0google_searchWith only one tool, there is no possibility of confusion between tools. The tool's purpose is clearly defined and unique.
The single tool name 'google_search' follows a clear verb_noun pattern, which is consistent even though there is only one tool. No mixed conventions exist.
The server has a single purpose — searching Google — and one tool fully realizes that purpose. While the count is below the typical 3-15 range, it is appropriate for the narrow, focused scope.
The tool provides comprehensive search capabilities, including organic results, knowledge graph data, filtering options, and pagination. There are no obvious gaps for the stated domain of Google search.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Scrape Google search results with SERP data, ads, and knowledge panels
GoogleSearch API: Fetch real-time Google Search results including title, links Ideal for serp api.
Google SERP as JSON: organic, AI Overview, People Also Ask, AI Mode, news, shopping. No Cloud setup.
Scrape AI answer engines and Google Search/News with country and state-level geo-targeting.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/SerpCheap/mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
