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

serper-search-mcp-server

by smjahid012
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

search_rag_context

Retrieve Google search results as clean, chunked, metadata-rich text for RAG, semantic search, and vector databases.

Instructions

Returns Google search results as clean, chunked, metadata-rich text optimized for embedding pipelines and vector databases. No LLM required. Each chunk includes: text, source URL, domain, title, date, word count, and chunk index. Perfect for RAG pipelines, semantic search, and AI grounding.

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_rag_context"
  }
}

Input Schema

NameRequiredDescriptionDefault
queryYesSearch query to retrieve and chunk.
countryNoCountry code. Default: "US".
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.
include_paaNoInclude "People Also Ask" Q&A pairs as extra chunks. Default: true.
num_resultsNoNumber of web results to fetch (1–20, default 10).
output_formatNo"json" (structured, for vector DBs) or "text" (plain blocks, for direct prompt use). Default: "json".json
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.
max_chunk_wordsNoMaximum words per chunk (default 200). Lower = more chunks, finer granularity.

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 does disclose the return shape (text, source URL, domain, title, date, word count, chunk index) and that no downstream LLM is needed. It omits cost, latency, failure modes, and the link-redirect/30s-resolution behavior that only appears buried in a parameter description.

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?

Three tight sentences with the output structure front-loaded after the core purpose; the metadata field list is genuinely useful. The closing "Perfect for..." sentence is mildly promotional but still earns its place as a use-case cue.

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 an 8-parameter tool with no annotations and no output schema, the description does cover the return payload well. However, it leaves out how results are sized/paginated, whether there are result caps, and when to prefer this over a plain search sibling — gaps an agent would notice on a complex call.

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% with three enums documented in detail, so the schema does the heavy lifting and baseline 3 applies. The description adds nothing parameter-specific beyond the word "chunked" loosely hinting at max_chunk_words.

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?

States a specific verb and resource ("Returns Google search results") plus the differentiating transformation: clean, chunked, metadata-rich text for embedding pipelines. The RAG/vector-DB framing separates it from a plain web search, but it never names a sibling (search_web, scrape, deep_research) to make the distinction explicit.

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?

"Perfect for RAG pipelines, semantic search, and AI grounding" implies a use case but gives no when-to-use rules, no exclusions, and no comparison against the many search_* siblings. An agent must infer that this is the chunked-output variant rather than being told.

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