Google Search MCP
Enables web search capabilities using Google Custom Search API, allowing queries to retrieve real-time information from the internet with configurable result counts.
Click on "Deploy 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 MCPsearch for latest AI developments in 2024"
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
A Model Context Protocol (MCP) server that utilizes Google Custom Search (CSE) to retrieve information from the internet. By leveraging this MCP, the Large Language Model (LLM) is enabled to perform real-time Web searches.
Prerequisites
A Google Custom Search API key and Custom Search Engine ID are required:
Get a Google API Key from the Google Cloud Console
Create a Custom Search Engine at Programmable Search Engine
Related MCP server: Google Search MCP Server
Installation
pip install google-search-mcpOr install from source:
pip install .Configuration
Create a .env file in the project root directory:
cp .env.example .envThen edit the .env file and add your credentials:
GOOGLE_API_KEY=your-api-key
GOOGLE_CSE_ID=your-custom-search-engine-idAlternatively, you can set environment variables directly:
export GOOGLE_API_KEY="your-api-key"
export GOOGLE_CSE_ID="your-custom-search-engine-id"Usage
As a CLI
google-search-mcpWith Claude Desktop
Add the following to your Claude Desktop configuration file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
For macOS/Linux:
{
"mcpServers": {
"google-search": {
"command": "python",
"args": ["-m", "google_search_mcp"],
"env": {
"GOOGLE_API_KEY": "your-api-key",
"GOOGLE_CSE_ID": "your-custom-search-engine-id"
}
}
}
}For Windows:
If python is in your PATH (check with where python), you can use the same configuration as macOS/Linux:
{
"mcpServers": {
"google-search": {
"command": "python",
"args": ["-m", "google_search_mcp"],
"env": {
"GOOGLE_API_KEY": "your-api-key",
"GOOGLE_CSE_ID": "your-custom-search-engine-id"
}
}
}
}If you need to use a specific Python installation, find the full path with:
python -c "import sys; print(sys.executable)"Then use the full path in the configuration:
{
"mcpServers": {
"google-search": {
"command": "C:\\Users\\YOUR_USERNAME\\AppData\\Local\\Microsoft\\WindowsApps\\PythonSoftwareFoundation.Python.3.13_qbz5n2kfra8p0\\python.exe",
"args": ["-m", "google_search_mcp"],
"env": {
"GOOGLE_API_KEY": "your-api-key",
"GOOGLE_CSE_ID": "your-custom-search-engine-id"
}
}
}
}Note: Environment variables must be set in the Claude Desktop config env section for the server to access them.
Tools
search
Search the web using Google Custom Search.
Parameters:
query(string, required): The search query stringnum_results(integer, optional): Number of results to return (1-10, default 10)
Development
Running Tests
Install development dependencies:
pip install -e ".[dev]"Run the test suite:
pytestRun tests with verbose output:
pytest -vRun tests with coverage:
pytest --cov=google_search_mcp --cov-report=htmlTest Coverage
The test suite includes comprehensive tests for:
Successful search requests
Environment variable validation
API error handling
JSON parsing errors
Empty search results
Input parameter validation (num_results clamping)
Result formatting
Request parameter verification
License
MIT License - see LICENSE for details.
Available Tools
1 toolsearchB
Search the web using Google Custom Search.
Args:
query: The search query string.
num_results: Number of results to return (1-10, default 10).
Returns:
Search results as formatted text.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| num_results | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool searches the web and returns formatted text, but lacks details on rate limits, authentication needs, error handling, or whether it's a read-only operation. For a web search tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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 appropriately sized and front-loaded, with a clear purpose statement followed by structured sections for Args and Returns. Every sentence earns its place by providing essential information without redundancy, making it easy to scan and understand quickly.
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 tool's moderate complexity (web search with 2 parameters), no annotations, and an output schema present, the description is partially complete. It covers parameters and return format, but lacks behavioral context like limitations or error cases. The output schema reduces the need to detail return values, but overall completeness is adequate with clear gaps.
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?
The description adds meaningful context beyond the input schema, which has 0% description coverage. It explains that 'query' is a search query string and 'num_results' specifies the number of results with a range (1-10) and default (10), clarifying usage that isn't evident from the schema alone. This compensates well for the low schema coverage.
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 the tool's purpose as 'Search the web using Google Custom Search,' which is a specific verb+resource combination. It distinguishes itself by specifying the search engine (Google Custom Search), though with no sibling tools mentioned, full differentiation isn't required. However, it lacks explicit mention of what makes this search unique (e.g., real-time web search vs. internal database).
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, limitations (e.g., internet access required), or scenarios where it's most appropriate. With no sibling tools, some context is implied, but explicit usage instructions are missing.
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 tool update
v1.0.0- First observed
search
TDQS
Scored across 1 tool
With only one tool, there is no possibility of ambiguity or overlap between tools. The tool's purpose is clearly defined as web searching, leaving no room for confusion or misselection.
A single tool inherently has perfect naming consistency, as there are no other tools to compare it against. The name 'search' is straightforward and follows a simple verb pattern appropriate for its function.
A single tool is too few for a server named 'Google Search MCP', which suggests a broader scope. While the tool covers basic search functionality, the server lacks additional operations like advanced search filters, image search, or news search, making it feel thin and underdeveloped for its apparent purpose.
The tool surface is severely incomplete for a Google Search domain. It only provides basic text search, missing essential features such as image search, video search, news search, or advanced query options. This creates significant gaps that will limit agent capabilities and lead to failures in handling diverse search-related tasks.
Maintenance
Related MCP Connectors
Search Google straight from your AI agent. Web results, images, videos, news, products, scholarly ar
Real-time web search, reasoning, and research through Perplexity's API
Provides AI assistants with access to Seltz's powerful Web Search capabilities.
Web search, scraping, Google Trends and data lookups. Paid per call in USDC on Base via x402.
Related MCP Servers
- AlicenseBqualityDmaintenanceFacilitates web search capabilities using Perplexity's API, allowing users to retrieve search results through Claude's interface.18MIT
- AlicenseNot gradedqualityDmaintenanceA Model Context Protocol server that enables Claude to perform Google Custom Search operations by connecting to Google's search API.2MIT
- FlicenseAqualityDmaintenanceProvides web search capabilities to Claude AI using the Anthropic API, allowing LLMs to access up-to-date information from the web with customizable domain filtering.148-
- FlicenseBqualityDmaintenanceEnables web searching and content scraping through Google Custom Search API. Provides tools to search the internet, extract webpage content, and automatically scrape search results for comprehensive information gathering.3-