Skip to main content
Glama
Sign In
serper-search-mcp-server

serper-search-mcp-server

by smjahid012
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

search

Query web, image, video, news, shopping, place, scholar, patent, and autocomplete results across multiple providers with automatic failover and credit-aware output.

Instructions

Unified search — one tool for all types (loads ~700 tokens instead of ~7k for 11 tools). Pick type=web|images|videos|news|shopping|places|scholar|patents|autocomplete and provider=auto|serper|tavily|brave|exa|firecrawl. Credit budget: basic 3 / standard 5 / deep 8 credits for deep_research; 1 credit per search; cache hits cost 0.

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>"
    },
    "name": "search"
  }
}

Input Schema

NameRequiredDescriptionDefault
typeNoResult type.web
queryYesSearch query (max 400 chars / 50 words).
countryNoISO 3166-1 alpha-2 country code (e.g. "US", "GB"). Default: "US".
ui_langNoUI language (e.g. "en-US"). Default: "en".
providerNoSearch backend: auto (failover chain), serper, tavily, brave, exa, firecrawl. Default: auto.auto
freshnessNoTime filter: pd=past day pw=week pm=month py=year any=none (historical). Pass pd/pw/pm/py whenever the user asks for latest/current/recent results ("today", "this week", "latest", current year); omit or "any" for timeless or historical questions. The response footer echoes the filter that was applied.
max_charsNoTruncate response to this many characters (0 = no limit).
verbosityNoOutput density: auto (server picks per audience), compact (~800 tokens, dev fast path), standard (KG+Box+10), full (everything, always for places/shopping/images/scholar). Default: auto.auto
safesearchNo"off" | "moderate" | "strict". Default: "moderate".moderate
num_resultsNoResults (1–20, default 10). Note: >10 results uses 2 Serper credits.
search_langNoLanguage code (e.g. "en", "de"). Default: "en".
snippets_onlyNoReturn 1-line snippets only (token-saving for agents). Default: false.
link_resolutionNoGoogle result links beyond the top 3 may come back as google.com/goto redirects. "auto" (default): top 3 resolved, any leftover goto links get a search_id for resolve_links. "all": also resolve every link now (free, but adds ~30 s when goto links are present). "none": fastest, links exactly as Google returns them.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv4.1.0
    • changedInput schema / properties / freshness / description
      Previous value: -"Time filter: pd=day pw=week pm=month py=year."New value: +"Time filter: pd=past day pw=week pm=month py=year any=none (historical). Pass pd/pw/pm/py whenever the user asks for latest/current/recent results (\"today\", \"this week\", \"latest\", current year); omit or \"any\" for timeless or historical questions. The response footer echoes the filter that was applied."
    • changedInput schema / properties / freshness / enum
      Previous value: -[
-  "pd",
-  "pw",
-  "pm",
-  "py"
-]New value: +[
+  "pd",
+  "pw",
+  "pm",
+  "py",
+  "any"
+]
  2. First observedv4.0.1

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations the description carries the full burden, and it does disclose genuinely useful economics: ~700 vs ~7k token load, 1 credit per search, cache hits free, and tiered credits for deep_research. It stops short of saying what a response contains, how provider failover behaves on error, or what auth/rate limits apply.

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?

One dense paragraph front-loads identity and type routing before costs, with no filler sentences. The parenthetical load-savings claim and the deep_research credit tier are compressed to the point of being slightly telegraphic, and the deep_research mention is only loosely relevant to calling this tool.

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

Completeness3/5

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

For a 13-parameter, no-annotation, no-output-schema tool the schema does most of the documentation work and the description adds the cost model. What is missing is selection guidance against twelve siblings and any statement of result shape or failure behavior, which matters for a tool advertising provider failover.

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

Parameters3/5

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

Schema description coverage is 100%, so every parameter including freshness, verbosity and link_resolution is already documented in detail. The description only restates the type and provider enum values, adding no semantics beyond what the schema provides; baseline 3 applies.

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?

Opens with a concrete verb+resource ('Unified search') and immediately scopes it as covering all result types with an enumerated type list, plus the explicit note that it replaces 11 separate tools. That implicitly separates it from siblings like search_web or search_images, though it never names any of them, so an agent must infer which to prefer in ambiguous cases.

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

Usage Guidelines3/5

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

'Pick type=... and provider=...' tells the agent how to configure the call but not when this tool beats the type-specific siblings or when to reach for deep_research. The credit budget line hints at cost tradeoffs but stops short of a routing rule such as 'use deep_research for multi-step questions'.

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