Google Search MCP Server
Provides tools to perform Google searches using the Custom Search Engine API, with support for parameters such as dateRestrict, siteSearch, and fileType.
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 Search MCP Serversearch the web for AI news from the 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.
Google Search MCP Server
This repository contains a Model Context Protocol (MCP) server that provides a tool-based interface to Google's Custom Search Engine (CSE) API. It is designed for use with MCP-compatible clients, such as those found in IDEs like Visual Studio Code, allowing developers and models to perform Google searches programmatically.
Features
Google Search Integration: Perform Google searches using the CSE API.
Expanded Search Parameters: Support for a wide range of search parameters, including
dateRestrict,siteSearch,fileType, and more.Flexible Configuration: Configure the server via environment variables or a
.envfile.User-Friendly Tools: Provides a clear
google_searchtool with support for various search parameters.Conversational Outputs: Returns search results in a conversational format, making it easy for clients to use the results.
Standalone and Asynchronous: The server runs as a standalone script and uses an asynchronous architecture for better performance.
Related MCP server: Google Search MCP Server
Prerequisites
Before running the server, you need to have Python 3.12+ and uv installed. You will also need a Google API key and a Programmable Search Engine (CSE) ID. You will also need Node.js and npx to run the MCP Inspector tool for testing.
Installation
Clone the repository.
# Use gh cli to clone repository gh repo clone fvanevski/google_search_mcp # Alternateively, use git to clone repository # git clone https://github.com/fvanevski/google_search_mcp.git # Enter the repository directory cd google_search_mcpCreate a virtual environment and install the required dependencies:
# Create a virtual environment uv venv # Activate the virtual environment source .venv/bin/activate # Install the dependencies uv sync
Running and Testing the Server
The MCP server is a command-line application that communicates over standard I/O. To use it, a client (like an IDE, a coding agent, or an inspector tool) must launch the server process.
Running for Diagnostics
You can try to run the script directly from your terminal to see if it starts without errors. This is a quick way to validate your Python environment and the script's basic syntax.
python google_search_mcp.pyHowever, the server will simply start and wait for input, so you won't be able to interact with it directly from your terminal.
Testing with MCP Inspector
The recommended way to test the server interactively is with MCP Inspector. It runs as a command-line tool and provides an interactive shell for sending requests to your server.
Launch the Inspector: You can run the inspector without a permanent installation using
npx. The inspector will launch your MCP server script for you. From your project directory, run:# Run the inspector with `uv run --with <dependencies> -- python3 <script>` npx @modelcontextprotocol/inspector uv run --with requests,python-dotenv,pydantic,mcp -- python3 google_search_mcp.pyEven if you have your virtual environment active, the
pythoncommand as executed by the inspector will not correctly point to the interpreter with the necessary dependencies, thus we use uv instead with the--withflag.Interact with the Server: Once the inspector starts, you can click the "Connect" button to establish a session with your server. You can then use ommands like
list_toolsandcall_toolto interact with it.Example session:
# List all available tools > list_tools # Call the 'google_search' tool with arguments > call_tool google_search '''{"query": "AI news", "dateRestrict": "d7"}'''This provides a reliable way to test all the tools and verify that the server is working as expected.
Configuration
The server is configured using environment variables or a .env file in your project's root directory.
Environment Variables
GOOGLE_API_KEY: Your Google API key.GOOGLE_CSE_ID: Your Custom Search Engine (CSE) ID.
Example .env file:
GOOGLE_API_KEY=your-secret-api-key
GOOGLE_CSE_ID=your-cse-idUsage with an MCP Client (VS Code Example)
You can connect to this server from any standard MCP client. Here’s how to do it in a VS Code environment that supports MCP:
Configure Your MCP Client: In your IDE's MCP client settings (e.g., in
mcp.jsonfor VS Code), configure a new MCP server that points to the script.Example
mcp.jsonentry for VS Code:{ "servers": { "google_search": { "command": "uv", "args": [ "run", "python", "google_search_mcp.py" ], "cwd": "/path/to/your/project" } } }Note: Replace
/path/to/your/projectwith the actual path to the project directory.Use the Tools: Once connected, you can use the exposed tools in your chat or agent interactions with natural language queries or structured calls. For example, to perform a Google search for recent PDF documents about machine learning, you could send the following structured tool call:
{ "tool": "google_search", "arguments": { "query": "machine learning", "dateRestrict": "m1", "fileType": "pdf" } }The server will execute the query and return the search results.
Available Tools
1 toolgoogle_searchB
Performs a Google Programmable Search (CSE) query. Returns a JSON list of results, each containing a URL, title, snippet, and pagemap.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The search query. | |
| num | No | Number of results to return (1-10). | |
| start | No | The starting index of the results (1-based). For example, `&start=11` would start at the 11th result. | |
| dateRestrict | No | Restricts results to a time period. Format: `d[number]`, `w[number]`, `m[number]`, `y[number]` (days, weeks, months, years). Example: `d7` for the last 7 days. | |
| siteSearch | No | Restricts results to a specific site. Example: `wikipedia.org`. | |
| siteSearchFilter | No | Whether to include (`i`) or exclude (`e`) results from the `siteSearch` domain. | |
| exactTerms | No | A phrase that all search results must contain. Example: "climate change" | |
| excludeTerms | No | A word or phrase that should not appear in any search results. Example: `politics` | |
| fileType | No | Restricts results to files of a specific extension. Example: `pdf` | |
| gl | No | Geolocation of the end user. A two-letter country code. Example: `us` for United States. | |
| lr | No | Restricts the search to documents written in a particular language. Example: `lang_en` for English. | |
| safe | No | Search safety level. `active` or `off`. | active |
| searchType | No | Specifies the search type. Set to `image` for image search. | |
| sort | No | Sorts results by a specific attribute. Format: `TYPE-NAME:DIRECTION`. Example: `metatags-pubdate:d` to sort by publication date in descending order. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only mentions the return format but does not address rate limits, authentication, potential side effects, or any other behavioral characteristics. The description is minimal.
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 a single sentence that directly conveys the tool's function and output. No unnecessary words. It is appropriately concise and front-loaded.
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 14 parameters and no output schema, the description only minimally covers return values. It mentions the fields but lacks detail on pagination, error handling, or common usage patterns. Completeness is adequate but not thorough.
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 coverage is 100%, so baseline is 3. The description does not add any meaning beyond what the input schema already provides; it only states the overall purpose. No parameter details are given in the description.
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 clearly states 'Performs a Google Programmable Search (CSE) query' and specifies the return format (JSON list with URL, title, snippet, pagemap). There are no sibling tools to differentiate from, but the purpose is unambiguous.
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?
No guidance on when to use this tool versus alternatives or under what circumstances. Since there are no sibling tools, the lack of context still leaves the agent without information about appropriate use cases or limitations.
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. Dates show when Glama detected each change.
1 tool update
v0.1.0- First observed
google_search
TDQS
With only one tool, there is no possibility of confusion. The tool's purpose is clearly defined and distinct.
The single tool name 'google_search' follows a clear and descriptive pattern (service_action), consistent with common conventions.
One tool is minimal for a search server. While it serves the basic purpose, a more comprehensive set (e.g., configuration, metadata) would be expected for a full-featured server.
The server only provides search functionality, missing obvious operations like managing search engines or retrieving result details. This gap limits the agent's ability to perform complete workflows.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Search Google straight from your AI agent. Web results, images, videos, news, products, scholarly ar
GoogleSearch API: Fetch real-time Google Search results including title, links Ideal for serp api.
Web search, news, page retrieval, sitemaps, and trending topics through Search1API.
Provides AI assistants with access to Seltz's powerful Web Search capabilities.
Related MCP Servers
- AlicenseAqualityDmaintenanceEnables search capabilities using a Google Custom Search Engine, allowing users to input a search term and retrieve search result titles, links, and snippets, while facilitating integration with other tools for content extraction and advanced search strategies.145-
- AlicenseAqualityDmaintenanceEnables users to perform Google Custom Search queries through the Model Context Protocol. Requires Google API credentials and Custom Search Engine configuration for web search functionality.1MIT
- AlicenseBqualityDmaintenanceEnables Large Language Models to perform real-time web searches using Google Custom Search API. Integrates with Claude Desktop to retrieve current information from the internet.1MIT
- FlicenseAqualityDmaintenanceEnables Google search with advanced options (date, language, country, safe search) and webpage content extraction via the Model Context Protocol.3-
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Calandrel/google_search_mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server