The MCP Chrome Google Search server enables Google searches and webpage content extraction through Chrome browser automation.
Perform Google Searches: Search with optional site filters, timeframe filters (hour, day, week, month, year), and retrieve specific pages of results (up to page 5, ~10 results per page).
Fetch Webpage Content: Extract readable text content from any URL, optionally including links.
Authenticated Access: Access authenticated content via your Chrome browser through visible browser windows and tabs.
Allows searching Google and extracting search results to provide information to Claude
Uses Chrome browser to perform web searches and extract webpage content for Claude
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., "@MCP Chrome Google Search search for the latest AI research papers on arXiv"
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.
MCP tool for Google search and webpage content extraction using Chrome browser. Works with Claude to enable Google search and content fetching capabilities.
Configure Claude Desktop
Open Claude Desktop on Mac
Go to Claude > Settings > Developer > Edit Config
Add the following to your config file:
{
"mcpServers": {
"mcp-chrome-google-search": {
"command": "npx",
"args": [
"-y",
"@cmann50/mcp-chrome-google-search"
]
}
}
}Restart Claude Desktop
First Time Setup
Grant Accessibility Permissions
On first run, approve macOS accessibility permissions prompt
Navigate to: System Preferences > Security & Privacy > Privacy > Accessibility
Add and enable permissions for your terminal app
Enable Chrome JavaScript from Apple Events
Open Chrome
Navigate to: View > Developer > Allow JavaScript from Apple Events
One-time setup only
Once configured, Claude will be able to perform Google searches and extract webpage content through Chrome when you make requests.
Related MCP server: Web Search MCP
Free to search google
Opens and small windows and uses your chrome browser, so should not get blocked
Since it is using your Chrome window it can access authenticated content. Claude can just open the URL in your browser.
✅ macOS
❌ Windows (not supported)
❌ Linux (not supported)
macOS
Google Chrome
Node.js 20 or higher
npx mcp-chrome-google-searchCheckout from git
Run npm run build
Add to Claude config (use absolute path):
{
"google-tools": {
"command": "node",
"args": [
"/your/checkout/path/mcp/mcp-chrome-google-search/dist/index.js"
]
}
}To test changes locally bump package.json version and run to put it in edit mode:
npm install -g .Then just do npm run build and the files will go in dist where claude is monitoring
Then press ctrl-R in claude desktop, no need to restart it
# Follow logs in real-time
tail -n 20 -F ~/Library/Logs/Claude/mcp*.logEnable developer settings:
echo '{"allowDevTools": true}' > ~/Library/Application\ Support/Claude/developer_settings.jsonOpen DevTools: Command-Option-Shift-i in Claude desktop
Use ctrl-r in Claude desktop while tailing for better errors
If you see:
execution error: Google Chrome got an error: Executing JavaScript through AppleScript
is turned off. For more information: https://support.google.com/chrome/?p=applescript (12)Solution:
Open Chrome
View > Developer > Allow JavaScript from Apple Events
If Chrome control fails:
Open System Preferences
Security & Privacy > Privacy > Accessibility
Ensure terminal app is listed and enabled
Use lock icon to make changes if needed
Uses AppleScript for Chrome control
Visible automation - Chrome windows will open/navigate
Each request opens a new Chrome tab
Close unused tabs periodically for optimal performance
Only use with trusted Claude instances (has Chrome control access)
Create GitHub issues for problems
Include macOS and Chrome version details
MIT License - see LICENSE file for details
Extract readable text content from a webpage using Chrome browser automation.
Key Features:
Returns main content text and optionally links
| Name | Required | Description | Default |
|---|---|---|---|
| includeLinks | No | Whether to include extracted links in the output | |
| url | Yes | Webpage URL to fetch (must include http:// or https://) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions Chrome browser automation and returning main content text with optional links, but lacks critical behavioral details: it doesn't specify if this is a read-only operation, potential rate limits, authentication needs, error handling for inaccessible pages, or what 'readable text' entails (e.g., stripping HTML, handling dynamic content). The description adds some context but leaves significant gaps for a tool interacting with external webpages.
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 concise and well-structured with a clear opening sentence followed by a bullet point. Every sentence earns its place by stating the core purpose and a key feature. However, the bullet point format is slightly redundant with the main sentence, and it could be more front-loaded by integrating the optional links feature into the initial statement.
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 complexity of web scraping (external interactions, potential failures) and lack of annotations or output schema, the description is incomplete. It doesn't explain return values beyond 'main content text and optionally links', leaving the agent uncertain about output structure, error responses, or behavioral constraints like timeouts or permissions. For a tool with no structured safety hints, this is inadequate.
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%, with clear descriptions for both parameters in the schema itself. The description adds minimal value beyond the schema: it mentions 'optionally links' which aligns with the 'includeLinks' parameter but doesn't provide additional semantic context. With high schema coverage, the baseline is 3, and the description doesn't significantly enhance parameter understanding.
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: 'Extract readable text content from a webpage using Chrome browser automation.' It specifies the verb (extract), resource (text content from a webpage), and method (Chrome browser automation). However, it doesn't explicitly differentiate from its sibling 'web-search' tool, which likely searches rather than extracts content from a specific URL.
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 mentions 'optionally links' as a feature but doesn't clarify scenarios where including links is beneficial or when to choose this over 'web-search'. There's no mention of prerequisites, limitations, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search webpages and get a specific page of results (each page has ~10 results). Optionally filter by site and timeframe.
| Name | Required | Description | Default |
|---|---|---|---|
| pageNumber | No | Which page of results to fetch (1-5). Each page contains ~10 results | |
| query_text | Yes | Plain text to search for (no Google operators plain text only - use other parameters for site/date filtering) | |
| site | No | Limit search to specific domain (e.g. 'github.com' or 'docs.python.org') | |
| timeframe | No | Time range filter (h=hour, d=day, w=week, m=month, y=year) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds some context beyond basic functionality: it mentions pagination ('each page has ~10 results') and optional filtering capabilities. However, it doesn't cover important aspects like rate limits, authentication needs, error handling, or what the output looks like (e.g., result format), which are significant gaps for a search tool.
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 extremely concise and front-loaded: it states the core purpose in the first clause and adds key details in a second sentence. Every word earns its place, with no redundancy or fluff, making it highly efficient for quick understanding.
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 (4 parameters, no output schema, no annotations), the description is somewhat complete but has gaps. It covers the basic operation and filtering options but lacks details on output format, error cases, or integration with the sibling tool. Without annotations or output schema, more behavioral context would be beneficial for full completeness.
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 documents all parameters thoroughly. The description adds minimal value beyond the schema by hinting at the optional nature of site and timeframe filters, but it doesn't provide additional semantic context or usage examples. This meets the baseline for high 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: 'Search webpages and get a specific page of results.' It specifies the verb ('search') and resource ('webpages'), and distinguishes it from the sibling tool 'web_fetch' by implying this is for search results rather than fetching specific pages. However, it doesn't explicitly contrast with the sibling, keeping it from a perfect score.
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 implied usage context by mentioning optional filters ('Optionally filter by site and timeframe'), which suggests when to use these parameters. However, it lacks explicit guidance on when to choose this tool over the sibling 'web_fetch' or any other alternatives, and doesn't specify prerequisites or exclusions, leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The two tools have clearly distinct purposes: web_fetch extracts content from a specific webpage, while web_search performs web searches and returns result pages. There is no overlap in functionality, making it easy for an agent to choose the correct tool based on the task.
Both tool names follow a consistent snake_case pattern with a clear verb-noun structure: web_fetch and web_search. The naming is predictable and readable, with no deviations in style or convention.
With only 2 tools, the server feels thin for a Google Search domain, which typically involves more operations like advanced filtering, image search, or history management. While the tools cover basic fetch and search, the scope is limited and could benefit from additional functionality to fully represent the domain.
The tools cover core search and content extraction, but there are notable gaps for a Google Search server, such as no tools for image search, news search, or handling search settings. Agents can perform basic tasks but may encounter dead ends for more advanced operations, indicating incomplete coverage of the domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Web search and page-reading for AI agents. One-click OAuth connect, or a Caesar API key.
Search Google straight from your AI agent. Web results, images, videos, news, products, scholarly ar
Web search, URL content extraction to Markdown, site mapping, and recursive web crawler.
Web search, fetch, extract, and research for AI agents. Markdown output + AI-synthesized answers.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/cmann50/mcp-chrome-google-search'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
